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:[EMAIL PROTECTED]
> 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
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
