From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Possible bug in u-boot standalone examples
Date: Thu, 15 Jan 2015 20:19:49 +0100 [thread overview]
Message-ID: <20150115191949.EF333384DFA@gemini.denx.de> (raw)
In-Reply-To: <54B7D34A.6090501@rapitasystems.com>
Dear David,
In message <54B7D34A.6090501@rapitasystems.com> you wrote:
>
> I had a look at this FAQ entry, and I think it's addressing a different
> point than the issue I'm seeing here. This part of the FAQ tells the
> user that the load point of their standalone function may differ due to
> the particular linker or link map they're using. This is totally fine
No, please re-read, this is not the case. The load address is always
a constant, defined only by your linker script / linker options.
But even with a fix load address (start address of the text segment)
the entry point address may vary depending on the code in your
program.
> In my situation, I specifically told my linker to set my example
> application's start address to to be the same as the hello_world example
> (0x40000). Presumably the same problems would have occurred regardless
You misunderstand. You told the linker where the text segment starts.
But this has nothing to do with the entry point address, i. e. where
the first instruction of your first code to be executed is. Assume 3
different C sources, say:
main() { ... }
foo() { ... }
bar() { ...}
versus
foo() { ... }
main() { ... }
bar() { ...}
or
foo() { ... }
bar() { ...}
main() { ... }
Even if you link all for the same memory map, the address of main()
will be different in all 3 cases.
> I'd be very interested to know which incidents in the past had caused
> the standalone examples to fail to execute correctly from their base
> address yet work correctly from a 4 byte offset, because as a relative
Forget about this offset thing, please. It all depends how trhe
linker arranges the code within the text segment. Yous, you can
probably write a linker script to make sure that the first executable
instruction of your code is at the beginning of the text segment, and
that the text segment is the first one in you binary image. No such
measures are taken in the example link command, so the entry point
address is not fix, nor is it necessarily at, or even near to, the
start of the text segment.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If something is different, it's either better or worse, and usually
both. - Larry Wall
prev parent reply other threads:[~2015-01-15 19:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <54B7C286.9080906@rapitasystems.com>
[not found] ` <20150115140401.ADF003808CF@gemini.denx.de>
[not found] ` <54B7CA19.1060109@rapitasystems.com>
[not found] ` <20150115143000.886A53808CF@gemini.denx.de>
2015-01-15 14:48 ` [U-Boot] Possible bug in u-boot standalone examples David George
2015-01-15 19:19 ` Wolfgang Denk [this message]
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=20150115191949.EF333384DFA@gemini.denx.de \
--to=wd@denx.de \
--cc=u-boot@lists.denx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox