[U-Boot] [PATCH 2/2] arm: config: enforce -fno-pic for SPL and normal U-Boot

Tue Jul 4 04:15:06 UTC 2017

On 7/3/2017 8:12 PM, Peng Fan wrote:
>
>> -----Original Message-----
>> From: Tom Rini [mailto:trini at konsulko.com]
>> Sent: Tuesday, July 04, 2017 10:47 AM
>> To: Peng Fan <peng.fan at nxp.com>
>> Cc: Simon Glass <sjg at chromium.org>; Philipp Tomsich
>> <philipp.tomsich at theobroma-systems.com>; albert.u.boot at aribaud.net; u-
>> boot at 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:trini at konsulko.com]
>>>> Sent: Tuesday, July 04, 2017 12:17 AM
>>>> To: Peng Fan <peng.fan at nxp.com>; Simon Glass <sjg at chromium.org>;
>>>> Philipp Tomsich <philipp.tomsich at theobroma-systems.com>
>>>> Cc: albert.u.boot at aribaud.net; u-boot at 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.fan at nxp.com>
>>>>> Cc: Albert Aribaud <albert.u.boot at aribaud.net>
>>>>> Cc: Tom Rini <trini at 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 at lists.denx.de
> https://lists.denx.de/listinfo/u-boot