Don't compile some opcodes files when bfd is 32-bit only

[Alan Modra]

On Thu, Dec 02, 2021 at 12:19:37AM -0500, Mike Frysinger wrote:
> On 02 Dec 2021 09:31, Alan Modra wrote:
> > On Fri, Nov 26, 2021 at 01:01:12PM -0500, Mike Frysinger wrote:
> > > On 12 Nov 2021 19:07, Alan Modra via Binutils wrote:
> > > > 	* Makefile.am (TARGET_LIBOPCODES_CFILES): Split into..
> > > > 	(TARGET64_LIBOPCODES_CFILES): ..this and..
> > > > 	(TARGET32_LIBOPCODES_CFILES): ..this.
> > > > 	(ALL_MACHINES): Likewise split to
> > > > 	(ALL64_MACHINES, ALL32_MACHINES): ..this.
> > > > 	* disassemble.c: Define some ARCH_* when ARCH_all only if BFD64.
> > > > 	* configure.ac (BFD_MACHINES): Defined depending on BFD_ARCH_SIZE.
> > > > 	* Makefile.in: Regenerate.
> > > > 	* configure: Regenerate.
> > 
> > > riscv supports 32-bit & 64-bit.  this move is breaking 32-bit builds of
> > > 32-bit riscv sims.
> > > 
> > > testing with --host=i686-linux-gnu --enable-targets=all --enable-sim:
> > > make[3]: Entering directory '.../sim/riscv'
> > >   CCLD   run
> > > ...sim/riscv/sim-main.c:71: error: undefined reference to 'riscv_gpr_names_abi'
> > > ...sim/riscv/sim-main.c:153: error: undefined reference to 'riscv_gpr_names_abi'
> > > ...sim/riscv/sim-main.c:652: error: undefined reference to 'riscv_gpr_names_abi'
> > > ...sim/riscv/sim-main.c:800: error: undefined reference to 'riscv_gpr_names_abi'
> > > ...sim/riscv/sim-main.c:1108: error: undefined reference to 'riscv_opcodes'
> > 
> > Yes, I moved bpf back into TARGET32_LIBOPCODES_CFILES for a similar
> > problem with the bpf sim.  That might have been a mistake.  For the
> > binutils, bpf opcode support is useless without bpf bfd support,
> > because a 32-bit bfd can't load an ELF64 object file.  Not even as the
> > generic elf64-little or elf64-big targets.
> > 
> > I think it is also useless for sim.  On my 32-bit sim build:
> > $ ~/build/gas/bpf-none/gas/as-new -I ~/src/binutils-gdb/sim/testsuite/bpf ~/src/binutils-gdb/sim/testsuite/bpf/alu.s -o alu.o
> > $ ~/build/gas/bpf-none/ld/ld-new -Ttext=0 -o alu alu.o
> > $ ./run --memory-size=4Mb alu
> > run: "alu" is not an object file: file format not recognized
> > 
> > Doing the same on a 64-bit sim build results in:
> > $ ./run --memory-size=4Mb alu
> > pass
> > exit 0 (0x0)
> > 
> > Mike, I question your "working" statement here:
> > https://sourceware.org/pipermail/binutils/2021-November/118569.html
> > 
> > Obviously, moving riscv back into TARGET32_LIBOPCODES_CFILES won't fix
> > anything, since riscv was the reason for removing objects from
> > libopcodes.
> 
> at that point i was defining "working" as "it built & linked fine".

Heh, OK I'm going to revert 7a53275579e7.

>  i don't
> have specific familiarity with the bpf port as i didn't author it.  i only
> just finished overhauling the sim build & test logic to support testing in a
> multitarget build so they can all (or most at this point) be tested at the
> same time.  and i can see the same runtime error you see now too.  is the
> 64-bit bfd setting easy to detect in subdirs ?

I used
    if grep '#define BFD_ARCH_SIZE 64' ../bfd/bfd-in3.h > /dev/null
in opcodes/configure.ac and made configure-opcodes depend on
configure-bfd in the top level Makefile.def.  bfd-in3.h is made during
bfd configure.

>  if so, i think we can change
> the sim to skip 64-bit-only ports if 64-bit bfd isn't available.

Yes, I think that is the right way to go for --enable-targets=all.

> riscv i think is a bit diff in that it supports 32-bit & 64-bit.

You can argue that with the riscv maintainers.  ;-)

Note that if a user specifically wants a riscv32 sim then using
--target=riscv32-elf or even --enable-targets=riscv32-elf will get
them a 64-bit bfd.

-- 
Alan Modra
Australia Development Lab, IBM