This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: HELP with linker script!!!

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:


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! :-)

     cachableRAM : org = 0x100, len = 0x200
     uncacheRAM:   org = 0x3000, len = 0x40000

     [...other sections...]

     .cached_bss : { *(.cached_bss) } > cachableRAM;
     .bss : { *(.bss) } > uncacheRAM;

     [...other sections...]


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]