This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: PE32/PE32+ linking of DLLs (and EFI applications)
- From: "Joe Abbey" <jabbey at arxan dot com>
- To: "Jan Beulich" <JBeulich at novell dot com>
- Cc: <binutils at sourceware dot org>
- Date: Mon, 2 May 2011 10:46:50 -0700
- Subject: Re: PE32/PE32+ linking of DLLs (and EFI applications)
- References: <4DBEDC06020000780003F2F5@vpn.id2.novell.com>
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
>