PE32/PE32+ linking of DLLs (and EFI applications)

PE32/PE32+ linking of DLLs (and EFI applications)

[Jan Beulich]

How do ld-linked DLLs work when there don't seem to be any base
relocations getting emitted? While imo for DLLs this should be the
default anyway, is there a magic switch that I'm overlooking? EFI
applications also require relocations to be emitted...

While the hack called "dlltool" isn't really an option anyway, it's not
even possible to use it as the file generated with --base-file is empty
(I assume because data gets written to it only for COFF input files,
but on Linux all of the inputs are [obviously] ELF).

Thanks, Jan

Re: PE32/PE32+ linking of DLLs (and EFI applications)

[Joe Abbey]

Jan,

For PE32, gcc emits PIC code which uses a call instruction to obtain the current EIP. After that, an offset is subtracted (usually relative the the GOT). Thus allowing the binary to be memory mapped at any base address. 

In PE32+, most compilers generate PIC via RIP-relative addressing mode. 

Some compilers still require linker-generated base relocations, and ld will create them if the COFF relocation is of the correct type. 

I have no familiarity with EFI applications, however. 

Does this help?

Joe

Sent from my iPhone

On May 2, 2011, at 7:29 AM, "Jan Beulich" <JBeulich@novell.com> wrote:

> How do ld-linked DLLs work when there don't seem to be any base
> relocations getting emitted? While imo for DLLs this should be the
> default anyway, is there a magic switch that I'm overlooking? EFI
> applications also require relocations to be emitted...
> 
> While the hack called "dlltool" isn't really an option anyway, it's not
> even possible to use it as the file generated with --base-file is empty
> (I assume because data gets written to it only for COFF input files,
> but on Linux all of the inputs are [obviously] ELF).
> 
> Thanks, Jan
> 

Re: PE32/PE32+ linking of DLLs (and EFI applications)

[Jan Beulich]

>>> On 02.05.11 at 19:46, "Joe Abbey" <jabbey@arxan.com> wrote:
> Jan,
> 
> For PE32, gcc emits PIC code which uses a call instruction to obtain the 
> current EIP. After that, an offset is subtracted (usually relative the the 
> GOT). Thus allowing the binary to be memory mapped at any base address. 
> 
> In PE32+, most compilers generate PIC via RIP-relative addressing mode. 
> 
> Some compilers still require linker-generated base relocations, and ld will 

Or assembly code, as in the case I'm looking at.

> create them if the COFF relocation is of the correct type. 

No, at least not as far as I was able to find out. If you know
differently, can you please point me to how this works and/or
where this is implemented?

Jan

> I have no familiarity with EFI applications, however. 
> 
> Does this help?
> 
> Joe
> 
> Sent from my iPhone
> 
> On May 2, 2011, at 7:29 AM, "Jan Beulich" <JBeulich@novell.com> wrote:
> 
>> How do ld-linked DLLs work when there don't seem to be any base
>> relocations getting emitted? While imo for DLLs this should be the
>> default anyway, is there a magic switch that I'm overlooking? EFI
>> applications also require relocations to be emitted...
>> 
>> While the hack called "dlltool" isn't really an option anyway, it's not
>> even possible to use it as the file generated with --base-file is empty
>> (I assume because data gets written to it only for COFF input files,
>> but on Linux all of the inputs are [obviously] ELF).
>> 
>> Thanks, Jan
>>