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

[Alan Modra]

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.  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.

-- 
Alan Modra
Australia Development Lab, IBM