This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]