Re: [GOLD] Support --icf=safe with -pie for x86_64

[Alan Modra <amodra at gmail dot com>]

On Fri, Jan 13, 2017 at 04:28:36PM -0800, Rahul Chaudhry wrote:
> 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?

I don't know.  I could look at gold source and figure out the answer,
but it's really your job to convince Cary and others that what you're
doing is safe.  ie. Prove to some level of confidence that comparing
the byte before r_offset of an R_X86_64_PC32 against 0xe8 really is a
valid test for a call.  Note that I'm *not* saying your patch was
wrong.  It may in fact be the case that all insns that could use an
R_X86_64_PC32 besides a call will have modrm or sib bytes different
to 0xe8.  Ditto for the other opcodes you test.  It might also be the
case that gcc won't put jump tables using R_X86_64_PC32 in code
sections.  (What crazy assembly programmers do is another story.)

x86 code editing/analysis is difficult.  If I had to do it, I think
I'd define a few more relocs for use in code so that you could find
the start of an instruction.  You could even do that without bloating
objects with extra relocs.  eg. instead of R_X86_64_32 in code you'd
use a series of relocs that all behave like R_X86_64_32 for relocation
but also say something about the insn opcode:
  R_X86_64_32_I1 insn opcode one byte before r_offset
  R_X86_64_32_I2 insn opcode two bytes before r_offset
  etc.

-- 
Alan Modra
Australia Development Lab, IBM