[U-Boot] arm: wrong Relocation and not cleared BSS

[V, Aneesh]

Hello Heiko, 

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de [mailto:u-boot-
> bounces at lists.denx.de] On Behalf Of Heiko Schocher
> Sent: Sunday, October 31, 2010 1:18 PM
> To: Alexander Holler
> Cc: Darius Augulis; u-boot at lists.denx.de
> Subject: Re: [U-Boot] arm: wrong Relocation and not cleared BSS
> 
> Hello Alexander
> 
> Alexander Holler wrote:
> > I've just tested an u-boot build by Wolfgang Denx with the ELDK
> 4.2
> > (using the HEAD of the current master with the same patches than
> I've
> > used).
> >
> > Thanks for that, Wolfgang.
> >
> > This one works without any problems. So it seems to be proved,
> that it
> 
> Great! (And as we thought on 27.10.2010 ...)
> 
> > is a problem of the current relocation code as found in start.S in
> > conjunction with a newer version of gcc.
> 
> Yep, seems so ...

I am also facing similar issues with booting OMAP4430 SDP(Cortex-A9) 
and did some debugging. 

I am using GCC 4.4.1. 

I found some strange issues with the code generated by the compiler. 

Looks like the following labels created in start.S do not work as 
intended. 
Please look at the header information and assembly listing generated
by objdump. 


*******************************************************************

Code: 
*****
_rel_dyn_start_ofs:
	.word __rel_dyn_start - _start
_rel_dyn_end_ofs:
	.word __rel_dyn_end - _start
_dynsym_start_ofs:
	.word __dynsym_start - _start


Assembly listing: 
*****************
80e8017c <_board_init_r_ofs>:
80e8017c:       00000748        .word   0x00000748

80e80180 <_rel_dyn_start_ofs>:
80e80180:       0002358c        .word   0x0002358c

80e80184 <_rel_dyn_end_ofs>:
80e80184:       0002358c        .word   0x0002358c

80e80188 <_dynsym_start_ofs>:
80e80188:       0002358c        .word   0x0002358c


Header dump:
************
u-boot:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000187b4  80e80000  80e80000  00008000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       00005fde  80e987b4  80e987b4  000207b4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .interp       00000011  80e9e792  80e9e792  00026792  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .dynamic      00000080  80ea3500  80ea3500  0002b500  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  4 .dynsym       00000100  80ea358c  80ea358c  0002b58c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .dynstr       000000c2  80e9e7a3  80e9e7a3  000267a3  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .hash         00000054  80e9e868  80e9e868  00026868  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .rel.dyn      00003c50  80e9e8bc  80e9e8bc  000268bc  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .data         00000ff4  80ea250c  80ea250c  0002a50c  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .got.plt      0000000c  80ea3580  80ea3580  0002b580  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 10 .u_boot_cmd   00000540  80ea368c  80ea368c  0002b68c  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 11 .bss          00031220  80ea3bd0  80ea3bd0  0002bbcc  2**3
                  ALLOC


So, there seems to be a problem in the way 'as' assembles the labels. 

I see the following 'warning' in the 'as' manual: 

Machines with a 32-bit address space, but that do less than 32-bit 
addressing, require the following special treatment. If the machine of 
interest to you does 32-bit addressing (or doesn't require it; see 
Chapter 9 [Machine Dependencies], page 75), you can ignore this
issue. In order to assemble compiler output into something that works, 
as occasionally does strange things to `.word' directives. Directives 
of the form `.word sym1-sym2' are often emitted by compilers as part of jump tables. 

Therefore, when as assembles a directive of the form 
`.word sym1-sym2', and the difference between sym1 and sym2 does not 
fit in 16 bits, as creates a secondary jump table, immediately before 
the next label. This secondary jump table is preceded by a short-jump to the first byte after the secondary table. This
short-jump prevents the flow of control from accidentally falling into 
the new table. Inside the table is a long-jump to sym2. The original 
`.word' contains sym1 minus the address of the long-jump to sym2.

If there were several occurrences of `.word sym1-sym2' before the 
secondary jump table, all of them are adjusted. If there was a `.word 
sym3-sym4', that also did not fit in sixteen bits, a long-jump to sym4 
is included in the secondary jump table, and the .word directives
are adjusted to contain sym3 minus the address of the long-jump to 
sym4; and so on, for as many entries in the original jump table as 
necessary. 

**********************************************************

Looks like part of the issue is due to these labels. 

However, there seems to be other problems. 
I noticed that the code is also not relocatable. It's making absolute
references to the address before relocation. 

This seems to be solved if I add -fPIE to the PLATFORM_CPPFLAGS. 

However, I couldn't solve the problem with the labels yet. I will let 
you know if I could make some progress. 

Br,
Aneesh