HELP with linker script!!!

HELP with linker script!!!

[Pieter Arnout]

I read the the Red Hat manual "Using ld, the GNU Linker", but I'm 
having trouble. Essentially, I'd like to take specific symbols and 
assign them to a memory region, rather than just take a section and 
assign it to a memory region. I can obtain the symbol values and symbol 
type from the objdump or nm output. The only examples offered in the 
manual, however, only define the output sections .bss and .data by just 
assigning everything from the .bss and .data input sections to it:

SECTIONS
{
	. = 0x10000;
	.text : { *(.text) }
	. = 0x8000000;
	.data : { *(.data) }
	.bss : { *(.bss) }
}

I want some finer control. Does anyone know how I can go about 
ultimately assigning specific symbols (or data structures if you will) 
to a memory region? Should / can I create a section (much like .text, 
.data or .bss above) in the linker script and call it "my_section" and 
assign a list of symbols to "my_section"? Is this how I would go about 
accomplishing what I want? If so do I reference the symbols by name or 
by value when I call them out in the SECTIONS command? How does that 
look like?

Additionally, where do I define the start and end regions of my stack 
and heap? I use .bss for uninitialized variables, .data for initialized 
variables, but how do I reference the beginning and end of stack and 
the beginning and end of heap?

I need answers urgently.

Thanks so much for your help!

Pieter

Re: HELP with linker script!!!

[Nick Clifton]

Hi Pieter,

> I read the the Red Hat manual "Using ld, the GNU Linker",

First of all it is not a Red Hat manual.  It is the binutils project's 
linker manual.   You might have been confused by the fact that the 
binutils project is hosted at the sources.redhat.com domain, but this is 
a resource provided by Red Hat to the Free Software community and it 
does not make the linker or its manual Red Hat property in any way.

> but I'm having 
> trouble. Essentially, I'd like to take specific symbols and assign them 
> to a memory region, rather than just take a section and assign it to a 
> memory region. 

A practical example of the problem that you are trying to solve would help.

The linker does not have the facility to assign individual symbols to a 
memory region.  Instead, as Grigory has already mentioned, the way to 
achieve what you want is to use a custom section to contain the symbols 
that you are interested in, and then have the linker script assign this 
custom section to a specific memory region.  His email shows you how to 
do this.

> Additionally, where do I define the start and end regions of my stack 
> and heap? I use .bss for uninitialized variables, .data for initialized 
> variables, but how do I reference the beginning and end of stack and the 
> beginning and end of heap?

That is up to you and will probably be dictated by the hardware you are 
using and the amount of available memory.  One common design is to have 
the heap start at the end of the allocated sections, usually after the 
.bss section, and grow upwards through memory.  Meanwhile the stack is 
placed to start at the end of the available memory and grow downwards. 
(This does assume that the ABI for the processor you are using has a 
downwards growing stack).

The location for the start of the heap and the start of the stack will 
normally be set up by your linker script and so you can associate 
symbols with these locations.  Finding the current end-of-heap and 
end-of-stack however is hardware specific.  Usually a hardware register 
will be used as a stack pointer and so contain the end-of-stack address. 
  The end of heap however is usually held in a private variable 
somewhere inside the operating system's memory allocation code and may 
not be accessible to application programs.

Cheers
   Nick

Re: HELP with linker script!!!

[Nick Clifton]

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

Re: HELP with linker script!!!

[Vincent Rubiolo]

Hello Nick,

Thanks for this informative reply. There is something I am wondering 
about using the gcc attributes to put variables or functions : how to 
control the section flags of these new sections?

I know I can use objcopy with the --set-section-flags to tweak section 
flags to my liking. I was wondering how gcc was settings these flags : 
for your '.cached_bss' section, it may have the NOBITS flag set but does 
gcc know that, for instance, the NOBITS flag will have to be set?

As for Pieter problem, the crt0.c will surely rely on special symbols 
like __heap_start or __stack_start (set by the linker script) to detect 
and set the start of heap and stack.
You are also encouraged to use the MEMORY keyword that Nick mentioned : 
it make things clearer. However, it may not suit you if you have 
sections that have dynamic addresses/sizes i.e computed from say, the 
previous section' size (you will then have to rely on the computation 
capabilities of the ld script).

Regards,

Vincent

Nick Clifton wrote:
[...]
> 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

-- 
Reclaim Your Inbox!
http://internal.vannes.wrsec.fr/twiki/bin/view/Utilities/MailThunderbird

Re: HELP with linker script!!!

[Nick Clifton]

Hi Vincent,

> Thanks for this informative reply. There is something I am wondering 
> about using the gcc attributes to put variables or functions : how to 
> control the section flags of these new sections?

