This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH][PR ld/10144] MIPS/BFD: Don't make debug section relocs dynamic
On Thu, 11 Nov 2010, Richard Sandiford wrote:
> > I agreed with you .dc.a is the right approach and have only been
> > concerned about the correctness of the implementation for MIPS targets or
> > elsewhere.
> >
> > Given your consideration I have just now looked into it as well and it
> > looks to me our MIPS target should simply override TC_ADDRESS_BYTES with
> > its own function that will return 8 for the n64 ABI and the EABI and 4
> > with all the other ABIs (I reckon o64 assumes 32-bit addresses too,
> > correct?), or the currently selected ISA-implied address size if no ABI
> > has been selected, such as with the ECOFF targets -- we have that logic
> > implemented elsewhere already, so the return value of function should
> > reduce to an expression along the lines of (4 << HAVE_64BIT_ADDRESSES).
> > The existence of the macro itself suggests this is something that was
> > intended for some platforms to do with the original implementation even
> > though no target makes such an override at the moment.
> >
> > Or do you have a documentation reference for .dc.a that claims it should
> > behave otherwise?
>
> Well, the point is: this kind of situation is by no means exclusive
> to MIPS. Plenty of other targets allow 64-bit architecturees to use a
> 32-bit ABI and a 32-bit file format. If .dc.a was supposed to select
> the ABI address size, it could/should/would have used other hooks to
> get that size. E.g. the code in bfd.c:is32bit would probably have
> been a better starting point.
Maybe, maybe not. This piece doesn't seem to be used particularly
extensively and we have many 64-bit targets that support a 32-bit ABI, so
internally they must have come up with their own ways of determining the
size of the address, just as we did with the MIPS target.
> As it stands, .dc.a means the architecture address size for all platforms.
> We shouldn't change the meaning on MIPS alone and introduce an inconsistency.
> And IMO we shouldn't change the meaning at all, given that the directive
> has already been released into the wild. We could of course add a new
> directive, but I personally don't think it's worth it. You'd have to
> convince another maintainer if you wanted to do that. :-)
OK, cc-ed Alan Modra, the original offender. ;) Perhaps he'll be able to
provide input about the directive and its origins.
I stand by what I stated. The pseudo-op has been out, but it's broken
and useless for an ILP32 ABI running on a 64-bit target. There's no
notion of a 64-bit address for such targets, and they need not even
provide a 64-bit reloc that the pseudo-op requires. We happen to have
such a reloc in our n32 backend, but frankly I have no idea what it was
added for -- perhaps anticipating this directive. ;)
Anyone relying on the current implementation of .dc.a on such a target
should have filed a bug in the first place and I don't think we are
obligated to provide bug compatibility for such obvious problems. I
suspect the knowledge of this pseudo-op is limited and hardly anybody uses
it, mainly because it's not documented in the GAS manual (I doubt anyone
seriously considers studying sources for feature discovery), so you're
almost certainly worrying about a scenario the probability of which is
epsilon.
Actually the problem with n32 (and the unexpected R_MIPS_64 reloc) is no
psABI has ever been written up; at least I have never heard of such a
document. The closest I know of are SGI's: "MIPSpro N32 ABI Handbook" and
"MIPSpro Assembly Language Programmer's Guide," but they are more
programmer-oriented manuals than proper ELF-level specifications. In the
end my understanding is our implementation has been crafted based on a
combination of the two said manuals, n64's "64-bit ELF Object File
Specification" and o32's "MIPS RISC Processor Supplement" to the SVR4 ABI,
as well as observation of what IRIX tools do.
> Please just go ahead with your original is_elf64 test.
Hmm, I guess we can fix it up if we ever come up with a constructive
conclusion wrt the .dc.a mess.
Maciej