This is the mail archive of the 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" <> 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

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.


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