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: [GOLD] Support --icf=safe with -pie for x86_64

On Fri, Jan 13, 2017 at 2:23 PM, Alan Modra <> 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.


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