Hello Heiko,
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot- bounces@lists.denx.de] On Behalf Of Heiko Schocher Sent: Sunday, October 31, 2010 1:18 PM To: Alexander Holler Cc: Darius Augulis; u-boot@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