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: "Rahul Chaudhry via binutils" <binutils at sourceware dot org>
- To: Alan Modra <amodra at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>, Cary Coutant <ccoutant at gmail dot com>, Sriraman Tallam <tmsriram at google dot com>
- Date: Fri, 13 Jan 2017 16:28:36 -0800
- 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> <20170113222348.GV32333@bubble.grove.modra.org>
- Reply-to: Rahul Chaudhry <rahulchaudhry at google dot com>
On Fri, Jan 13, 2017 at 2:23 PM, Alan Modra <amodra@gmail.com> wrote:
> 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.
For a jump table containing relocations, it should be fine to treat all of them
as function calls/jumps, right?
If anything, the check for opcode 1-2 bytes before r_offset is likely to fail
and classify the relocation as address taken instead of a function call. This
is the reverse problem of above, it may result in a function section not
getting folded, that could have been folded safely.
--
Rahul