This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [GOLD] Support --icf=safe with -pie for x86_64
- From: Alan Modra <amodra at gmail dot com>
- To: Rahul Chaudhry <rahulchaudhry at google dot com>
- Cc: Binutils <binutils at sourceware dot org>, Cary Coutant <ccoutant at gmail dot com>, Sriraman Tallam <tmsriram at google dot com>
- Date: Sat, 14 Jan 2017 08:53:48 +1030
- Subject: Re: [GOLD] Support --icf=safe with -pie for x86_64
- Authentication-results: sourceware.org; auth=none
- References: <CAJRD=oqcd2y03pjosB6ifygwGv1wO0VgPFFqvTiSOvFhaqisJA@mail.gmail.com> <20170113012324.GO32333@bubble.grove.modra.org> <CAJRD=opJc+d+RENAfdndtyB2mjSHLTgXfhua2KF=R46dtkA-4Q@mail.gmail.com>
On Fri, Jan 13, 2017 at 12:10:55PM -0800, Rahul Chaudhry wrote:
> > Also, might you have an R_X86_64_PC32 in data and so be looking at the
> > high byte of the previous word?
>
> Not sure what you mean here, but this code is only called for text sections, so
OK, if you know it is text then you're a lot safer, but even so..
> we can be sure that the relocation offset is part of an instruction. Did you
> mean an instruction with an encoding containning opcode bytes, followed by
> immediate operand, which is followed by a R_X86_64_PC32 relocation?
.. what if you have a jump table of 32-bit relative offsets in text?
I think such a table would use R_X86_64_PC32 relocs if the
destinations were in other sections or other files. If your new code
happens to look at one of those relocs then one byte before r_offset
is not part of an instruction using an R_X86_64_PC32 reloc.
--
Alan Modra
Australia Development Lab, IBM