From: "Jan Beulich" <JBeulich@novell.com>
To: "Joe Abbey" <jabbey@arxan.com>
Cc: <binutils@sourceware.org>
Subject: Re: PE32/PE32+ linking of DLLs (and EFI applications)
Date: Tue, 03 May 2011 07:45:00 -0000 [thread overview]
Message-ID: <4DBFCEBC020000780003F559@vpn.id2.novell.com> (raw)
In-Reply-To: <97BEEADB-FF81-452F-99E7-6847E3B0FAC8@arxan.com>
>>> 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
>>
prev parent reply other threads:[~2011-05-03 7:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-02 14:30 Jan Beulich
2011-05-02 17:47 ` Joe Abbey
2011-05-03 7:45 ` Jan Beulich [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DBFCEBC020000780003F559@vpn.id2.novell.com \
--to=jbeulich@novell.com \
--cc=binutils@sourceware.org \
--cc=jabbey@arxan.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).