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

[Luis Machado <luis.machado@arm.com>]

On 5/6/22 03:35, Hans-Peter Nilsson via Binutils wrote:
>> From: Alan Modra <amodra@gmail.com>
>> Date: Fri, 6 May 2022 02:56:46 +0200
> 
>> As is often the case the truth is more complicated than it would
>> appear on the surface.
> 
> While aiming for the bigger picture is a good thing, you're
> here letting the perfect be the enemy of the good.  A
> reasonable step would be to get all targets want64=true, to
> avoid this annoying host-32/64-bit difference.
> 
>>   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
> 
> But seeing it as "calculating in 32 bits" is just So Wrong!
> 
> I admit I worked around this missing tracking of
> subexpression signeness and papering over the gas bug by
> just making the problem go away for *this* port.
> 
> Now 20 years down the line, when 64-bit is the norm, IMHO
> that's a preferred solution (while waiting for Someone to
> rewrite the expression bits, but it also happens to get
> host-size-uniform address output).
> 
> brgds, H-P

It does seem like trying to adjust code like this is a bit dangerous and 
may lead to some breakage that is hard to exercise.

 From a "--enable-targets=all" and GDB build's perspective, making these 
targets use a 64-bit BFD and defining disassembler functions 
conditionally according to the presence of a 32-bit BFD or 64-bit BFD 
causes some issues.

I think most of the problem lies in the fact that sim/ wants to build 
everything (all sims, for all targets), regardless of whether we're 
using a 32-bit BFD or 64-bit BFD. And that leads to undesirable build 
breakages for 32-bit builds.

If a disassembler function is not defined properly for GDB, then that 
also leads to internal errors in GDB's testsuite, as the architecture 
will be visible to GDB, and it will cycle through all of the available 
architectures doing multiple checks.

I'd expect at least a clean 32-bit build to go through, and that has 
been my goal so far. And I did notice some files were placed incorrectly 
(ones using 64-bit BFD's in the 32-bit BFD list or the other way 
around). Then again, it seems the current mechanism is to keep 
everything in sync by hand, which is a bit fragile.