Re: [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

["Shi, Steven" <steven.shi@intel.com>]

> On 1 August 2016 at 09:54, Shi, Steven <steven.shi@intel.com> wrote:
> >> On 1 August 2016 at 09:19, Shi, Steven
> <steven.shi@intel.com<mailto:steven.shi@intel.com>> wrote:
> >> >> >>
> >> >> >> The fact that it works does not make it safe. Having multiple fixups
> >> >> >> for the same symbol in the .reloc section is a problem, and so is
> >> >> >> reapplying GOTPCRELX to places where the original instruction has
> >> been
> >> >> >> replaced by the linker.
> >> >> >>
> >> >> > [Steven]: I still don't understand why there will be multiple fixups for
> the
> >> >> same symbol in the .reloc section?
> >> >> >
> >> >>
> >> >> Remember this example
> >> >>
> >> >> >> > int n;
> >> >> >> > int f () { return n; }
> >> >> >> > int g () { return n; }
> >> >> >> > int h () { return n; }
> >> >>
> >> >> If every 'return n' results in a GOTPCREL relocation, how are you
> >> >> going to make sure that the GOT entry for 'n' is only fixed up a
> >> >> single time?
> >> >
> >> > [Steven]: the 'return n' will not result in relocation, but the 'int n' will
> result
> >> in the relocation in GOT. The three 'return n' will point to the same 'int n'
> >> relocation item. So, we need only fixup 'int n' once, all three 'return n' will
> >> use the correct global 'n' value.
> >>
> >> Every 'return n' will result in a GOTPCREL relocation against n. And
> >> your code emits a relocation for the GOT entry every time.
> >>
> > [Steven]: I don't think so. please give a real case and offer its source code
> to prove " Every 'return n' will result in a GOTPCREL relocation against n ".
> >
> 
> Compiling the code above using
> 
> gcc -c -O -fpic /tmp/pie.c -o pie.o
> 
> and dumping it using
> 
> readelf -r pie.o
> 
> gives me
> 
> Relocation section '.rela.text' at offset 0x250 contains 3 entries:
>   Offset          Info           Type           Sym. Value    Sym. Name + Addend
> 000000000003  000a0000002a R_X86_64_REX_GOTP 0000000000000004 n -
> 4
> 00000000000d  000a0000002a R_X86_64_REX_GOTP 0000000000000004 n -
> 4
> 000000000017  000a0000002a R_X86_64_REX_GOTP 0000000000000004 n -
> 4
> ...
[Steven]: In this example, the pie.o is just the object file which is not linked. And if you link this pie.o file, the linker will solve all these three R_X86_64_REX_GOTP symbol with same 'int n' symbol address, and will create only one relocation item for 'int n' in the linked executable relocation section. So, we only need fixup once for the 'int n' in the linked executable.

Thanks
Steven