Re: [U-Boot] Possible bug in u-boot standalone examples
Hey Wolfgang,
Hmm, I think I might not have made my point clear enough ... my apologies! Either that or I have a fundamental misunderstanding of the issue (more likely).
No. See the FAQ entry. The entry point address really depends on te code. If you add code, it can be basically anywehre - there may other functions preceed the entry point, etc.
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 and I understand that this is subject to change, and naturally if you're attempting to run a standalone application from an address other than its base address defined at link time, then the application won't execute correctly.
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 of where I loaded it due to the fact that I was beginning execution four bytes into the code, thus skipping the first instruction (as outlined in the examples).
Of course, I understand that the situation becomes very different when alternative compilers and linkers are thrown into the mix.
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 newcomer to development at this level of abstraction, this threw me a massive red herring until I realised that actually, for my example, the first instruction is -crucial- (stack frame allocation), and I can't work out in my head how the example actually works correctly when loaded at a 4 byte offset.
Thanks!
Dave George
Stay informed by joining the Rapita Systems mailing list http://www.rapitasystems.com/contact/mailing_list
For real-time verifications issues and discussion, follow the Rapita Systems blog http://www.rapitasystems.com/blog
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
participants (2)
-
David George -
Wolfgang Denk