[U-Boot] aarch64-linux-gnu-objdump gives all zeros in init_sequence_f[]

Albert ARIBAUD albert.u.boot at aribaud.net
Wed Nov 11 23:20:18 PST 2015


Hello Shawn,

On Thu, 12 Nov 2015 13:43:18 +0800, Shawn Guo <shawn.guo at linaro.org>
wrote:
> Hi,
> 
> I need some help to understand aarch64-linux-gnu-objdump output in .data
> section as below.  It's part of the dump of u-boot image with command
> 'aarch64-linux-gnu-objdump -D -z u-boot'.
> 
> Disassembly of section .data:
> 
> 0000000035039898 <reserved_list>:
> 	<snip>
> 
> 0000000035039948 <init_sequence_f>:
>     35039948:   00000000        .word   0x00000000
>     3503994c:   00000000        .word   0x00000000
>     35039950:   00000000        .word   0x00000000
>     35039954:   00000000        .word   0x00000000
>     35039958:   00000000        .word   0x00000000
>     3503995c:   00000000        .word   0x00000000
>     35039960:   00000000        .word   0x00000000
>     35039964:   00000000        .word   0x00000000
>     35039968:   00000000        .word   0x00000000
>     3503996c:   00000000        .word   0x00000000
>     35039970:   00000000        .word   0x00000000
>     35039974:   00000000        .word   0x00000000
>     35039978:   00000000        .word   0x00000000
>     3503997c:   00000000        .word   0x00000000
>     35039980:   00000000        .word   0x00000000
>     35039984:   00000000        .word   0x00000000
>     35039988:   00000000        .word   0x00000000
>     3503998c:   00000000        .word   0x00000000
>     35039990:   00000000        .word   0x00000000
>     35039994:   00000000        .word   0x00000000
>     35039998:   00000000        .word   0x00000000
>     3503999c:   00000000        .word   0x00000000
>     350399a0:   00000000        .word   0x00000000
>     350399a4:   00000000        .word   0x00000000
>     350399a8:   00000000        .word   0x00000000
>     350399ac:   00000000        .word   0x00000000
>     350399b0:   00000000        .word   0x00000000
>     350399b4:   00000000        .word   0x00000000
>     350399b8:   00000000        .word   0x00000000
>     350399bc:   00000000        .word   0x00000000
>     350399c0:   00000000        .word   0x00000000
>     350399c4:   00000000        .word   0x00000000
>     350399c8:   00000000        .word   0x00000000
>     350399cc:   00000000        .word   0x00000000
>     350399d0:   00000000        .word   0x00000000
>     350399d4:   00000000        .word   0x00000000
>     350399d8:   00000000        .word   0x00000000
>     350399dc:   00000000        .word   0x00000000
>     350399e0:   00000000        .word   0x00000000
>     350399e4:   00000000        .word   0x00000000
>     350399e8:   00000000        .word   0x00000000
>     350399ec:   00000000        .word   0x00000000
>     350399f0:   00000000        .word   0x00000000
>     350399f4:   00000000        .word   0x00000000
>     350399f8:   00000000        .word   0x00000000
>     350399fc:   00000000        .word   0x00000000
>     35039a00:   00000000        .word   0x00000000
>     35039a04:   00000000        .word   0x00000000
>     35039a08:   00000000        .word   0x00000000
>     35039a0c:   00000000        .word   0x00000000
>     35039a10:   00000000        .word   0x00000000
>     35039a14:   00000000        .word   0x00000000
>     35039a18:   00000000        .word   0x00000000
>     35039a1c:   00000000        .word   0x00000000
>     35039a20:   00000000        .word   0x00000000
>     35039a24:   00000000        .word   0x00000000
>     35039a28:   00000000        .word   0x00000000
>     35039a2c:   00000000        .word   0x00000000
>     35039a30:   00000000        .word   0x00000000
>     35039a34:   00000000        .word   0x00000000
>     35039a38:   00000000        .word   0x00000000
>     35039a3c:   00000000        .word   0x00000000
>     35039a40:   00000000        .word   0x00000000
>     35039a44:   00000000        .word   0x00000000
>     35039a48:   00000000        .word   0x00000000
>     35039a4c:   00000000        .word   0x00000000
> 
> The init_sequence_f[] is an array defined in U-Boot v2015.04 source
> common/board_f.c, which holds a bunch of pointers to critical
> initialization functions that have to be called during boot.  Obviously,
> the array cannot be all zeros like what objdump tells.  And I confirmed
> that by printing the pointers at run-time as below.
> 
> init_sequence_f[0]: 0000000035004280
> init_sequence_f[1]: 00000000350042a8
> init_sequence_f[2]: 0000000035004380
> init_sequence_f[3]: 00000000350042a0
> init_sequence_f[4]: 00000000350044b8
> init_sequence_f[5]: 0000000035004388
> init_sequence_f[6]: 0000000035029538
> init_sequence_f[7]: 000000003500675c
> init_sequence_f[8]: 000000003500447c
> init_sequence_f[9]: 000000003501d864
> init_sequence_f[10]: 0000000035013778
> init_sequence_f[11]: 0000000035004398
> init_sequence_f[12]: 0000000035028ab8
> init_sequence_f[13]: 0000000035004278
> init_sequence_f[14]: 0000000035004270
> init_sequence_f[15]: 000000003500445c
> init_sequence_f[16]: 0000000035001f20
> init_sequence_f[17]: 0000000035004574
> init_sequence_f[18]: 00000000350042b0
> init_sequence_f[19]: 00000000350042c4
> init_sequence_f[20]: 00000000350042cc
> init_sequence_f[21]: 00000000350042f8
> init_sequence_f[22]: 00000000350044d4
> init_sequence_f[23]: 000000003500430c
> init_sequence_f[24]: 0000000035004314
> init_sequence_f[25]: 0000000035004330
> init_sequence_f[26]: 0000000035004390
> init_sequence_f[27]: 00000000350045bc
> init_sequence_f[28]: 0000000035004550
> init_sequence_f[29]: 0000000035004518
> init_sequence_f[30]: 0000000035004378
> init_sequence_f[31]: 0000000035004428
> init_sequence_f[32]: 00000000350043f0
> 
> Dumping an u-boot image built for 32-bit platform with
> arm-linux-gnueabi-objdump gives correct pointer values for the same
> array.
> 
> 17853c7c <init_sequence_f>:
> 17853c7c:       17805600        strne   r5, [r0, r0, lsl #12]
> 17853c80:       17805620        strne   r5, [r0, r0, lsr #12]
> 17853c84:       1780574c        strne   r5, [r0, ip, asr #14]
> 17853c88:       178007ec        strne   r0, [r0, ip, ror #15]
> 17853c8c:       1780583c                        ; <UNDEFINED> instruction: 0x1780583c
> 17853c90:       17805834                        ; <UNDEFINED> instruction: 0x17805834
> 17853c94:       1780315c                        ; <UNDEFINED> instruction: 0x1780315c
> 17853c98:       178015f4                        ; <UNDEFINED> instruction: 0x178015f4
> 17853c9c:       17800890                        ; <UNDEFINED> instruction: 0x17800890
> 17853ca0:       17801c0c        strne   r1, [r0, ip, lsl #24]
> 17853ca4:       178078f8                        ; <UNDEFINED> instruction: 0x178078f8
> 17853ca8:       17805808        strne   r5, [r0, r8, lsl #16]
> 17853cac:       17829564        strne   r9, [r2, r4, ror #10]
> 17853cb0:       17816104        strne   r6, [r1, r4, lsl #2]
> 17853cb4:       1783dea4        strne   sp, [r3, r4, lsr #29]
> 17853cb8:       178055f8                        ; <UNDEFINED> instruction: 0x178055f8
> 17853cbc:       17801a54                        ; <UNDEFINED> instruction: 0x17801a54
> 17853cc0:       17805b4c        strne   r5, [r0, ip, asr #22]
> 17853cc4:       178057e0        strne   r5, [r0, r0, ror #15]
> 17853cc8:       178057c8        strne   r5, [r0, r8, asr #15]
> 17853ccc:       17802e20        strne   r2, [r0, r0, lsr #28]
> 17853cd0:       17805910        usada8ne        r0, r0, r9, r5
> 17853cd4:       17805628        strne   r5, [r0, r8, lsr #12]
> 17853cd8:       17805640        strne   r5, [r0, r0, asr #12]
> 17853cdc:       17805678                        ; <UNDEFINED> instruction: 0x17805678
> 17853ce0:       17805680        strne   r5, [r0, r0, lsl #13]
> 17853ce4:       178056b0                        ; <UNDEFINED> instruction: 0x178056b0
> 17853ce8:       17805850                        ; <UNDEFINED> instruction: 0x17805850
> 17853cec:       178056c8        strne   r5, [r0, r8, asr #13]
> 17853cf0:       178056dc                        ; <UNDEFINED> instruction: 0x178056dc
> 17853cf4:       178056f8                        ; <UNDEFINED> instruction: 0x178056f8
> 17853cf8:       17805768        strne   r5, [r0, r8, ror #14]
> 17853cfc:       17805950                        ; <UNDEFINED> instruction: 0x17805950
> 17853d00:       178058ec        strne   r5, [r0, ip, ror #17]
> 17853d04:       17805894                        ; <UNDEFINED> instruction: 0x17805894
> 17853d08:       17805744        strne   r5, [r0, r4, asr #14]
> 17853d0c:       17805798                        ; <UNDEFINED> instruction: 0x17805798
> 17853d10:       17805770                        ; <UNDEFINED> instruction: 0x17805770
> 17853d14:       00000000        andeq   r0, r0, r0
> 
> Here are my questions:
> 
> - Is this only because that ARM 64-bit toolchain doesn't show the real
>   value of the pointers, or there are some linking or run-time magics to
>   get these pointers correct when the binary is actually running?
> 
> - Is this different behavior between ARM 32-bit and 64-bit toolchain
>   expected?  Or did I miss anything on 64-bit toolchain usage?
> 
> Any hints or comments are much appreciated.

Can you provide the target name and commit ID that you are building,
s well as the version of the toolchain that you are building with?
Without being able to reproduce your issue, it's kind of hard to
diagnose it.

> Thanks,
> Shawn

Amicalement,
-- 
Albert.



More information about the linux-arm-kernel mailing list