public inbox for bfd@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@cygnus.com>
To: nickc@cygnus.com
Cc: bfd@cygnus.com
Subject: Re: Linker script documentation
Date: Tue, 21 Apr 1998 20:06:00 -0000	[thread overview]
Message-ID: <199804220306.XAA05648@subrogation.cygnus.com> (raw)
In-Reply-To: <199804212224.PAA30193@elmo.cygnus.com>

   Date: Tue, 21 Apr 1998 15:24:09 -0700
   From: Nick Clifton <nickc@cygnus.com>

   I have read through your new document and I have a few questions to
   ask/points to raise:

Thanks a lot for the comments.  This sort of thing helps a lot.

   In the 'Simple Linker Script Example' it says:

	The remaining lines define the `.data' and `.bss' sections in the
     output file.  The `.data' output section will be at address
     `0x8000000'.  When the `.bss' output section is defined, the value of
     the location counter will be `0x8000000' plus the size of the `.data'
     output section.  The effect is that the `.bss' output section will
     follow immediately after the `.data' output section in memory.

   What about alignment ?  Will the .bss section be automatically aligned
   to the next word boundary ?  (I asssume that later sections in the
   document will answer that is question - I have not read that far yet.
   But people new to linker scripts may also be wondering about this
   question at this point in the text).


I changed this bit of text to this:

The remaining lines define the @samp{.data} and @samp{.bss} sections in
the output file.  The linker will place the @samp{.data} output section
at address @samp{0x8000000}.  After the linker places the @samp{.data}
output section, the value of the location counter will be
@samp{0x8000000} plus the size of the @samp{.data} output section.  The
effect is that the linker will place the @samp{.bss} output section
immediately after the @samp{.data} output section in memory

The linker will ensure that each output section has the required
alignment, by increasing the location counter if necessary.  In this
example, the specified addresses for the @samp{.text} and @samp{.data}
sections will probably satisfy any alignment constraints, but the linker
may have to create a small gap between the @samp{.data} and @samp{.bss}
sections.

   In 'PROVIDE' it says:

	Here is an example of using `PROVIDE' to define `etext':
	  SECTIONS
	  {
	    .text :
	      {
		*(.text)
		_etext = .;
		PROVIDE(etext = .);
	      }
	  }

	In this example, if the program defines `_etext', the linker will
     give a multiple definition error.  If, on the other hand, the program
     defines `etext', the linker will silently use the definition in the
     program.  If the program references `etext' but does not define it, the
     linker will use the definition in the linker script.

   I think this example is slightly confusing, since it is not
   immediately obvious that 'etext' and '_etext' are seperate symbols.

I really want to use etext and _etext, since this is a common idiom
found in several linker scripts.  I changed the text to this:

In this example, if the program defines @samp{_etext} (with a leading
underscore), the linker will give a multiple definition error.  If, on
the other hand, the program defines @samp{etext} (with no leading
underscore), the linker will silently use the definition in the program.
If the program references @samp{etext} but does not define it, the
linker will use the definition in the linker script.

   {My eyes are starting to cross, so I will leave off reading about
   overlays and other fun thinhs until tomorrow.  In the meantime I also
   have a small patch to propose which fixes a spelling mistake, and
   rewords a paragraph to make it clearer (IMHO).}

I checked in the spelling mistake.  I changed the paragraph to this:

The first line inside the @samp{SECTIONS} command of the above example
sets the value of the special symbol @samp{.}, which is the location
counter.  If you do not specify the address of an output section in some
other way (other ways are described later), the address is set from the
current value of the location counter.  The location counter is then
incremented by the size of the output section.  At the start of the
@samp{SECTIONS} command, the location counter has the value @samp{0}.

Thanks again.

Ian

  reply	other threads:[~1998-04-21 20:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-04-21 15:25 Nick Clifton
1998-04-21 20:06 ` Ian Lance Taylor [this message]
  -- strict thread matches above, loose matches on Subject: below --
1998-04-13 14:05 Ian Lance Taylor

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=199804220306.XAA05648@subrogation.cygnus.com \
    --to=ian@cygnus.com \
    --cc=bfd@cygnus.com \
    --cc=nickc@cygnus.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).