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

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 1 August 2016 at 09:19, Shi, Steven <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.

 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.

> You can see the 'int myglob' in Eli's example in 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.