Re: [PATCH][PR ld/10144] MIPS/BFD: Don't make debug section relocs dynamic

["Maciej W. Rozycki" <macro at codesourcery dot com>]

On Sat, 11 Dec 2010, Richard Sandiford wrote:

> >  Thanks, I'll be applying the following change on top of that change then, 
> > unless you have any further concerns.
> 
> I think this is likely to break other targets that have 32-bit ABIs
> and 64-bit architectures.  A general fix along the lines of the
> bfd.c:is32bit thing that I mentioned upthread would be needed first.

 TBH I don't think putting a lot of infrastructure into an internal 
feature meant for testing only is worth the effort unless proved 
otherwise.  I propose to include my testcases as is now and then the 
respective platform maintainers to implement TC_ADDRESS_BYTES as a need 
arises, i.e. someone notices breakage or they feel like looking for work.  
We've got around a year until the next release now, so there's plenty of 
time to catch any problems and I find the idea of rejecting a test case 
because "it may reveal breakage somewhere" backwards, sorry.  This is 
exactly what test cases are for.

 If enough evidence is found this is worth abstracting, then the 
bfd.c:is32bit idea you propose may be implemented (though I'd be more 
comfortable with a function returning a quantitative result -- there are 
undoubtedly addressing submode variations other to 64/32, e.g. 32/16, 
24/16, etc.).  The TC_ADDRESS_BYTES macro is distinct enough for all the 
places to be easily identified at that stage.

 As I believe these test cases are good enough in the current form, I will 
not make any further development in this area.  I'll be happy to commit my 
proposal as posted, but otherwise I'll dismiss it -- feel free to pick it 
up yourself, share with somebody or discard altogether.

> (That fix would also have worked for your three examples, without
> the need for a MIPS-specific patch.  The reason I didn't insist
> is that a MIPS-specific change is needed for EABI64 (32-bit ELF,
> 64-bit addresses, ick.).)

 Well, I believe TC_ADDRESS_BYTES is the least of concern with getting the 
address size right.

 While at it: M R Swami, as the CR16 maintainer would you please have a 
look at CR16 implementation of l_cons() in gas/config/tc-cr16.c?  This 
function refers to TC_ADDRESS_BYTES that is nowhere defined in that 
configuration and the .dc.a pseudo-op is therefore likely broken for that 
target.  I suspect the function has been copied and pasted from gas/read.c 
without the bit referring to TC_ADDRESS_BYTES updated accordingly.  Thank 
you.

  Maciej