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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.