On 7/3/2017 8:12 PM, Peng Fan wrote:
-----Original Message-----
From: Tom Rini [mailto:tr...@konsulko.com]
Sent: Tuesday, July 04, 2017 10:47 AM
To: Peng Fan <peng....@nxp.com>
Cc: Simon Glass <s...@chromium.org>; Philipp Tomsich
<philipp.toms...@theobroma-systems.com>; albert.u.b...@aribaud.net; u-
b...@lists.denx.de
Subject: Re: [U-Boot] [PATCH 2/2] arm: config: enforce -fno-pic for SPL and
normal U-Boot
On Tue, Jul 04, 2017 at 01:09:36AM +0000, Peng Fan wrote:
Hi Tom,
-----Original Message-----
From: Tom Rini [mailto:tr...@konsulko.com]
Sent: Tuesday, July 04, 2017 12:17 AM
To: Peng Fan <peng....@nxp.com>; Simon Glass <s...@chromium.org>;
Philipp Tomsich <philipp.toms...@theobroma-systems.com>
Cc: albert.u.b...@aribaud.net; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH 2/2] arm: config: enforce -fno-pic for
SPL and normal U-Boot
On Mon, Jul 03, 2017 at 09:14:08PM +0800, Peng Fan wrote:
If not pass -fno-pic to toolchains, some toolchains may generate
.got and .got.plt sections, but when generate binaries, we did not
take .got and .got.plt into consideration, then SPL or normal
U-Boot boot failure because image corrupted.
Need to pass -fno-pic to disable generating .got and .got.plt
sections.
Signed-off-by: Peng Fan <peng....@nxp.com>
Cc: Albert Aribaud <albert.u.b...@aribaud.net>
Cc: Tom Rini <tr...@konsulko.com>
---
arch/arm/config.mk | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk index
1a77779..66ae403 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -130,9 +130,10 @@ ALL-y += checkarmreloc # instruction.
Relocation is not supported for that case, so disable # such
usage by requiring word relocations.
PLATFORM_CPPFLAGS += $(call cc-option, -mword-relocations)
-PLATFORM_CPPFLAGS += $(call cc-option, -fno-pic) endif
+PLATFORM_CPPFLAGS += $(call cc-option, -fno-pic)
+
# limit ourselves to the sections we want in the .bin.
ifdef CONFIG_ARM64
OBJCOPYFLAGS += -j .text -j .secure_text -j .secure_data -j
.rodata -j .data \
Something is "up" here and I need you to dig harder and perhaps see
if we're missing something in the linker scripts? The very next line of
context here is:
-j .u_boot_list -j .rela.dyn -j .got -j .got.plt
Meaning that we intentionally copy .got / .got.plt into the
resulting binary. And I see that we took in 397d7d5a1be1 from you
back in 2016 saying that we needed this in SPL. But 5a942a152776
put the got/got.plt sections (for 32bit
ARM) in intentionally as some relocations do need it. And in
4b0d506ed3b4 Philipp seems to have seen the same problem you have,
but fixed it with adding got/got.plt to the sections list we copy in (the above
hunk of context).
If pass -fno-pic to compiler, there will be no .got and .got.plt sections.
The .got and .got.plt is usually used for dynamic link, such as linux "*.so"
file.
We need to pass -fno-pic to compiler to remove .got and .got.plt sections.
"Usually" isn't the same as "always" or "only". And this reminded me that we
From https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options,
when -fpic is used for ARM, there will be GOT. The dynamic loader resolves the
GOT entries
when the program starts (the dynamic loader is not part of GCC; it is part of
the
operating system).
had to deal with e391b1e64b0b because yes, we're not making a shared library
but we do have position independent code. So, in the case of SPL, since we
For position independent code, but not making a shared library, we could use
-fpie.
can get away with -fno-pic (and get some space
savings) that's just not true of U-Boot itself. We're enforcing -fpic on other
architectures, so what exactly is going on with what you're seeing? Where
If not passing -fno-pic to gcc, the android toolchain will generate .got and
.got.plt
section. I think these sections are for dynamic link, not for static link.
would we need to be taking .got/.got.plt into consideration and why would it
be a bad thing to do so? Thanks!
We could keep .got and .got.plt, but personally I prefer use -fno-pic.
I think fpic is for shared library and fpie is for position independt code for
static link.
Thanks,
Peng.
To clarify things, as I understand it, -pie produces the same code and
segments as -pic does, plus a loader to load the code correctly into
memory. u-boot probably doesn't want that loader. The loader is required
to make the executable work under the OS, but stand-alone probably
doesn't work right in general. For u-boot, the advantage of -pic code
is that there are no TEXTREL relocations in the binary. The code is
generated to take care of bss (and code segment when required)
references that require relocation. Things in the .got may need
relocating by where bss ends up, but not the code. So relocation is
short and simple. Non pic code requires relocation processing that may
be more complex than pic code, and requires a larger relocation table.
If you are loading the code and bss at the location they were linked
for, neither type requires relocation. If the code and or bss is located
at a different address, -pic requires a little relocation and no pic
requires a lot. In general, -pic code is slightly slower and larger than
non-pic, but the relocation table for non-pic may be large enough to
overcome the smaller code. YMMV, but either can be made to work. It
depends on your exact situation. If you know the code will be loaded and
executed as it was linked, non-pic is usually a winner, as you can
discard all relocation. Otherwise, -pic is usually simpler to use, as
the u-boot relocation code can be simpler. OTOH, if one already has a
complete relocating loader in the u-boot code, either way will work. In
any case, the relocation code must relocate itself as required for
itself to work. Easy in -pic, not so easy otherwise.
Best Regards,
Bill Campbell
--
Tom
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
