Re: HELP with linker script!!!

[Pieter Arnout <pieter@powerescape.com>]

Nick,

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

Just a few more questions if you don't mind:

(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?
In Grigory's example he writes in C code "extern int my_section_start".
Is this the way to define such a thing? Seems to me that the linker 
script couldn't possibly know that the intention of this value is to 
serve as a boundary for the section my_section ...
(2) You say:
> 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? How can they not have a size then? Do they just grow 
towards each other until one collides with the other?

(3) Finally I would love to find a book that was as helpful in 
explaining this as your email, so I don't have to keep asking these 
questions. Do you know of a good book that covers these issues?

Again, thanks so much for your help. This email has been the most 
helpful one I've had on the topic!

Sincerely,
Pieter


On Apr 1, 2005, at 3:23 AM, Nick Clifton wrote:

> Hi Pieter,
>
>> Thank you very much. Your emails were extremely helpful. I'm trying 
>> to digest it, but it's still a little over my head. I'm a 
>> self-confessed newbie to this area.
>
> Just a word of warning then.  Hacking linker scripts can be difficult 
> and will often result in programs which do not execute.
>
>> (1) Is there a name for the stack section and the heap section?
>
> No.  In fact there is no heap section and there usually is no stack 
> section either.
>
>> What I mean here is, just like the name for the uninitialized globals 
>> is .bss, is there something like this when referring to the stack?
>
> No.  The stack and the heap have no contents (at link-time or 
> load-time) and so there is no need for them to have sections 
> associated with them, since the linker does not need to manipulate 
> them.  [Note - the stack and the heap do frequently have *symbols* 
> associated with them, and these symbols do have names, and these names 
> can appear in linker scripts.  But commonly there will be no 
> *sections* for the stack or the heap].
>
>> Is this the hardware specific part?
>
> Yes. :-)
>
>> In other words, will the name I need to reference in the linker 
>> script vary depending on what I choose to be my target as I 
>> cross-compile?
>
> Yes.  It will also vary on the run-time environment that you will 
> running on that target.
>
>> If so, where specifically should I look to find this? Would the ABI 
>> mention this?
>
> It may do.  You should also consider looking at whatever documentation 
> is provided about the execution environment for your program.
>
> Normally the stack and the heap are set up by the run-time startup 
> code for the application.  (Typically a file called crt0.o).  This 
> code may use an operating system call to find out where the stack and 
> heap should be located or it may look for symbols defined by the 
> linker script.
>
> The best way to learn all of this is by example.  So pick an 
> architecture with which you are familiar and then have a look in the 
> libgloss/ directory (which is part of the newlib project).  You should 
> be able source files in one of its sub-directories which give examples 
> of how the run-time startup code create the stack and heap.
>
>> Do I use the same syntax to define the stack's size? and the heap's 
>> size?
>
> 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.
>
>> (2) The reason I'm trying to assign certain variables to memory 
>> regions on their own, is because I have more than just the simple RAM 
>> and ROM region like in the example documentation. In my case, my RAM 
>> contains a region that is cachable and another region that is 
>> uncachable (like scratch memory). What I would like to do is place 
>> some of the members of the .bss section in the uncacheable region and 
>> some of the .bss section in the cachable region. Exactly how I should 
>> do this is where I'm getting stuck. Grigory's email is still over my 
>> head in this way and I'm still trying to "digest" it! Because of I'm 
>> not familiar at all with what he's doing here, I want to make sure 
>> his example would serve my purpose before I go down the wrong track 
>> ... can you or someone else confirm this?
>
> His example will help you.
>
> The problem comes down to deciding which pieces of data are going to 
> be placed in the cacheable RAM and which are going to be placed in the 
> uncacheable RAM.  If you can make this decision in the source code of 
> your application then it is easy.  Simply use the:
>
>   __attribute__((section(".cached_bss")))
>
> feature of GCC to annotate all of those variables which you want to be 
> placed into the cacheable RAM, and then make sure that your linker 
> script assigns the .cached_bss to the cacheable RAM memory region. 
> Easy! :-)
>
>   MEMORY
>   {
>      cachableRAM : org = 0x100, len = 0x200
>      uncacheRAM:   org = 0x3000, len = 0x40000
>   }
>
>   SECTIONS
>   {
>      [...other sections...]
>
>      .cached_bss : { *(.cached_bss) } > cachableRAM;
>      .bss : { *(.bss) } > uncacheRAM;
>
>      [...other sections...]
>   }
>
> Cheers
>   Nick
>