From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] Let's bury CONFIG_NEEDS_MANUAL_RELOC
Date: Wed, 4 Feb 2015 11:29:52 +0100 [thread overview]
Message-ID: <20150204112952.2ba1e086@lilith> (raw)
In-Reply-To: <54D1C6CE.2020307@tss-engineering.com>
Hello Graeme,
On Wed, 04 Feb 2015 18:14:22 +1100, Graeme Russ
<gruss@tss-engineering.com> wrote:
> Hi Guys,
>
> Since I did the initial 'full relocation' for x86 way back when
> (http://git.denx.de/?p=u-boot.git;a=commit;h=1c409bc7101a24ecd47a13a4e851845d66dc23ce),
> there has been a lot of chatter about the ongoing need for
> CONFIG_NEEDS_MANUAL_RELOC. I think it's about time we looked really hard
> at this define and come to a definitive conclusion as to IF and HOW we
> can get rid of it for the remaining architectures that use it (being
> avr32, m68k, nds32, and sparc).
I second that.
> First, a bit of a primer on why and how I finally killed off
> CONFIG_NEEDS_MANUAL_RELOC for x86...
>
> Despite the best intentions of the 'manual' relocation performed by
> U-Boot, there were still instances where the U-Boot binary referenced
> the 'unrelocated' image which typically resides in flash (NOR flash in
> the case of the x86 board I was using). I only finally tracked this down
> through some arduous debugging of random crashes during the writing of a
> new U-Boot image to the NOR flash.
>
> After a lot of digging around, I managed to get a good understanding of
> the ELF binary format for x86 and compiler/linker flags needed in order
> to generate a binary image that could be relocated. It turns out that
> for x86, it was the -pic and --emit-relocs ld flags (Oddly, I cannot
> find the -pic flag in the gnu ld documentation maybe it's depricated?)
When I did the ELF relocation for ARM, only -pie existed for ld; but it
has an alias, --pic-executable. Maybe -pic is short for -pic-executable?
> The --emit-relocs flags leaves the relocation sections (for x86 the
> section of interest is .rela.dyn) in the final image. These sections
> list all the locations in the final binary that need to be adjusted if
> the image is loaded at a different address than the one it is compiled
> for. You can see the processing in do_elf_reloc_fixups() in
> arch/x86/lib/relocate.c
For ARM I just specified the placement of relocation sections in the
linker script; I'm surprised that x86 needs this --emit-relocs. Maybe
that's needed when one does not provide a custom linker script?
> Keep in mind that the relocation sections are NOT copied to RAM - they
> are only used once after U-Boot is copied to RAM to locate the memory
> locations that need to be adjusted.
>
> So the crux of generic relocation is to generate a stripped binary with
> all necessary ELF relocation information located AFTER the text and data
> sections which are copied to RAM
>
> So the first question that we need to answer is: Do the avr32, m68k,
> nds32, and sparc toolchains support the generation of the relevant
> sections needed to perform relocation in a manner similar to x86 (i.e
> generation of relocation references into sections of the final U-Boot
> binary)?
Those arches which use GCC should be able to use -pie / -pic-executable
and possibly --emit-relocs, as none of these is arch-specific.
Then, each arch might have to look into what GCC options are needed.
For the record, on ARM, I did not need any gcc option, but actually
had one -fPIC option /removed/.
> Regards,
>
> Graeme
Amicalement,
--
Albert.
next prev parent reply other threads:[~2015-02-04 10:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-04 7:14 [U-Boot] Let's bury CONFIG_NEEDS_MANUAL_RELOC Graeme Russ
2015-02-04 10:29 ` Albert ARIBAUD [this message]
2015-02-04 12:16 ` Graeme Russ
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=20150204112952.2ba1e086@lilith \
--to=albert.u.boot@aribaud.net \
--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