Re: HELP with linker script!!!

[Nick Clifton <nickc@redhat.com>]

Hi Pieter,

> Thank you so much. Your email was *extremely* helpful! Your explanations 
> are excellent! I greatly appreciate all of your help!

Umm thank you - just one request - please could you use fewer 
exclamation marks ?  Thanks.

> (1) How do I indicate the start and end of the cacheable .bss or 
> uncacheable .bss in your example? Don't they usually have symbol names 
> that you can use to refer to them by?

You put the symbols in the linker script, like this:

   .cached_bss : {
      __start_of_cacheable_bss = ABSOLUTE (.);
      *(.cached_bss)
      __end_of_cacheable_bss = ABSOLUTE (.);
    } > cachableRAM;

Then you can reference them from your C code, like this:

    extern int __start_of_cacheable_bss;
    extern int __end_of_cacheable_bss;

    memset (& __start_of_cacheable_bss, 0,
     & __end_of_cacheable_bss - & __start_of_cacheable_bss);

Note - read the section entitled "Source Code Reference" in the linker 
documentation for an explanation of why these variables are being 
accessed via the & operator.

Note - you do not need to use double underscores at the start of the 
variable names, this is just a convention.

>> Normally the stack and heap do not have a size.  Instead they occupy 
>> all of the memory available to the application which has not already 
>> been allocated to the loaded code and its data.
> 
> This makes no sense to me. Frequently the stack and heap grow towards 
> each other, so isn't it important to define a boundary which they cannot 
> cross? 

No - as otherwise you would be restricting the heap and stack to fixed 
sizes when it was not necessary.  Some applications may use a lot of 
stack but very little heap, and others might use lots of heap but only a 
little stack.  If you have a fixed boundary that the stack and heap 
cannot cross then you might be unable to accommodate these kinds of 
application.

> How can they not have a size then? 

They do have sizes, but not fixed ones.  Their sizes are dynamic with 
the only real limitation being the amount of available memory that can 
be shared between them.

> Do they just grow towards each 
> other until one collides with the other?

Yes.  Of course well written memory allocators will attempt to check for 
collision with the stack.  Also for some targets the compiler supports a 
command line switch to add extra code that is called at the start of 
every function in order to check whether the stack is about to overflow 
into the heap.

Cheers
   Nick