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 Wed, 10 Nov 2010, Richard Sandiford wrote:

> > OK, will try to fix that this weekend.  I still think dc.a is the
> > right thing for the test, but see below.
> 
> So, I looked at it this weekend, and I longer think dc.a is the right
> thing for the test.  It seemed so well suited, but as you point out,
> it's based on the ISA address size rather than the ABI or file
> format address size, which probably makes it of limited use.  Oh well.

 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?  Where have these .dc.* pseudo-ops come from anyway?  
We seem to have collected plenty of various directives providing 
overlapping functionality with confusingly subtle semantics differences, 
sigh...

 And while at it I have noticed the #ifdef TC_ADDRESS_BYTES clauses 
throughout gas/read.c are rather pointless as the file defines the macro 
if not already present.  Was there a specific reason to have them?  If 
not, then I'll make a patch to remove them.  There's also related dead 
code in gas/config/tc-cr16.c -- not sure what to do about it.

> Please go ahead with your original is_elf64 patch, and sorry for the noise.

 I'd rather fixed .dc.a, sorry.  As this is not something critical for 
2.21, let me defer it until I'm done with the next (I dare not say "last") 
iteration of the microMIPS change.

  Maciej


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