Many thanks for the quick reply/comments. Please allow me to explain: I try to bootelf from ELF bits residing in a region of memory (address range) that partially overlaps the loaded code .bss (the ELFs bits just happen to reside in that specific memory region that will eventually become the .bss by pure coincidence of address selection.)
Of course, a section of memory outside the reach of the application can be found to hold the ELF bits. Unfortunately, this also wastes valuable RAM bits (the Elf bits get downloaded; they are at no stage ROM resident), or will otherwise require some run-time memory layout calculation trickery I would rather avoid.
And a final note: try as I may, I could find no specific reference (ABI or otherwise) to indicate whose responsibility is it to clear the .bss. As for u-boot, I assume any change here would break things working today. Possibly, a bootelf invocation option would be nice....
Thanks again, Baruch
-----Original Message----- From: Mike Frysinger [mailto:vapier@gentoo.org] Sent: Sunday, May 04, 2008 11:16 AM To: u-boot-users@lists.sourceforge.net Cc: Baruch Cochavy Subject: Re: [U-Boot-Users] u-boot BOOTELF clearing SHT_NOBITS
sections
On Sunday 04 May 2008, Baruch Cochavy wrote:
u-boot's bootelf clears (memset to 0) sections of SHT_NOBITS type.
This
covers .bss sections - however, it might also includes other
sections,
not expected to be cleared as per some users expectations (stacks,
for
example).
most people dont declare sections for stacks. i dont think ive ever
seen
an ELF that does it.
I am beginning to wonder if this behavior is correct/desired: if one tries to bootelf an ELF file which happens to resizde somewhere
inside
the .bss section, or some other data section of the loaded code,
bootelf
clears it (or part of it...) while loading, corrupting the code to
be
loaded.
if you have overlapping sections, then your ELF is broken. if you
have
data in the middle of the .bss, then it isnt a NOBITS by definition, it's PROGBITS. you're describing invalid scenarios.
AFAIK, .bss is normally zeroed out in crt0 (or equivalent), so there
is
no need (?) to zero it in bootelf. Bootelf may also defer all such actions (clearing section) to the end of the loading process.
there is no normal sense here. the only real guarantee is that when main() starts executing, the C runtime environment is entirely valid (or any pre-main initializers that get run). by dropping the behavior in question, you'd be breaking things that are working today, so it's pretty hard
to
change it at all.
really though, using the section headers is going to always lead to conflicting needs. the program headers should be used instead ...
perhaps
a new command (or option) can be added for it ... -mike