public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@zembu.com>
To: hjl@lucon.org
Cc: binutils@sourceware.cygnus.com
Subject: Re: Variable page size for ELF
Date: Sun, 11 Jul 1999 08:13:00 -0000	[thread overview]
Message-ID: <19990711151244.1933.qmail@daffy.airs.com> (raw)
In-Reply-To: <19990711034758.0B58C57B9@ocean.lucon.org>

   Date: Sat, 10 Jul 1999 20:47:58 -0700 (PDT)
   From: hjl@lucon.org (H.J. Lu)

   >    I got a request to support variable page size for ELF. It turned out
   >    not too hard to implement. Is that interesting to anyone? Should I
   >    send in my patch which adds "--page-size SIZE" to ld?
   > 
   > It's hard for me to imagine an application for that.  However, if
   > there is some reason that it is useful, in a way that can not be
   > handled by simply changing the linker script, then I have no objection

   The problem is get_elf_backend_data (abfd)->maxpagesize in BFD and
   MAXPAGESIZE in linker script. I did

   1. Add functions to get/set get_elf_backend_data (abfd)->maxpagesize.
   2. Made MAXPAGESIZE in linker script a variable.

   Now the ELF linker script has

   MAXPAGESIZE != 0 ? MAXPAGESIZE : ${MAXPAGESIZE}

   in place of ${MAXPAGESIZE}.

I guessed that much, but I still find it hard to imagine an
application.  We shouldn't provide features merely because we can; we
should stick to providing features that are meaningful and useful.

Merely changing the linker script is not a terribly useful feature,
since people can already change it anyhow.  The interesting new
feature here is changing the use of maxpagesize in the backend data
structure.  However, the only interesting use of the backend
maxpagesize is to set up the program headers, and you can already do
that using PHDRS in the linker script.

So I don't see any new functionality in the --page-size option.  Of
course, if it is a useful shorthand, we should add it anyhow.  But
that is where I wonder what the application is, since I don't see that
either.

By the way, MAXPAGESIZE should probably not be used as a symbol name
in a linker script, because it is part of the user's name space.
Something like __MAXPAGESIZE would be better.

   > to such an option.  At first glance it seems like anything you can do
   > by changing the page size you can do by changing the linker script,
   > using the PHDRS option.

   How does PHDRS work?

It's documented.  Basically, it lets you set the program headers in
the linker script.

Ian

  reply	other threads:[~1999-07-11  8:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-07-10 19:24 H.J. Lu
1999-07-10 19:44 ` Ian Lance Taylor
1999-07-10 20:47   ` H.J. Lu
1999-07-11  8:13     ` Ian Lance Taylor [this message]
1999-07-11 10:38       ` H.J. Lu
1999-07-11 13:02         ` Richard Henderson
1999-07-11 13:22           ` H.J. Lu
1999-07-11 15:11             ` Richard Henderson
1999-07-11 16:45         ` 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=19990711151244.1933.qmail@daffy.airs.com \
    --to=ian@zembu.com \
    --cc=binutils@sourceware.cygnus.com \
    --cc=hjl@lucon.org \
    /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).