* [U-Boot] sparc leon3 linking problem
@ 2014-03-11 22:14 Kameron Larsen
2014-03-12 12:52 ` Tom Rini
0 siblings, 1 reply; 3+ messages in thread
From: Kameron Larsen @ 2014-03-11 22:14 UTC (permalink / raw)
To: u-boot
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?
-Kameron
^ permalink raw reply [flat|nested] 3+ messages in thread
* [U-Boot] sparc leon3 linking problem
2014-03-11 22:14 [U-Boot] sparc leon3 linking problem Kameron Larsen
@ 2014-03-12 12:52 ` Tom Rini
2014-03-12 15:01 ` Daniel Hellstrom
0 siblings, 1 reply; 3+ messages in thread
From: Tom Rini @ 2014-03-12 12:52 UTC (permalink / raw)
To: u-boot
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!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140312/8acb7f99/attachment.pgp>
^ permalink raw reply [flat|nested] 3+ messages in thread
* [U-Boot] sparc leon3 linking problem
2014-03-12 12:52 ` Tom Rini
@ 2014-03-12 15:01 ` Daniel Hellstrom
0 siblings, 0 replies; 3+ messages in thread
From: Daniel Hellstrom @ 2014-03-12 15:01 UTC (permalink / raw)
To: u-boot
On 03/12/2014 01:52 PM, Tom Rini wrote:
> 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!
>
Hi! I've looked at it quickly but couldn't see any obvious problems.
Daniel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-03-12 15:01 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-11 22:14 [U-Boot] sparc leon3 linking problem Kameron Larsen
2014-03-12 12:52 ` Tom Rini
2014-03-12 15:01 ` Daniel Hellstrom
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox