From: shawn.guo@linaro.org (Shawn Guo)
To: linux-arm-kernel@lists.infradead.org
Subject: aarch64-linux-gnu-objdump gives all zeros in init_sequence_f[]
Date: Thu, 12 Nov 2015 16:12:24 +0800 [thread overview]
Message-ID: <20151112081223.GB5043@dragon> (raw)
In-Reply-To: <CAKv+Gu8KyP8YQzhiJu6ThnMJCUc2U9mUhJk6mdxL3PGcV59Bcw@mail.gmail.com>
On Thu, Nov 12, 2015 at 07:36:02AM +0100, Ard Biesheuvel wrote:
> On 12 November 2015 at 06:43, Shawn Guo <shawn.guo@linaro.org> wrote:
> > 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?
> >
>
> AArch64 uses the ELF RELA relocation format, where the target location
> of the relocation is not used to hold the addend. In contrast, ARM
> uses the REL format, where the addend is stored in the same place
> where the result of the relocation computation needs to be stored.
>
> Since U-Boot is a PIE executable, it makes heavy use of
> R_ARM_RELATIVE/R_AARCH64_RELATIVE relocations, which are not symbol
> based, but simply point to places in the binary such as your init
> array) where the offset between the link time and load time addresses
> needs to be taken into account. For this type of relocation (and since
> the u-boot link time base address is 0x0), the addends happen to
> coincide with the actual addresses of the functions. These relocations
> are applied at runtime by u-boot itself, since it moves itself to the
> top of DRAM right after boot.
>
> In the AArch64 case, these addends are stored in the relocation
> entries themselves. If you dump the relocations form the u-boot binary
> using readelf, you will probably find the values you are looking for.
Thanks a lot for the pointer, Ard. With your hints, I'm looking at
U-Boot commit 8137af19e75a (arm64: Add tool to statically apply RELA
relocations) and getting the idea how this thing works on arm64.
Thanks again.
Shawn
WARNING: multiple messages have this Message-ID (diff)
From: Shawn Guo <shawn.guo@linaro.org>
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 16:12:24 +0800 [thread overview]
Message-ID: <20151112081223.GB5043@dragon> (raw)
In-Reply-To: <CAKv+Gu8KyP8YQzhiJu6ThnMJCUc2U9mUhJk6mdxL3PGcV59Bcw@mail.gmail.com>
On Thu, Nov 12, 2015 at 07:36:02AM +0100, Ard Biesheuvel wrote:
> On 12 November 2015 at 06:43, Shawn Guo <shawn.guo@linaro.org> wrote:
> > 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?
> >
>
> AArch64 uses the ELF RELA relocation format, where the target location
> of the relocation is not used to hold the addend. In contrast, ARM
> uses the REL format, where the addend is stored in the same place
> where the result of the relocation computation needs to be stored.
>
> Since U-Boot is a PIE executable, it makes heavy use of
> R_ARM_RELATIVE/R_AARCH64_RELATIVE relocations, which are not symbol
> based, but simply point to places in the binary such as your init
> array) where the offset between the link time and load time addresses
> needs to be taken into account. For this type of relocation (and since
> the u-boot link time base address is 0x0), the addends happen to
> coincide with the actual addresses of the functions. These relocations
> are applied at runtime by u-boot itself, since it moves itself to the
> top of DRAM right after boot.
>
> In the AArch64 case, these addends are stored in the relocation
> entries themselves. If you dump the relocations form the u-boot binary
> using readelf, you will probably find the values you are looking for.
Thanks a lot for the pointer, Ard. With your hints, I'm looking at
U-Boot commit 8137af19e75a (arm64: Add tool to statically apply RELA
relocations) and getting the idea how this thing works on arm64.
Thanks again.
Shawn
next prev parent reply other threads:[~2015-11-12 8:12 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 [this message]
2015-11-12 8:12 ` Shawn Guo
2015-11-12 7:20 ` Albert ARIBAUD
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=20151112081223.GB5043@dragon \
--to=shawn.guo@linaro.org \
--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.