From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-2.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS,URIBL_BLACK shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 54FD41F910 for ; Mon, 28 Nov 2022 02:25:10 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=rivosinc-com.20210112.gappssmtp.com header.i=@rivosinc-com.20210112.gappssmtp.com header.b="QTezNo65"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A5A6C3858436 for ; Mon, 28 Nov 2022 02:25:04 +0000 (GMT) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by sourceware.org (Postfix) with ESMTPS id 5C343385840D for ; Mon, 28 Nov 2022 02:24:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5C343385840D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pj1-x1035.google.com with SMTP id v3-20020a17090ac90300b00218441ac0f6so11512632pjt.0 for ; Sun, 27 Nov 2022 18:24:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=p01jfPx06HmGs23Xz7fe1lSXbpXUTkkla7AE6ySutaY=; b=QTezNo65Lq2lEgzo5AcGgb9RFbL3GC77Yl8i91EM0Uj/XL8E3a5vUywVJOXvkwkamZ FYODiE043PqzmpA7hNG7t7HNVHNee4qBYVkJnWXxA3P9DwF4wzXHGm/7XDqdHQtxQGZx v4v+k6FXBJgaKscO/NcuJzc1EGESEWxNCLu6qnF3zt5GUEts10wSUNF6yjr/dz42w8GV Iv+wKyrB7abHwib7JcHhmYggS49tshxaLPyudijvn2cXkt+bs3LwLv3YUmiBteuTR9eL blKr44Yn3ojmQvZndDa7TEAJE70hBvkkVRhWj+3wzET8aIQ2SyBzLQ9jjqBNUz6OVu8J +A6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=p01jfPx06HmGs23Xz7fe1lSXbpXUTkkla7AE6ySutaY=; b=pX9a6jiM0hRRl7ZdScv2QfylZajBwhnHDIyVAFpKkYWOnPnAs4Skb8dXEMn7OnvrMm NMZMN7qQbkZIsPcqkCHinBIN4a07z+BaIV9mlly3zZ5v3wGyCzVcdQSkEx6mlLp4KDXa YMEv2Rsn7E11UuWxglMoUndQBlGuuaizEO0YVhQA5yNXzVBevMvFSfyVgwEoFdEGZ2g9 IHGr5QKDiTHzEiZ9fo4lK/nN2MuKKUnM3GOs+Fk/fSqu48ZbgujrOvLGmD0jjW9j6YL4 7vl2SJnKumP2tzE8pLZ7OcDlPWREgEnoW+gPtGrMZs3340cq+Kx58G3o3h1kTRoc88Tf gHNA== X-Gm-Message-State: ANoB5pmApLfQ//EUlKicPa6cGXIXYn7wbYx3p1KCzIagUVK3YGPNs2La TjNQ3fyLJXD61KAjLmd7nDZfqFTURc7Hkw== X-Google-Smtp-Source: AA0mqf6wP8FZuVcir3eKitp+eoQsR1+WarxuaiHqhPUZURFqfOEXGkSr6LVezDFtAHzr1oFNcy4y7A== X-Received: by 2002:a17:902:ce90:b0:186:ab02:664c with SMTP id f16-20020a170902ce9000b00186ab02664cmr31807673plg.49.1669602289363; Sun, 27 Nov 2022 18:24:49 -0800 (PST) Received: from [192.168.50.116] (c-24-4-73-83.hsd1.ca.comcast.net. [24.4.73.83]) by smtp.gmail.com with ESMTPSA id t5-20020a170902e84500b00176acd80f69sm7552031plg.102.2022.11.27.18.24.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Nov 2022 18:24:48 -0800 (PST) Message-ID: Date: Sun, 27 Nov 2022 18:24:47 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH] Revert "Correctly determine libc.so 'OUTPUT_FORMAT' when cross-compiling." Content-Language: en-US To: =?UTF-8?Q?Ludovic_Court=c3=a8s?= Cc: libc-alpha@sourceware.org, Carlos O'Donell , Fangrui Song , nelson Chu , palmer@rivosinc.com, gnu-toolchain@rivosinc.com References: <20221123025932.473655-1-vineetg@rivosinc.com> <87lenx9315.fsf@gnu.org> From: Vineet Gupta In-Reply-To: <87lenx9315.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" Hi Ludovic, On 11/26/22 06:57, Ludovic Courtès wrote: > Hi, > > Vineet Gupta skribis: > >> This reverts commit 361d6454c034a920f2c96517c277990d390b9652. >> >> This trips up riscv gnu toolchain builds [1] >> >> riscv ld segfaults when linking libgcc because libc.so linker script >> contains `OUTPUT_FORMAT(elf32-little)` vs. `OUTPUT_FORMAT(elf32-littleriscv)`. >> >> This patch causes builds to lookup riscv32* prefixed objdump and failing >> to find it falls back to host objdump which is the root of the issue. >> The host objdump in turn generates `OUTPUT_FORMAT(elf32-little)` >> >> riscv glibc multilib builds lack riscv32 prefix binaries. They have a >> single set of "riscv64" prefixed binaries supporting both 32 and 64-bit >> abis: ilp32/ilp32d/lp64/lp64d using -march/-mabi. >> >> FWIW I'm not sure how this patch fixed a real problem to begin with. > The rationale was described in the context of cross-compilation to > aarch64-linux-gnu: > > https://sourceware.org/pipermail/libc-alpha/2021-July/128333.html Yes I understood that clearly before posting this patch. > We observed a similar issue with objcopy when cross-compiling to > powerpc64le-linux-gnu: > > https://issues.guix.gnu.org/49417 Right but they both are for the guix build env. Can you show that problem exists in standard glibc build env and that this patch fixes some issue there. FWIW at above page the full log link is broken. Anyhow if you read the details in my revert changelog, I mentioned that for the cross toolchain, there are 2 objdump binaries. One with the prefix and one w/o. | $ find TC_INSTALL -name *objdump -exec md5sum {} \; | 5fd0b967d4977a4f8bc3a7b7a9318b1d ./bin/riscv64-unknown-linux-gnu-objdump | 5fd0b967d4977a4f8bc3a7b7a9318b1d ./riscv64-unknown-linux-gnu/bin/objdump W/o the patch, sure glibc build picks up the non-prefixed one. | /scratch/vineetg/gnu/TC_INSTALL/lib/gcc/riscv64-unknown-linux-gnu/12.2.0/../../../../riscv64-unknown-linux-gnu/bin/objdump -f /scratch/vineetg/gnu/toolchain-src/build-glibc-linux-rv32imac-ilp32/format.lds.so | sed -n 's/.*file format \(.*\)/OUTPUT_FORMAT(\1)/;T;p' > /scratch/vineetg/gnu/toolchain-src/build-glibc-linux-rv32imac-ilp32/format.lds And the non-prefixed objdump is functionally exactly same as prefixed one (as evident from md5sum above). Obviously they both produce the desired/correct "file format" - again from my changelog posted. | | $ ./bin/riscv64-unknown-linux-gnu-objdump -f ./xx.lds.so | grep "file format" | ./xx.lds.so: file format elf32-littleriscv | | $ ./riscv64-unknown-linux-gnu/bin/objdump -f ./xx.lds.so | grep "file format" The issue is this patch makes an assumption that a triplet prefixed cross binary exists, which may not always happen in multilib setups. > Maybe we should see, in your case, why “riscv32-linux-gnu-objdump -f” > reports “elf32-little” instead of “elf32-littleriscv”? Again if you read my changelog carefully I mention that in my setup riscv32-* binaries don't exist, as explained above. So lets not add that assumption in tooling. I'm not aware of how guix build env is setup. Can you check if PATH is not clobbered there - if the tooling uses -print-prog-name=objdump it should pick the correct cross objdump, not host binary. -Vineet