This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


>>> 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
>> 




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]