[PATCH] Don't define ARCH_cris for BFD64

[Pedro Alves]

On 2022-05-04 23:37, Alan Modra via Binutils wrote:

> OK, so this means we have two slightly different versions of cris
> support.  Configured to support cris directly with --target or
> --enable-targets mentioning one of the cris tuples will always give
> you a 64-bit bfd.  On a 32-bit host configured with
> --enable-targets=all you'll get a 32-bit bfd, and miss some support
> for explicitly choosing and displaying targets.  (The #ifdef comments
> in config.bfd are used to generate targmatch.h, which gets included
> into targets.c.)

I guess I don't understand the logic fully, and if you have the patience for me, I'd like
to understand it better.

In the --enable-targets=all case with a 32-bit bfd, it seems counterintuitive to want to be able to choose
and display cris, if its bfd supposedly wants 64-bit, given want64=true.  If bfd says cris wants
64-bit bfd, and you have a 32-bit bfd, it seems weird to build it in 32-bit mode, and let users choose and
use it?  

I just tried a 32-bit --enable-targets=all --disable-sim build of current master, and indeed we end
up with these files built:

 $ ls bfd/*cris*
 bfd/aout-cris.lo  bfd/aout-cris.o  bfd/cpu-cris.lo  bfd/cpu-cris.o  bfd/elf32-cris.lo  bfd/elf32-cris.o

however, those are built with a 32-bit bfd ("#define BFD_ARCH_SIZE 32" in bfd/bfd.h), which if we
trust win64=true (and 56fbd041853a "Fix gas/22304 by forcing a 64-bit bfd for cris*-*") is not
supposed to happen.

Currently, gas --enable-targets=all isn't very useful, as you can't make it assemble
for non-primary targets AFAIK, but if it did, then a 32-bit --enable-targets=all build would
assemble cris using 32-bit bfd, which I assume would be affected by gas/22304 again.

Unlike gas however, a 32-bit --target-targets=all gdb knows how to cross-debug cris and will happily
do it, again with a 32-bit bfd.  Maybe the gas issue that led to making cris want 64-bit bfd doesn't
affect any other tool, so meh, who cares, right?, but it still seems counterintuitive/strange
to have tool dependencies or mismatches like that.

Shouldn't instead BFD64 / want64 / TARGET64_LIBOPCODES_CFILES all agree in principle
so we avoid these tool mismatches, where a port says it wants 64-bit bfd but then it
can happen to be built and be used with 32-bit anyhow?

Sometimes I wonder whether 32-bit bfd_vma is still worth it, though.
FWIW, GDB always has 64-bit CORE_ADDR nowadays, even on 32-bit hosts.

Anyhow, I got confused trying to figure out how all this is supposed to work, and I realize
that the above may sound like a rant, though it was not intended, so sorry if it does.
I guess other people who read this code for the first time may end up scratching their
heads too.