Re: [PATCH] Don't define ARCH_cris for BFD64

[Alan Modra <amodra@gmail.com>]

On Thu, May 05, 2022 at 12:11:29PM +0100, Pedro Alves wrote:
> 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?  

As is often the case the truth is more complicated than it would
appear on the surface.  I think the cris support works fine with a
32-bit bfd.  It's just that the cris testsuite has expressions
that overflow 32 bits.

gas/testsuite/gas/cris/shexpr-1.s has this expression:

    ((0x17<<23)+((0xfede4194/8192)<<4)+8)

It evaluates to 0x0bff6f28 when calculating in 64 bits, but to
0x0b7f6f38 when calculating in 32 bits, because 0xfede4194 is
−0x121be6c as a signed 32-bit number and the division is done using
signed bfd_vma values.

gas/testsuite/gas/cris/range-err-1.s has three uses of 0xffffffff that
don't give the expected error when used in 8-bit and 16-bit fields if
bfd_vma is 32 bits.  That's because 0xffffffff is -1, and apparently
-1 is OK for those fields.

No doubt gas expression evaluation could be improved.  eg. We could
use C rules for whether constants are signed or unsigned, and track
that through expression evaluation.  The thing that give me pause in
recommending that (or doing it myself) is that I suspect it might open
up a can of worms assembling 64-bit target code, discovering lots of
places where compiler output or user assembly isn't clean.  A simple
example is that 0xffffffffffffffff would no longer be equal to -1, and
therefore might trigger field overflow errors.

-- 
Alan Modra
Australia Development Lab, IBM