From: Jerry Van Baren <gerald.vanbaren@ge.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Changing u-boot relocation scheme
Date: Fri, 25 Jul 2008 15:03:43 -0400 [thread overview]
Message-ID: <488A238F.5010806@ge.com> (raw)
In-Reply-To: <20080725205017.564dedff@siona.local>
Haavard Skinnemoen wrote:
> On Fri, 25 Jul 2008 11:21:12 -0400
> Jerry Van Baren <gerald.vanbaren@ge.com> wrote:
>
>> The relocation information is in the ELF file until and unless we remove
>> it. "Normal" ELF executables retain that relocation information... that
>> is exactly what the "L" (it) is for. The linux loader (elf loader)
>> loads an executable into an arbitrary memory location and relocates it
>> by fixing up addresses based on the relocation table.
>
> You're mixing two different relocation tables. Statically linked
> executables (like u-boot) normally don't have any relocation
> information in them after they are fully linked. Dynamically linked
> executables, position-independent executables (PIE) and shared
> libraries have dynamic relocations which are not only in the ELF file,
> but in a loadable segment so that they can be accessed at run time.
>
> The relocation information from the .o files are not preserved in the
> final executable unless you specify the --emit-relocs flags, which
> exists purely for debugging purposes. The relocations used by the
> dynamic loader come from an entirely different, simpler set of
> relocation types which are normally not found in .o files.
>
> Why do you think objdump has two different options for dumping normal
> (-r) vs. dynamic (-R) relocations?
>
> And no, Linux ELF executables can _not_ be loaded into an arbitrary
> memory location unless they are PIE. Shared libraries, however, can be
> loaded at arbitrary memory locations, though things like pre-linking
> might make it more optimal to try to place them at the same address
> everywhere.
Thanks for the explanation. I have not worked at this level with
executable formats in a long time. My experience harks back to Z80
formats (I forgot which, but post-CPM which loaded into a fixed address)
and .COM and .EXE formats which have rudimentary relocation fixup
information so that they could be run at arbitrary addresses. Those are
non-virtual (or didn't use the MMU) formats, equivalent to your PIE
reference.
> Ok, I'll stop the chest-beating now. But please stop trying to tell
> people that adding a powerpc-specific option (which nobody seems to
> know how really works) to the command line will work on any other
> architectures than powerpc.
Fair enough.
> Haavard
Discovering my banner is labeled "obsolete",
gvb
next prev parent reply other threads:[~2008-07-25 19:03 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-23 17:39 [U-Boot-Users] Changing u-boot relocation scheme vb
2008-07-23 21:46 ` Jerry Van Baren
2008-07-23 22:46 ` vb
2008-07-24 3:18 ` Wolfgang Denk
2008-07-24 6:45 ` vb
2008-07-24 9:58 ` Haavard Skinnemoen
2008-07-24 13:47 ` vb
2008-07-24 12:23 ` Jerry Van Baren
2008-07-24 12:47 ` Kenneth Johansson
2008-07-24 13:50 ` vb
2008-07-24 13:01 ` Wolfgang Denk
2008-07-24 13:17 ` Kenneth Johansson
2008-07-24 16:57 ` Haavard Skinnemoen
2008-07-24 17:12 ` Kenneth Johansson
2008-07-25 9:16 ` Haavard Skinnemoen
2008-07-24 17:37 ` vb
2008-07-24 18:09 ` Kenneth Johansson
2008-07-24 18:26 ` vb
2008-07-24 18:32 ` Joakim Tjernlund
2008-07-24 18:41 ` Kenneth Johansson
2008-07-25 4:28 ` Wolfgang Denk
2008-07-26 5:48 ` Grant Likely
2008-07-26 7:53 ` kenneth johansson
2008-07-26 12:48 ` Grant Likely
2008-07-25 4:28 ` Wolfgang Denk
2008-07-25 9:10 ` Haavard Skinnemoen
2008-07-25 11:55 ` kenneth johansson
2008-07-25 12:19 ` Haavard Skinnemoen
2008-07-25 13:30 ` Joakim Tjernlund
2008-07-26 5:36 ` Wolfgang Denk
2008-07-25 14:33 ` kenneth johansson
2008-07-25 14:51 ` vb
2008-07-25 15:21 ` Jerry Van Baren
2008-07-25 18:50 ` Haavard Skinnemoen
2008-07-25 19:03 ` Jerry Van Baren [this message]
2008-07-26 5:36 ` Wolfgang Denk
2008-07-26 16:09 ` Haavard Skinnemoen
2008-07-26 6:06 ` Grant Likely
2008-07-26 6:11 ` Grant Likely
2008-07-26 12:49 ` Wolfgang Denk
2008-07-26 5:36 ` Wolfgang Denk
2008-07-26 5:51 ` vb
2008-07-25 15:23 ` Haavard Skinnemoen
2008-07-25 16:31 ` kenneth johansson
2008-07-25 17:02 ` Jerry Van Baren
2008-07-25 17:28 ` kenneth johansson
2008-07-25 18:35 ` Haavard Skinnemoen
2008-07-25 19:57 ` J. William Campbell
2008-07-25 20:51 ` kenneth johansson
2008-07-26 15:54 ` Haavard Skinnemoen
2008-07-26 21:29 ` J. William Campbell
2008-07-26 21:58 ` Haavard Skinnemoen
2008-07-27 0:15 ` J. William Campbell
2008-07-26 5:36 ` Wolfgang Denk
2008-07-26 7:41 ` kenneth johansson
2008-07-26 12:49 ` Wolfgang Denk
2008-07-26 5:57 ` Grant Likely
2008-07-26 14:03 ` Jean-Christophe PLAGNIOL-VILLARD
2008-07-26 14:29 ` Joakim Tjernlund
2008-07-25 16:48 ` J. William Campbell
2008-07-25 4:28 ` Wolfgang Denk
2008-07-24 13:45 ` Jon Loeliger
2008-07-24 13:52 ` vb
2008-07-26 5:43 ` Grant Likely
2008-07-26 5:54 ` vb
2008-07-26 6:20 ` Grant Likely
2008-07-24 3:18 ` Wolfgang Denk
2008-07-24 6:20 ` Robert Schwebel
2008-09-15 14:56 ` [U-Boot] " vb
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=488A238F.5010806@ge.com \
--to=gerald.vanbaren@ge.com \
--cc=u-boot@lists.denx.de \
/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