This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] MIPS/BFD: Handle linker garbage collection with n64 relocs
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: "Maciej W. Rozycki" <macro at linux-mips dot org>
- Cc: binutils at sourceware dot org
- Date: Tue, 10 Apr 2012 19:37:11 +0100
- Subject: Re: [PATCH] MIPS/BFD: Handle linker garbage collection with n64 relocs
- References: <alpine.LFD.email@example.com>
"Maciej W. Rozycki" <firstname.lastname@example.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
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.