From: Nick Clifton <nickc@redhat.com>
To: Pieter Arnout <pieter@powerescape.com>
Cc: binutils@sources.redhat.com
Subject: Re: HELP with linker script!!!
Date: Thu, 31 Mar 2005 15:50:00 -0000 [thread overview]
Message-ID: <424BE5A7.5060902@redhat.com> (raw)
In-Reply-To: <13ab0c503312082c7af572c83f523f4f@powerescape.com>
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
next prev parent reply other threads:[~2005-03-31 12:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-31 14:42 Pieter Arnout
2005-03-31 15:50 ` Nick Clifton [this message]
[not found] ` <29c1ff0410ff9cc2b88a3ad82d1938aa@powerescape.com>
2005-04-01 11:27 ` Nick Clifton
2005-04-01 12:53 ` Vincent Rubiolo
2005-04-01 14:05 ` Nick Clifton
2005-04-01 14:13 ` Dave Korn
2005-04-01 14:34 ` Andreas Schwab
2005-04-01 16:53 ` Pieter Arnout
2005-04-04 9:39 ` Vincent Rubiolo
2005-04-04 11:06 ` Nick Clifton
2005-04-04 11:11 ` Dave Korn
2005-04-04 11:59 ` Sergei Organov
2005-04-04 13:39 ` Nick Clifton
2005-03-31 15:08 Zagorodnev, Grigory
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=424BE5A7.5060902@redhat.com \
--to=nickc@redhat.com \
--cc=binutils@sources.redhat.com \
--cc=pieter@powerescape.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).