Re: [PATCH] Revert "Correctly determine libc.so 'OUTPUT_FORMAT' when cross-compiling."

[Vineet Gupta <vineetg@rivosinc.com>]

On 11/30/22 04:39, Adhemerval Zanella Netto wrote:
>
> On 28/11/22 20:25, Palmer Dabbelt wrote:
>> On Tue, 22 Nov 2022 18:59:32 PST (-0800), Vineet Gupta wrote:
>>> 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)`.
>> Sounds like a linker bug?
>>
>>> 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.
>> Though we _could_ have riscv32-* and riscv64-* binaries (and also riscv*- too), it just doesn't make much of a difference as the riscv64-* binaries can target everything.  If the answer here is just "fix riscv-gnu-toolchain" that seems reasonable to me, but also happy to avoid touching that so
>>
>> Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
>>
>> Though some sort of global reviewer should take a look here, I definately don't understand the glibc build process well enough to review this one.
>>
>
> I think the question is whether we need to set OBJDUMP and/or can override
> or if we should derive the tools solely from CC.  It make sense for later,
> since using a different binutils than the one CC is meant to use not always
> guarantee that compiler will emits all supports instructions or ABI.

Certainly the ability to override OBJDUMP (actually all of binutils) 
seems useful. However the issue with the original patch was it assuming 
that triplet prefixed binary exists and even worse it silently falling 
back to host binary if it fails to find one. If we really want to 
support the original patch, it should add a fallback of using $CC 
-print-prog-name if the triplet binary search fails.

But as it stands, riscv multilib toolchain builds are currently hosed 
because of this.

-Vineet

> The build-many-glibc.py sets the OBJDUMP, so I think it would be good to
> also remove its usage (since with this patch OBJDUMP can not be override
> anymore).  In fact the only way to override the binutils with
> LIBC_PROG_BINUTILS is to use --with-binutils (which has some issues [1]
> though).
>
> The --with-binutils is also a developer options, so I wonder if we should
> simplify the build process by removing it along with LIBC_PROG_BINUTILS, and
> replace with a new macro that checks whether the tools is set, otherwise uses
> the CC with -print-prog-name for default case.
>
> It would continue to provide a way to override binutils tools (for development
> and testing) and simplify the build process (one less configure option).  GUIX
> can then override OBJDUMP if it need (and it was not clear not me why
> CC -print-prog-name does not work on this environment).
>
> [1] https://patchwork.sourceware.org/project/glibc/patch/20221115193159.173838-2-adhemerval.zanella@linaro.org/