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

[Alan Modra]

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'
> -mike

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.

-- 
Alan Modra
Australia Development Lab, IBM