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

Shawn Guo shawn.guo at linaro.org
Wed Nov 11 21:43:18 PST 2015


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.

Thanks,
Shawn



More information about the linux-arm-kernel mailing list