[U-Boot] ARM: problem with linker option -pie

[U-Boot] ARM: problem with linker option -pie

[Darius Augulis]

Hi all,

I've found solution which solves problem of empty command table.
Actually the problem is -pie linker option. I removed it and added -fPIC 
flag to compiler options. Because relocation with such changes fails, I 
set TEXT_BASE equal to runtime calculated relocation address.
And it works! All commands are there.

There is this dummy patch:

diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 4e165bf..2046c32 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -33,7 +33,7 @@ STANDALONE_LOAD_ADDR = 0xc100000
  endif
  endif

-PLATFORM_CPPFLAGS += -DCONFIG_ARM -D__ARM__
+PLATFORM_CPPFLAGS += -DCONFIG_ARM -D__ARM__ -fPIC

  # Explicitly specifiy 32-bit ARM ISA since toolchain default can be 
-mthumb:
  PLATFORM_CPPFLAGS += $(call cc-option,-marm,)
@@ -67,5 +67,4 @@ LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds

  # needed for relocation
  ifndef CONFIG_NAND_SPL
-PLATFORM_LDFLAGS += -pie
  endif

And there is small patch for debugging command table:

diff --git a/common/hush.c b/common/hush.c
index 2188fd4..be92968 100644
--- a/common/hush.c
+++ b/common/hush.c
@@ -1675,6 +1675,10 @@ static int run_pipe_real(struct pipe *pi)
                         /* Look up command in command table */


