From: "H. J. Lu" <hjl@lucon.org>
To: linux-ia64@vger.kernel.org
Subject: Re: [Fwd: RE: elf header bits for page migration support......]
Date: Sun, 15 May 2005 19:45:28 +0000 [thread overview]
Message-ID: <20050515194528.GA17773@lucon.org> (raw)
In-Reply-To: <4287A223.6010804@sgi.com>
On Sun, May 15, 2005 at 12:25:23PM -0700, Jack Carter wrote:
> Ray Bryant wrote:
>
> >2/2
> >
> >-------- Original Message --------
> >Subject: RE: elf header bits for page migration support......
> >Date: Fri, 13 May 2005 10:54:11 -0700
> >From: Luck, Tony <tony.luck@intel.com>
> >To: Ray Bryant <raybry@engr.sgi.com>
> >CC: <linux-ia64@vger.kernel.org>
> >
> >>The alternative being suggested is to mark the elf header of object
> >>files
> >>that should only have shared pages migrated, or that should not be
> >>migrated
> >>(e. g. you don't want to migrate /bin/csh all the time.)
> >
> >
> >No ... I'd like you to replicate shared pages (of /bin/bash ... I
> >personally don't
> >care what happens to the pages of /bin/csh :-)
> >
> >>Can I use some bits (I need 2) of p_flags of Elf64_Phdr for this
> >>purpose?
> >>If so, which bits?
> >>
> >>If not which other fields can I use?
> >
> >
> >I think H.J's suggestion of an extra section makes sense ... then you
> >can go
> >wild with as many bits as you can dream up uses for, rather than
> >constraining
> >yourself to squeeze into just 2 bits.
> >
> >-Tony
> >
> >
> The fun part of this is that if you introduce a new section and
> a new segment to point to it (only segments exist at load time)
> then you need to really muck with the bits because you will be
> growing the program header (segment table) and the section header
> as well as putting in a new section.
>
> If this information is to be used by rld it will need to be in some
> element of the bits that will be loadable and that means the new
> section needs to be either contiguous to a currently marked (PT_LOAD)
> segment with it's size increase due to the new section or the new section
> needs to be in it's own segment which means increasing the number
> of PT_LOAD segment entries.
I am not sure I understand what you are saying. As far as I know,
you don't need PT_LOAD for it. The dynamic linker will handle it in
program header just fine.
H.J.
next prev parent reply other threads:[~2005-05-15 19:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-15 19:25 [Fwd: RE: elf header bits for page migration support......] Jack Carter
2005-05-15 19:45 ` H. J. Lu [this message]
2005-05-15 20:08 ` Jack Carter
2005-05-15 20:33 ` H. J. Lu
2005-05-16 4:29 ` Ray Bryant
2005-05-16 4:42 ` H. J. Lu
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=20050515194528.GA17773@lucon.org \
--to=hjl@lucon.org \
--cc=linux-ia64@vger.kernel.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