One way is by pre-declaring the section's name and attributes before 
using it. Like this:

   asm (".section .cached_bss, \"w\",@nobits");
   int foo __attribute__((section (".cached_bss")));

The problem with this approach is that (with GCC 4.1 at least) you will 
get warning messages from the assembler:

   Warning: ignoring changed section type for .cached_bss
   Warning: ignoring changed section attributes for .cached_bss

This is because GCC does not know that the asm() statement has already 
defined the .cached_bss section and so it issues its own .section 
directive.  If you can live with the assembler warning that this method 
will work.

The other way is hackier, but it avoids the warnings:

   int foo __attribute__((section (".cached_bss,\"w\",@nobits#")));

This assumes that the hash character (#) is the start-of-line-comment 
character for the particular instruction set you are using.  If you have 
a look at the assembler emitted by GCC you can see why:

         .section        .cached_bss,"w",@nobits#,"aw",@progbits

The hash stops GAS from interpreting the

   ,"aw",@probits

which gcc has appended to the name of the section...

Cheers
   Nick

RE: HELP with linker script!!!

[Dave Korn]

----Original Message----
>From: Nick Clifton
>Sent: 01 April 2005 15:02


> The other way is hackier, but it avoids the warnings:
> 
>    int foo __attribute__((section (".cached_bss,\"w\",@nobits#")));
> 
> This assumes that the hash character (#) is the start-of-line-comment
> character for the particular instruction set you are using.  If you have
> a look at the assembler emitted by GCC you can see why:
> 
>          .section        .cached_bss,"w",@nobits#,"aw",@progbits
> 
> The hash stops GAS from interpreting the
> 
>    ,"aw",@probits
> 
> which gcc has appended to the name of the section...

  <koff>  *start*-of-line comment character .........  <g>

  You could either add a \n before the # or use a ';' or whatever the port
uses for the mid-line comment character.......

  And boy, is that _ever_ a gross hack!  (I quite like it!)

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: HELP with linker script!!!

[Andreas Schwab]

"Dave Korn" <dave.korn@artimi.com> writes:

> ----Original Message----
>>From: Nick Clifton
>>Sent: 01 April 2005 15:02
>
>
>> The other way is hackier, but it avoids the warnings:
>> 
>>    int foo __attribute__((section (".cached_bss,\"w\",@nobits#")));
>> 
>> This assumes that the hash character (#) is the start-of-line-comment
>> character for the particular instruction set you are using.  If you have
>> a look at the assembler emitted by GCC you can see why:
>> 
>>          .section        .cached_bss,"w",@nobits#,"aw",@progbits
>> 
>> The hash stops GAS from interpreting the
>> 
>>    ,"aw",@probits
>> 
>> which gcc has appended to the name of the section...
>
>   <koff>  *start*-of-line comment character .........  <g>
>
>   You could either add a \n before the # or use a ';' or whatever the port
> uses for the mid-line comment character.......
>
>   And boy, is that _ever_ a gross hack!  (I quite like it!)

This will fail within #NO_APP.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: HELP with linker script!!!

[Pieter Arnout]

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
>

Re: HELP with linker script!!!

[Vincent Rubiolo]

Hello Pieter,

Pieter Arnout wrote:
[...]
> (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?
I mentioned possible symbol names for the start of these sections. 
However, these usually do not have any end that is predefined. The 
linker script defines the start symbols of these sections for the 
initialization code to position to corresponding pointers.

> 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 ...
No, Grigory's code is a way to reference it. You generally would only 
define the symbol yourself in the linker script. Here is what you can 
toss out :
__bss_end = . ;
This would define the __bss_end symbol and assign the location counter 
value to it. By referencing it as 'extern' in your C code, you can use 
it in your program/libraries.
You can have more information about linker scripts by passing the 
--verbose flag to your ld. It will display the default linker script it 
uses.

> (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?
Indeed. The 'boundary check', would you want to have one, should be done 
by your memory/program routines. This is not something that the linker 
is meant to do (the linker only deals with symbols and program 
sections/segments placement, not with program dynamic execution).
> 
> (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?
The binutils manual (http://sources.redhat.com/binutils/docs-2.15/) is 
of course the reference for the tools. However, it is a bit scarce on 
theory. You can consult John R. Levine's book which is, to my knowledge, 
the only book to deal with the subject (could be twice as thick 
however). You can find its only version here 
(http://www.iecc.com/linker/) or but it through your favorite book 
retail (I got mine via Amazon). A very good buy IMHO.

HTH,

Vincent
[...]

-- 
Reclaim Your Inbox!
http://internal.vannes.wrsec.fr/twiki/bin/view/Utilities/MailThunderbird

Re: HELP with linker script!!!

[Nick Clifton]

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

RE: HELP with linker script!!!

[Dave Korn]

----Original Message----
>From: Nick Clifton
>Sent: 04 April 2005 12:04

> 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.


  Or if you have to use lots, at least use ones made from recycled
electrons.  Exclamation points are one of the internet's most strained
natural resources.  Ever since the invention of AOL, dwindling supplies have
been rapidly reaching crisis point.

  Yahoo! doesn't help any either :)


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: HELP with linker script!!!

[Sergei Organov]

Nick Clifton <nickc@redhat.com> writes:
[...]
> 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.

Well, please correct me if I'm wrong, but I see two problems here.

1. The variables should better be of type 'char', otherwise pointer
   arithmetic in the third parameter to memcpy() will bring wrong
   result.

2. Even then it could be wrong. For example, on PowerPC using SYSV ABI
   compiler is free to assume the two variables are in the small data
   section and may generate incorrect assembly and relocation types for
   the addresses, I'm afraid. Because of this I'd use slightly different
   approach:

   extern char __start_of_cacheable_bss[];
   extern char __end_of_cacheable_bss[];

   memset (__start_of_cacheable_bss, 0,
      __end_of_cacheable_bss - __start_of_cacheable_bss);

   The purpose of using arrays of unknown size is to prevent compiler
   from assuming anything about the location of the variables.

-- 
Sergei.

Re: HELP with linker script!!!

[Nick Clifton]

Hi Sergei,

> Well, please correct me if I'm wrong, but I see two problems here.
> 
> 1. The variables should better be of type 'char', otherwise pointer
>    arithmetic in the third parameter to memcpy() will bring wrong
>    result.
> 
> 2. Even then it could be wrong. For example, on PowerPC using SYSV ABI
>    compiler is free to assume the two variables are in the small data
>    section and may generate incorrect assembly and relocation types for
>    the addresses, I'm afraid. Because of this I'd use slightly different
>    approach:
> 
>    extern char __start_of_cacheable_bss[];
>    extern char __end_of_cacheable_bss[];
> 
>    memset (__start_of_cacheable_bss, 0,
>       __end_of_cacheable_bss - __start_of_cacheable_bss);
> 
>    The purpose of using arrays of unknown size is to prevent compiler
>    from assuming anything about the location of the variables.


Good points - thanks for making them.

Cheers
   Nick

RE: HELP with linker script!!!

[Zagorodnev, Grigory]

Hi, Pieter!
You may consider this example: "implicit" linker script contains extra
information to combine user-defined section with default ".data" one,
providing the beginning mark. C program accesses this mark as data
object. 

$ cat main.c
#include <stdio.h>

int my_val __attribute__((section("my_section"))) = 123;
 
extern int my_section_start;
 
int main(){
    printf("%d - %d\n", my_val, my_section_start);
}

$ cat main.script 
SECTIONS
{
    .data : { 
        my_section_start = .;
        *(my_section) 
    }
}

$ gcc main.c main.script 
$ ./a.out

123 - 123


Best regards!
---
Grigory Zagorodnev
Intel Corporation

>-----Original Message-----
>From: binutils-owner@sources.redhat.com [mailto:binutils-
>owner@sources.redhat.com] On Behalf Of Pieter Arnout
>Sent: Thursday, March 31, 2005 4:27 AM
>To: binutils@sources.redhat.com
>Subject: HELP with linker script!!!
>
>I read the the Red Hat manual "Using ld, the GNU Linker", but I'm
>having trouble. Essentially, I'd like to take specific symbols and
>assign them to a memory region, rather than just take a section and
>assign it to a memory region. I can obtain the symbol values and symbol
>type from the objdump or nm output. The only examples offered in the
>manual, however, only define the output sections .bss and .data by just
>assigning everything from the .bss and .data input sections to it:
>
>SECTIONS
>{
>	. = 0x10000;
>	.text : { *(.text) }
>	. = 0x8000000;
>	.data : { *(.data) }
>	.bss : { *(.bss) }
>}
>
>I want some finer control. Does anyone know how I can go about
>ultimately assigning specific symbols (or data structures if you will)
>to a memory region? Should / can I create a section (much like .text,
>.data or .bss above) in the linker script and call it "my_section" and
>assign a list of symbols to "my_section"? Is this how I would go about
>accomplishing what I want? If so do I reference the symbols by name or
>by value when I call them out in the SECTIONS command? How does that
>look like?
>
>Additionally, where do I define the start and end regions of my stack
>and heap? I use .bss for uninitialized variables, .data for initialized
>variables, but how do I reference the beginning and end of stack and
>the beginning and end of heap?
>
>I need answers urgently.
>
>Thanks so much for your help!
>
>Pieter