[PATCH][PR ld/10144] MIPS/BFD: Don't make debug section relocs dynamic
Maciej W. Rozycki
macro@codesourcery.com
Mon Dec 13 16:51:00 GMT 2010
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
More information about the Binutils
mailing list