+                       printf("%s %d: cmd_tbl_s: %X, cmd_tbl_e: %X, 
len: %d\n",
+                               __func__, __LINE__,
+                               &__u_boot_cmd_start, &__u_boot_cmd_end,
+                               &__u_boot_cmd_end - &__u_boot_cmd_start);
                         if ((cmdtp = find_cmd(child->argv[i])) == NULL) {
                                 printf ("Unknown command '%s' - try 
'help'\n", child->argv[i]);
                                 return -1;      /* give up after bad 
command */

Also I did one test with linker script.
I defined variable in start.S:

.globl _cmd_start
_cmd_start:
	.word __u_boot_cmd_start

__u_boot_cmd_start is exported in linker script.
Without my patch, disassembled elf looks like this:

<...>
57e00048 <_cmd_start>:
57e00048:       00000000        .word   0x00000000
<...>

while with patch applied:

<..>
57fcb048 <_cmd_start>:
57fcb048:       57fea2b0        .word   0x57fea2b0
<..>

Also disassembling u-boot-spl shows good result because there isn't -pie 
linker option.
It's interesting, because if I define .word __u_boot_cmd_start - _start,
then *offset* is calculated correctly.
So, I assume, with -pie, linker doesn't export variables correctly and 
in my case pointer to command table is always null.

Eric, could your please test your board in the same way I have described 
and find out whether it helps? This could be toolchain version dependent 
and other people may not have this problem.

Darius.

[U-Boot] ARM: problem with linker option -pie

[Wolfgang Denk]

Dear Darius Augulis,

In message <4CCC8206.40206@gmail.com> you wrote:
> 
> I've found solution which solves problem of empty command table.
> Actually the problem is -pie linker option. I removed it and added -fPIC 
> flag to compiler options. Because relocation with such changes fails, I 
> set TEXT_BASE equal to runtime calculated relocation address.
> And it works! All commands are there.

Sorry, but this is not a solution. You may use this as momentary
workaround if you need a running system, but it cannot go into
mainline.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I have the simplest tastes.  I am always satisfied with the best.
                                                       -- Oscar Wilde

[U-Boot] ARM: problem with linker option -pie

[Darius Augulis]

Hi Wolfgang,

On 10/30/2010 11:43 PM, Wolfgang Denk wrote:
> Dear Darius Augulis,
>
> In message<4CCC8206.40206@gmail.com>  you wrote:
>>
>> I've found solution which solves problem of empty command table.
>> Actually the problem is -pie linker option. I removed it and added -fPIC
>> flag to compiler options. Because relocation with such changes fails, I
>> set TEXT_BASE equal to runtime calculated relocation address.
>> And it works! All commands are there.
>
> Sorry, but this is not a solution. You may use this as momentary
> workaround if you need a running system, but it cannot go into
> mainline.

Of course not. I just wanted inform that -pie is not working.
Actually I don't know how to fix it correctly. It's may be interesting 
for more people, especially who wrote relocation code.
At least one person except me in this list faced the same problem.
Maybe somebody could do test with different compiler/binutils versions 
and figure out whether is it depended or not. I have only single ARM 
toolchain and can't do such test yet.

Darius.

>
> Best regards,
>
> Wolfgang Denk
>

[U-Boot] ARM: problem with linker option -pie

[Wolfgang Denk]

Dear Darius Augulis,

In message <4CCC85B4.6060102@gmail.com> you wrote:
> 
> > Sorry, but this is not a solution. You may use this as momentary
> > workaround if you need a running system, but it cannot go into
> > mainline.
> 
> Of course not. I just wanted inform that -pie is not working.
> Actually I don't know how to fix it correctly. It's may be interesting 
> for more people, especially who wrote relocation code.

Which exact tool chain are you using?

Do you have a chance to build with ELDK 4.2?

Or, if your code is all in mainline (or you are willing to send me
patches), would you test an image that I compile for you, using LDK
4.2?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
He'd heard her use that sweet, innocent  tone  of  voice  before.  It
meant that, pretty soon, there was going to be trouble.
                                        - Terry Pratchett, _Truckers_

[U-Boot] ARM: problem with linker option -pie

[Albert ARIBAUD]

Le 30/10/2010 23:17, Wolfgang Denk a ?crit :
> Dear Darius Augulis,
>
> In message<4CCC85B4.6060102@gmail.com>  you wrote:
>>
>>> Sorry, but this is not a solution. You may use this as momentary
>>> workaround if you need a running system, but it cannot go into
>>> mainline.
>>
>> Of course not. I just wanted inform that -pie is not working.
>> Actually I don't know how to fix it correctly. It's may be interesting
>> for more people, especially who wrote relocation code.
>
> Which exact tool chain are you using?
>
> Do you have a chance to build with ELDK 4.2?
>
> Or, if your code is all in mainline (or you are willing to send me
> patches), would you test an image that I compile for you, using LDK
> 4.2?
>
> Best regards,
>
> Wolfgang Denk

I would really like it if someone, especially Alexander or Darius or 
both, could build u-boot and send me the whole u-boot ELF binary (not 
the raw binary) along with the commit ID of the source tree they built 
and the exact version of binutils they use, so that I can look up and 
compare the whole things. It could be a change in the relocation code of 
binutils, for instance; but I can't find out without the ELF binaries.

I don't need the -fPIC version; the one with -pie alone is the one I need.

Amicalement,
-- 
Albert.

[U-Boot] ARM: problem with linker option -pie

[Albert ARIBAUD]

All,

Thanks to Wolfgang and Alexander who offered help offline in order to 
track down the issue. Currently we know that the ELDK 4.2 toolchain 
"works" and the CodeSourcery 4.4.1 (arm-2010q1-202) "does not work".

A preliminary test of both the ELDK and the CS toolchains on a small 
program which uses one each of const, initialized and uninitialized 
globals shows that while the EABI version has moved from 4 to 5, and the 
code generator has changed, both toolchains generate the same number of 
relocations for the same locations, albeit in a different order; so at 
least we know that all required fixups are present with both chains.

On u-boot, the overall number of relocations is smaller with the CS 
toolchain but apparently this is due to the code generator generating 
less literals per function.

Tomorrow (sorry : later this morning) I'll build the OpenRD binaries 
with both toolchains and test it.

Meanwhile, I would still like Alexander to add printf()s to then nand 
init functions so that we know at which address they think they 
nand_chip should be written to, and compare that to the printf() that 
shows at which address nand_chip is supposed to be read.

Amicalement,
-- 
Albert.

[U-Boot] ARM: problem with linker option -pie

[Heiko Schocher]

Hello Darius,

Darius Augulis wrote:
> I've found solution which solves problem of empty command table.
> Actually the problem is -pie linker option. I removed it and added -fPIC
> flag to compiler options. Because relocation with such changes fails, I
> set TEXT_BASE equal to runtime calculated relocation address.
> And it works! All commands are there.

Which toolchain do you use?

Can you try ELDK-4.2, seems to me newer gcc have problems
with -pie

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] ARM: problem with linker option -pie

[Albert ARIBAUD]

Le 31/10/2010 01:31, Albert ARIBAUD a ?crit :

All,

I can now reproduce the issue using ELDK 4.2 ("works") and CS 
arm-2010q1-202 ("does not work") toolchains on openrd_base and current 
tip of master plus Alexander's RFC patch. CS toolchain emits lots of 
warnings about type-punned pointer dereferencing, though none in nand 
code, and I think these are not related to our issue.

I will now analyze the patch code to see if it contains relocations that 
should have applied but did not, or if it misses relocations altogether. 
My currently favored bet right now is that BSS may have gotten its own 
relocation table in later toolchains, but that's only a bet.

Amicalement,
-- 
Albert.

[U-Boot] ARM: problem with linker option -pie

[Reinhard Meyer]

Dear Albert ARIBAUD,

> CS toolchain emits lots of 
> warnings about type-punned pointer dereferencing, though none in nand 
> code, and I think these are not related to our issue.

Same with gcc 4.3.5

> I will now analyze the patch code to see if it contains relocations that 
> should have applied but did not, or if it misses relocations altogether. 
> My currently favored bet right now is that BSS may have gotten its own 
> relocation table in later toolchains, but that's only a bet.

u-boot.bin is 257KiB with 4.2.4 but only 251KiB with 4.3.5 !
Either its much better optimised or the relocation info shrunk which
_might_ indicate something is missing in it...

Compiled with 4.3.5 last output is the "DRAM: 64 MiB" message. Then silence.

I suppose you don't need u-boot.elf from me, if otherwise, ping me:)

Best Regards,
Reinhard

[U-Boot] ARM: problem with linker option -pie

[Albert ARIBAUD]

Hi Reinhart,

Le 31/10/2010 09:40, Reinhard Meyer a ?crit :
> Dear Albert ARIBAUD,
>
>> CS toolchain emits lots of
>> warnings about type-punned pointer dereferencing, though none in nand
>> code, and I think these are not related to our issue.
>
> Same with gcc 4.3.5
>
>> I will now analyze the patch code to see if it contains relocations that
>> should have applied but did not, or if it misses relocations altogether.
>> My currently favored bet right now is that BSS may have gotten its own
>> relocation table in later toolchains, but that's only a bet.
>
> u-boot.bin is 257KiB with 4.2.4 but only 251KiB with 4.3.5 !
> Either its much better optimised or the relocation info shrunk which
> _might_ indicate something is missing in it...

 From what I see, the code generator emits "denser" code, which *could* 
result in a smaller relocation table, but that depends if the denser 
code does uses less literals (they're what makes the size of relocation 
tables). So I have to dive into some sample functions and see for 
myself; the fact that the linker obviously reorders code within .text 
does not help me much. :/

> Compiled with 4.3.5 last output is the "DRAM: 64 MiB" message. Then silence.
>
> I suppose you don't need u-boot.elf from me, if otherwise, ping me:)

I'm ok now that I have a non-working toolchain to play with. :)

> Best Regards,
> Reinhard

Amicalement,
-- 
Albert.

[U-Boot] ARM: problem with linker option -pie

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4CCD26B7.8090503@free.fr> you wrote:
> 
> I can now reproduce the issue using ELDK 4.2 ("works") and CS
> arm-2010q1-202 ("does not work") toolchains on openrd_base and current
> tip of master plus Alexander's RFC patch. CS toolchain emits lots of
> warnings about type-punned pointer dereferencing, though none in nand
> code, and I think these are not related to our issue.

These are indeed unrelated.

> I will now analyze the patch code to see if it contains relocations that
> should have applied but did not, or if it misses relocations altogether.
> My currently favored bet right now is that BSS may have gotten its own
> relocation table in later toolchains, but that's only a bet.

Hm.... probably not BSS as such, but eventually the linker treats
segments without "LOAD" attribute differently?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Evil does seek to maintain power by suppressing the truth."
"Or by misleading the innocent."
	-- Spock and McCoy, "And The Children Shall Lead",
	   stardate 5029.5.

[U-Boot] ARM: problem with linker option -pie

[Wolfgang Denk]

Dear Reinhard Meyer,

In message <4CCD2B7C.3040804@emk-elektronik.de> you wrote:
>
> u-boot.bin is 257KiB with 4.2.4 but only 251KiB with 4.3.5 !
> Either its much better optimised or the relocation info shrunk which
> _might_ indicate something is missing in it...
> 
> Compiled with 4.3.5 last output is the "DRAM: 64 MiB" message. Then silence.

Confirmed: the tx25 board which runs fine when built with ELDK hangs
after the DRAM message as well.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
1st Old Man:  Gee, its windy today.
2nd Old Man:  No it's not... it's Thursday.
3rd Old Man:  Yeh, me too.  Let's go for a beer.

[U-Boot] ARM: problem with linker option -pie

[Albert ARIBAUD]

Le 31/10/2010 10:24, Wolfgang Denk a ?crit :

>> I will now analyze the patch code to see if it contains relocations that
>> should have applied but did not, or if it misses relocations altogether.
>> My currently favored bet right now is that BSS may have gotten its own
>> relocation table in later toolchains, but that's only a bet.
>
> Hm.... probably not BSS as such, but eventually the linker treats
> segments without "LOAD" attribute differently?

The first test I did with a sample program which contains the three 
types of static scope objects: const, initialized and uninitialized, and 
I checked that the inititialized one lands in BSS which has NOBITS while 
explicitely initialized objects land in data sections with PROGBITS -- 
that's akin to the LOAD attribute.

Both the ELDK 4.2 and the CS toolchains' linkers treat all three object 
types the same way with respect to relocation, and emit relocations to 
the uninitialized object, so not having LOAD attribute is irrelevant -- 
BTW if it was, BSS relocation would never have worked.

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.

[U-Boot] ARM: problem with linker option -pie

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4CCD3A6F.7040303@free.fr> you wrote:
> 
> The first test I did with a sample program which contains the three 
> types of static scope objects: const, initialized and uninitialized, and 
> I checked that the inititialized one lands in BSS which has NOBITS while 
> explicitely initialized objects land in data sections with PROGBITS -- 
> that's akin to the LOAD attribute.

Thanks for checking.

> Both the ELDK 4.2 and the CS toolchains' linkers treat all three object 
> types the same way with respect to relocation, and emit relocations to 
> the uninitialized object, so not having LOAD attribute is irrelevant -- 
> BTW if it was, BSS relocation would never have worked.

Yes, I know. My speculation was that suchbehaviour (or linker options
to adjust it) might have changed in more recent versions of
gcc/binutils.


BTW: I would like to point out that so far we're blaming GCC, which is
not exaclt correct, as we always tested GCC+Binutils combos. For
completeness, we should separate compilation and linking and test for
example ELDK's gcc with CS's ld, and vice versa.  Hope I will find
some time later this night.  Hope the ghosts won't make too much of a
noise.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Real Programmers always confuse Christmas and Halloween because
OCT 31 == DEC 25 !  - Andrew Rutherford (andrewr at ucs.adelaide.edu.au)

[U-Boot] ARM: problem with linker option -pie

[Albert ARIBAUD]

Le 31/10/2010 11:35, Wolfgang Denk a ?crit :
> Dear Albert ARIBAUD,
>
> In message<4CCD3A6F.7040303@free.fr>  you wrote:
>>
>> The first test I did with a sample program which contains the three
>> types of static scope objects: const, initialized and uninitialized, and
>> I checked that the inititialized one lands in BSS which has NOBITS while
>> explicitely initialized objects land in data sections with PROGBITS --
>> that's akin to the LOAD attribute.
>
> Thanks for checking.
>
>> Both the ELDK 4.2 and the CS toolchains' linkers treat all three object
>> types the same way with respect to relocation, and emit relocations to
>> the uninitialized object, so not having LOAD attribute is irrelevant --
>> BTW if it was, BSS relocation would never have worked.
>
> Yes, I know. My speculation was that suchbehaviour (or linker options
> to adjust it) might have changed in more recent versions of
> gcc/binutils.

Understood. Apparently it hasn't as such.

> BTW: I would like to point out that so far we're blaming GCC, which is
> not exaclt correct, as we always tested GCC+Binutils combos. For
> completeness, we should separate compilation and linking and test for
> example ELDK's gcc with CS's ld, and vice versa.  Hope I will find
> some time later this night.  Hope the ghosts won't make too much of a
> noise.

Correct, gcc and binutils are different things. In my (admittedly 
simple) test I'd looked at both toe .o files and the elf binaries, so 
either stage seems ok; and you're correct that 'cross-building' one gcc 
with the other linker is a useful set of tests to perform.

For the sake of completeness, as a reminder, the -pie option is a pure 
linker option: the gcc stage is the same whether ELF relocation is 
generated or not; that would *slightly* weight toward the linker as a 
culprit, but let's not haste to conclusions especially with such a weird 
issue.

I'll try 'cross-building' either this morning or in the early afternoon.

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.

[U-Boot] ARM: problem with linker option -pie

[Albert ARIBAUD]

Le 31/10/2010 11:57, Albert ARIBAUD a ?crit :

> I'll try 'cross-building' either this morning or in the early afternoon.

Linking the CodeSourcery objects with the ELDK 4.2 linker gives a 
functional u-boot with no "bad BSS" warning.

Seems like we can narrow down on binutils as I suspected.

I'll try the reverse (ELDK objects and CS linker) to see if the issue is 
seen then.

Amicalement,
-- 
Albert.

[U-Boot] ARM: problem with linker option -pie

[Albert ARIBAUD]

Le 31/10/2010 12:30, Albert ARIBAUD a ?crit :

> Linking the CodeSourcery objects with the ELDK 4.2 linker gives a
> functional u-boot with no "bad BSS" warning.

There is, however, an issue with the command table.

Amicalement,
-- 
Albert.

[U-Boot] ARM: problem with linker option -pie

[Albert ARIBAUD]

Le 31/10/2010 12:30, Albert ARIBAUD a ?crit :
> Le 31/10/2010 11:57, Albert ARIBAUD a ?crit :
>
>> I'll try 'cross-building' either this morning or in the early afternoon.
>
> Linking the CodeSourcery objects with the ELDK 4.2 linker gives a
> functional u-boot with no "bad BSS" warning.
>
> Seems like we can narrow down on binutils as I suspected.

... or maybe not.

Cross-building with one gcc and the other ld leads to the following 
obvious observation:

ELDK gcc plus ELDK or CS ld produces 3899 or 3898 .rel.dyn entries 
respectively whereas CS gcc plus CS or ELDK  produces 949 or 950 
.rel.dyn entries respectively, and I don't see a two-third drop in the 
number of literals which require relocation that would explain this 
difference.

Since changing the linker leaves almost the same relocation entry count, 
but changing gcc radically changes it, I now suspect the gcc part of the 
build rather than the ld.

One possible track is the use of -fPIE or -fpie while compiling and 
linking, I'm investigating this right now.

Amicalement,
-- 
Albert.

[U-Boot] ARM: problem with linker option -pie

[Darius Augulis]

On 10/31/2010 12:17 AM, Wolfgang Denk wrote:
> Dear Darius Augulis,
>
> In message<4CCC85B4.6060102@gmail.com>  you wrote:
>>
>>> Sorry, but this is not a solution. You may use this as momentary
>>> workaround if you need a running system, but it cannot go into
>>> mainline.
>>
>> Of course not. I just wanted inform that -pie is not working.
>> Actually I don't know how to fix it correctly. It's may be interesting
>> for more people, especially who wrote relocation code.
>
> Which exact tool chain are you using?

I use toolchain from Buildroot compiled from sources on my ubuntu 10.04 
host. I have made some testing today:

gcc 4.4.5 + binutils 2.19 - works ok
gcc 4.2.4 + binutils 2.19 - works ok
gcc 4.4.5 + binutils 2.20.1 - fails
gcc 4.2.4 + binutils 2.20.1 - fails
gcc 4.4.5 + binutils 2.20 - fails

Results show that it doesn't depend on compiler version and depends only 
on binutils - v2.20 and higher versions doesn't work.

Darius.

>
> Do you have a chance to build with ELDK 4.2?
>
> Or, if your code is all in mainline (or you are willing to send me
> patches), would you test an image that I compile for you, using LDK
> 4.2?
>
> Best regards,
>
> Wolfgang Denk
>