[PATCH, v2] Fix 32-bit build for --enable-targets=all

[Luis Machado]

On 4/26/22 14:22, Alan Modra wrote:
> On Tue, Apr 26, 2022 at 10:07:53AM +0200, Jose E. Marchesi wrote:
>>
>> Hi Alan.
>>
>>> On Mon, Apr 25, 2022 at 08:40:54AM +0100, Luis Machado wrote:
>>>> On 4/24/22 15:58, Joel Brobecker wrote:
>>>>> Looking at this patch, I think you you may not have seen Alan's
>>>>> comment, which je sent on Apr 18, saying:
>>>>>
>>>>>       https://sourceware.org/pipermail/gdb-patches/2022-April/187960.html
>>>>>       | Anything that requires 64-bit BFD support does not belong in
>>>>>       | TARGET32_LIBOPCODES_CFILES.  In fact, the whole point of
>>>>>       | TARGET32_LIBOPCODES_CFILES was to fix --enable-targets=all breakage on
>>>>>       | 32-bit hosts without --enable-64-bit-bfd.  Why would you want to put
>>>>>       | bpf here?  It's a 64-bit target!
>>>>>
>>>>> (I see that you weren't in the list of direct recipients for that email)
>>>>>
>>>>
>>>> Yes, it looks that way.
>>>>
>>>> Unfortunately --enable-targets=all never really worked OK for 32-bit builds
>>>> after splitting 64/32 targets. It is not clear to me if there are bugs
>>>> elsewhere that are preventing a clean build, but right now it doesn't look
>>>> buildable at all.
>>>>
>>>> Alan?
>>>
>>> The major problem I have with your patch is that all it does is sweep
>>> a problem under the rug.  While it may fix a build breakage I doubt
>>> that it actually improves anything for users.  For example, if I apply
>>> your patch for a 32-bit --enable-targets=all binutils build, then
>>> attempt to disassemble one of the bpf gas testsuite objects:
>>>
>>> $ ~/build/gas/all32/binutils/objdump -dr tmpdir/lddw.o
>>> /home/alan/build/gas/all32/binutils/objdump: tmpdir/lddw.o: file format not recognized
>>>
>>> That's due to lack of the required support from bfd/elf64-bpf.c to
>>> load bpf object files into BFD.
>>
>> Could you please elaborate on that?
>>
>> What is it in elf64-bpf.c that must be improved in order to support
>> 32-bit --enable-targets=all binutils?
> 
> It isn't that elf64-bpf.c is missing something, it's that the entire
> file is not built on a 32-bit host with --enable-targets=all and
> without --enable-64-bit-bfd.
> 
>>> I think you'll find a similar result for the other targets your patch
>>> touches, and not just with objdump but with everything else that uses
>>> libbfd.
>>>
>>> There is also a minor problem with the patch in that it adds entries
>>> to TARGET32_LIBOPCODES_CFILES without removing the corresponding
>>> entries from TARGET64_LIBOPCODES_CFILES.  Similarly for the defines in
>>> opcodes/disassemble.c.
> 

After some investigation, it seems the bpf target is a bit of a corner 
case. It's within the 64-bit bfd group, so libopcodes gets built only if 
--enable-64-bit-bfd. Otherwise, libopcodes doesn't include bpf.

The bpf sim gets built regardless of having a 32-bit bfd or 64-bit bfd, 
so in the case of a 32-bit build with --enable-targets=all (and no 
--enable-64-bit-bfd), libopcodes doesn't include bpf, causing a libsim 
linking failure due to missing symbols (.

Things work fine for 64-bit though. I think the fix would involve not 
building the sim if the bpf files are not linked into libopcodes.

--

libsim.a(sim-close.o): In function `sim_close':
/builds/binutils-gdb-armhf-bionic/sim/bpf/../../../../repos/binutils-gdb/sim/bpf/../common/sim-close.c:43: 
undefined reference to `bpf_cgen_cpu_close'
libsim.a(sim-if.o): In function `sim_open':
/builds/binutils-gdb-armhf-bionic/sim/bpf/../../../../repos/binutils-gdb/sim/bpf/sim-if.c:166: 
undefined reference to `bpf_cgen_cpu_open_1'
/builds/binutils-gdb-armhf-bionic/sim/bpf/../../../../repos/binutils-gdb/sim/bpf/sim-if.c:179: 
undefined reference to `bpf_cgen_init_dis'
collect2: error: ld returned 1 exit status