This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: HELP with linker script!!!
- From: Nick Clifton <nickc at redhat dot com>
- To: Pieter Arnout <pieter at powerescape dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Mon, 04 Apr 2005 12:03:51 +0100
- Subject: Re: HELP with linker script!!!
- References: <13ab0c503312082c7af572c83f523f4f@powerescape.com> <424BE5A7.5060902@redhat.com> <29c1ff0410ff9cc2b88a3ad82d1938aa@powerescape.com> <424D2F42.5070508@redhat.com> <c0be1d23b46c1b33af576292896526b6@powerescape.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