Rom based Shared Library
Thu Mar 30 14:53:00 GMT 2006
On 30 March 2006 15:33, email@example.com wrote:
> hey Dave
[ You posted this reply only to me and forgot to Cc the list. It's always
better to keep the thread on the mailing list, because a) if I get something
wrong in the discussion someone will notice and correct me before you get a
false understanding, and b) it all gets stored in the list archive and then if
someone has the same (or a similar) problem in the future they'll be able to
find our conversation and any solution with a websearch. I've added it back
in to the Cc. ]
> As I understand the .bss section is data that can be modified and since
> the application program (at least parts of it ) are running in Flash I
> thought it necessary to re-locate the .bss section to RAM so that the data
> in it can be modified by code running in FLASH - or have I missed
> something - I will be happy if you prove me wrong as leaving the .bss
> section in Flash would make my life a whole lot easier.
There's one vital fact you don't know about .bss: It's /all/ zeros!
Always, at startup, the /entire/ bss section is zeros; the whole purpose of it
is that the compiler puts all the zero-initialised variables in there. Since
the content is always known to be all zeros, the object file doesn't actually
include a .bss section at all; it just has a header to tell the linker/loader
how big it needs to be.
So, you don't even need to /have/ the .bss section at all in your flash.
Just write a memset call in your early startup code to zero out the entire bss
Can't think of a witty .sigline today....
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc