public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Vincent Rubiolo <vincent.rubiolo@windriver.com>
To: Pieter Arnout <pieter@powerescape.com>
Cc: binutils@sources.redhat.com
Subject: Re: HELP with linker script!!!
Date: Mon, 04 Apr 2005 09:39:00 -0000	[thread overview]
Message-ID: <42510B52.2090002@windriver.com> (raw)
In-Reply-To: <c0be1d23b46c1b33af576292896526b6@powerescape.com>

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

  reply	other threads:[~2005-04-04  9:39 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
     [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 [this message]
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=42510B52.2090002@windriver.com \
    --to=vincent.rubiolo@windriver.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).