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: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 ".



>  BTW, the 'int n' relocation type in your code on X64 should be

> R_X86_64_GLOB_DAT

> >

>

> R_X86_64_GLOB_DAT is a dynamic relocation type. These are only emitted

> when linking a shared object or a PIE executable, which I would like

> to avoid as well.

>

> The problem with PIE executables is that the .rela.xxx sections

> emitted for each section, and the single .rela section containing the

> dynamic relocations overlap with each other, i.e., places containing

> absolute symbol addresses in the binary will appear in both, and

> emitting reloc fixups for all relocations will result in duplicates.

>

[Steven]: the current GenFw will ignore the single .rela section, because the .rela section info is 0, which target invalid section at all. See below sections example. Current GenFw will only handle the .rela.text and .rela.data relocation sections.



Section Headers:

  [Nr] Name              Type             Address           Offset

       Size              EntSize          Flags  Link  Info  Align

  [ 0]                   NULL             0000000000000000  00000000

       0000000000000000  0000000000000000           0     0     0

  [ 1] .note.gnu.build-i NOTE             0000000000000000  00000100

       0000000000000024  0000000000000000   A       0     0     4

  [ 2] .text             PROGBITS         0000000000000240  00000340

       00000000000059f8  0000000000000008  AX       0     0     64

  [ 3] .rela.text        RELA             0000000000000000  00008728

       00000000000044d0  0000000000000018   I      10     2     8

  [ 4] .data             PROGBITS         0000000000005c40  00005d40

       0000000000000a68  0000000000000000  WA       0     0     64

  [ 5] .rela.data        RELA             0000000000000000  0000cbf8

       00000000000004b0  0000000000000018   I      10     4     8

  [ 6] .rela             RELA             00000000000066c0  000067c0

       00000000000004b0  0000000000000018   A       0     0     8



> > You can see the 'int myglob' in Eli's example in

> http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-<http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/>

> shared-libraries/<http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/>. The 'int myglob' is same as your 'int n' example.

> >

> > int myglob = 42;

> > int ml_func(int a, int b)

> > {

> >     return myglob + a + b;

> > }

> >

>

> Yes, and every reference to 'myglob' will result in a GOTPCREL

> relocation. We must not emit a fixup for myglob every time.

[Steven]: Please give a real case and offer its source code to prove "every reference to 'myglob' will result in a GOTPCREL relocation".