On Tue, Mar 11, 2014 at 03:14:26PM -0700, Kameron Larsen wrote:
Hello,
I'm bringing up a board based on the board/gaisler/gr_xc3s_1500/ design. To keep things simple, we can use this design exactly as is.
My problem starts in the relocation section of arch/sparc/cpu/leon3/start.S which I'll paste here for convenience:
/* un relocated start address of monitor */ #define TEXT_START _text
/* un relocated end address of monitor */ #define DATA_END __init_end
reloc: set TEXT_START,%g2 set DATA_END,%g3 set CONFIG_SYS_RELOC_MONITOR_BASE,%g4 reloc_loop: ldd [%g2],%l0 ldd [%g2+8],%l2 std %l0,[%g4] std %l2,[%g4+8] inc 16,%g2 subcc %g3,%g2,%g0 bne reloc_loop inc 16,%g4
As can be seen, this relies upon the location of the _text and __init_end symbols. These symbols are only known to the linker and should be filled in by the linker to point to the actual addresses within the compiled program. I can see these addresses by running an objdump -x on the final u-boot binary. The relevant portions are below:
SYMBOL TABLE: 00000000 g .text 00000000 _text 00036000 g *ABS* 00000000 __init_end
So 0x00000000, and 0x00036000 are the values I expect to be used for _text and __init_end respectively. However, looking at the disassembled u-boot binary (objdump -d), I see that they are not. Instead they are giving the values of 0xd50 and 0xd44:
sparc-elf-objdump -d u-boot: 000010a4 <reloc>: 10a4: 05 00 00 03 sethi %hi(0xc00), %g2 10a8: 84 10 a1 50 or %g2, 0x150, %g2 ! d50 <MINFRAME+0xcf4> 10ac: 07 00 00 03 sethi %hi(0xc00), %g3 10b0: 86 10 e1 44 or %g3, 0x144, %g3 ! d44 <MINFRAME+0xce8> 10b4: 09 10 fe 38 sethi %hi(0x43f8e000), %g4
000010b8 <reloc_loop>: 10b8: e0 18 80 00 ldd [ %g2 ], %l0 10bc: e4 18 a0 08 ldd [ %g2 + 8 ], %l2 10c0: e0 39 00 00 std %l0, [ %g4 ] 10c4: e4 39 20 08 std %l2, [ %g4 + 8 ] 10c8: 84 00 a0 10 add %g2, 0x10, %g2 10cc: 80 a0 c0 02 cmp %g3, %g2 10d0: 12 bf ff fa bne 10b8 <reloc_loop> 10d4: 88 01 20 10 add %g4, 0x10, %g4
FWIW, MINFRAME is the last declared variable in start.S before this reloc label.
I've tried this with both the 3.4.4 and the 4.4.2 toolchains distributed by Gaisler. Both behave the same way.
Why isn't ld filling in the correct values of linker symbols?
Any ideas Daniel? Thanks!