public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Timothy Wall <twall@tiac.net>
To: binutils@sourceware.cygnus.com
Subject: Linker overlay pages strategy [Q]
Date: Thu, 19 Aug 1999 19:37:00 -0000	[thread overview]
Message-ID: <37BCBF63.BAE42A52@tiac.net> (raw)

I'm trying to figure out the best way to handle a processor's dual
address space as it relates to the linker and script files.  Fortunately

I don't have to do compatibility with the other vendor's linker scripts,

but there are a few options I need to include.  First is being able to
specify separate allocations for load-time and run-time addresses of
sections, and second, being able to map into two overlapping addrss
spaces.

Most links for this target (TIC54X) specify memory regions for PROG
(usually ROM) and DATA (maybe on-chip, maybe not), these usually get
designated pages 0 and 1, respectively.

Some sections may be designated to have a different "run time"
allocation, which may be on the same or a different page.  e.g.

MEMORY
{
    PAGE 0: PROG: ORIGIN 0x0000 LENGTH 0xFF00
   PAGE 1: DATA: ORIGIN 0x0080 LENGTH 0xFF80
}

SECTIONS
{
    .text: load = PROG, run = 0x800
    .cinit: load = PROG, run = DATA
}

So what this does is effectively allocate two sections per section.  The

text section is expected to be relocated before running (so all
relocations are done for the "run" address).
Note that the memory "pages" have overlapping address space.

So for the first item, I can link each section in twice.
The overlay functions more or less provide the second item, though I'd
prefer to keep the semantics closer to the above example (which
represents putting sections into two memory areas which happen to have
the same address) rather than using the OVERLAY semantics (which puts
more than one section into the same address).

Any comments, ideas, references?  Please CC twall@tiac.net, as I am not
subscribed to the list.

Thanks
Tim Wall




             reply	other threads:[~1999-08-19 19:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-08-19 19:37 Timothy Wall [this message]
1999-08-19 23:00 ` 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=37BCBF63.BAE42A52@tiac.net \
    --to=twall@tiac.net \
    --cc=binutils@sourceware.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).