public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: b95705030@ntu.edu.tw
Cc: binutils@sourceware.org
Subject: Re: static link with relocations
Date: Sat, 17 Apr 2010 18:56:00 -0000	[thread overview]
Message-ID: <w2r6dc9ffc81004171156gdb35d501n2186fc6ee8de3d65@mail.gmail.com> (raw)
In-Reply-To: <20100418024035.83245zdnmlwkiuub@wmail1.cc.ntu.edu.tw>

On Sat, Apr 17, 2010 at 11:40 AM,  <b95705030@ntu.edu.tw> wrote:
> Hello
>
> [顯示引述 - 13 行][隱藏引述]
> I want to port binutils to a platform(EFI Binary Code Virtual Machine). The
> image of that platform is static link, but they contain relocations.
>
> Does binutils have build in assumption that static image don't contain
> relocations??(ie. Does binutils support the model that static image contain
> relocations??)
> Do they use the same format as native EFI codes? If yes,
> you need to link as PIE. I fixed an PIE bug recently for EFI:
>
> http://www.sourceware.org/bugzilla/show_bug.cgi?id=11396
> Yes, they use the same format as native EFI codes(object file format COFF,
> excutable format PE32+).
> The problem I ask is because of a discussion of EDK mailing list.
> http://sourceforge.net/mailarchive/forum.php?thread_name=7C0E3215-191D-4B58-BC2B-D273281608F1%40apple.com&forum_name=edk2-devel
>
> The memory model of EFI in IA32 is Basic Flat Model(3.2.1 in Intel(R) 64 and
> IA-32 Architectures Software Developer's Manual Volume 3A:System Programming
> Guide, Part 1), which means every selector defines the entire address space.
>
> Because PE/COFF is designed to be run at any address, and determined the
> relocations at loading time. The load address could also change if the
> sequence of loads was different. The source code of loader in EFI is:
> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
>
> So I wondering whether binutils support static link image with relocation
> model. I have survey the bug you fixed. In my opinion, binutils support this
> model, Is it??

Yes.

> tnanks for you to be my mentor.
>

You are welcome.


-- 
H.J.

  reply	other threads:[~2010-04-17 18:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-16 20:03 b95705030
2010-04-16 20:24 ` H.J. Lu
2010-04-17 18:40   ` b95705030
2010-04-17 18:56     ` H.J. Lu [this message]
2010-04-19 18:07       ` b95705030
2010-04-19 19:20         ` H.J. Lu
2010-04-20 13:39           ` b95705030
2010-04-20 13:49             ` H.J. Lu

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=w2r6dc9ffc81004171156gdb35d501n2186fc6ee8de3d65@mail.gmail.com \
    --to=hjl.tools@gmail.com \
    --cc=b95705030@ntu.edu.tw \
    --cc=binutils@sourceware.org \
    /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).