Re: HELP with linker script!!!

[Nick Clifton <nickc@redhat.com>]

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