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] MIPS/BFD: Handle linker garbage collection with n64 relocs


"Maciej W. Rozycki" <macro@linux-mips.org> writes:
>  The fix below removes the problem and causes no regressions with said 
> modified mips64-linux-gnu configuration nor a pristine mips-linux-gnu one.  
> The RELOC_AGAINST_DISCARDED_SECTION macro has a bit weird semantics, it's 
> not really intended to behave like a function call, and I think there's 
> little point in making it do (e.g. adding argument protection throughout), 
> if at all possible.  Therefore some unusual syntactic sugar had to be 
> added around the macro reference, so that its expansion can be executed 
> three times consecutively over a relocation triplet.  This is explained in 
> the comment included with the change itself.  The new code also avoids a 
> duplicate call to MIPS_ELF_RTYPE_TO_HOWTO, hence a bit unusual form of the 
> loop introduced.

I think it'd be better (and cleaner) to handle
bed->s->int_rels_per_ext_rel in RELOC_AGAINST_DISCARDED_SECTION
instead.

The patch as posted isn't quite correct, because the "middle"
relocation in a triple doesn't define a relocation field.
E.g. for the common %hi(%neg(%gp_rel(...))) case, the middle
%neg is a 64-bit relocation, but we don't want R_A_D_S to clear
a 64-bit field.

Richard


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