From: albert.u.boot@aribaud.net (Albert ARIBAUD)
To: linux-arm-kernel@lists.infradead.org
Subject: [U-Boot] aarch64-linux-gnu-objdump gives all zeros in init_sequence_f[]
Date: Thu, 12 Nov 2015 08:20:18 +0100 [thread overview]
Message-ID: <20151112082018.5af69684@lilith> (raw)
In-Reply-To: <20151112054316.GA5043@dragon>
Hello Shawn,
On Thu, 12 Nov 2015 13:43:18 +0800, Shawn Guo <shawn.guo@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.
WARNING: multiple messages have this Message-ID (diff)
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] aarch64-linux-gnu-objdump gives all zeros in init_sequence_f[]
Date: Thu, 12 Nov 2015 08:20:18 +0100 [thread overview]
Message-ID: <20151112082018.5af69684@lilith> (raw)
In-Reply-To: <20151112054316.GA5043@dragon>
Hello Shawn,
On Thu, 12 Nov 2015 13:43:18 +0800, Shawn Guo <shawn.guo@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.
next prev parent reply other threads:[~2015-11-12 7:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-12 5:43 aarch64-linux-gnu-objdump gives all zeros in init_sequence_f[] Shawn Guo
2015-11-12 5:43 ` [U-Boot] " Shawn Guo
2015-11-12 6:36 ` Ard Biesheuvel
2015-11-12 6:36 ` [U-Boot] " Ard Biesheuvel
2015-11-12 8:12 ` Shawn Guo
2015-11-12 8:12 ` [U-Boot] " Shawn Guo
2015-11-12 7:20 ` Albert ARIBAUD [this message]
2015-11-12 7:20 ` Albert ARIBAUD
2015-11-12 8:15 ` Shawn Guo
2015-11-12 8:15 ` Shawn Guo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151112082018.5af69684@lilith \
--to=albert.u.boot@aribaud.net \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.