Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 8 Nov 2001 11:48:02 -0800
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        Doug Rabson <dfr@nlsystems.com>
Cc:        Peter Wemm <peter@wemm.org>, ia64@FreeBSD.ORG
Subject:   Re: Region usage
Message-ID:  <20011108114802.B13009@kayak.xcllnt.net>
In-Reply-To: <Pine.BSF.4.33.0111081124080.88856-100000@herring.nlsystems.com>
References:  <20011107145044.A10229@kayak.xcllnt.net> <Pine.BSF.4.33.0111081124080.88856-100000@herring.nlsystems.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 08, 2001 at 11:28:17AM +0000, Doug Rabson wrote:
> 
> True. I can just about imagine an ILP32 app wanting to share address
> spaces with other apps but it seems unlikely.

But isn't that the task of our VM subsystem and doesn't it already
handle it?

Put differently: user space should not know about regions, right?

> > > > I see little advantage to have text, data/heap and stack be
> > > > seperate regions, other than a nice side-effect while debugging
> > > > (it's easy to see what an address references). The possibility
> > > > of either of those segments taking up more than, say, 48 bits
> > > > is very small ATM, although it's possible that I'm stuck in the
> > > > a-couple-of-megabytes-is-large mindset and thus underestimate
> > > > a typical "large" application.
> > >
> > > A truly 'large' application can always overflow into the other regions.
> >
> > The question is if this can be done automagically or if it requires
> > compile-time options or even ELF object tuning (ie flags).
> 
> This would happen automatically. If the elf sections were rooted in
> specific regions, the loader would automatically put them there and the VM
> system would allocate spaces as required. If a running app wants to use a
> new region, its as simple as giving an explicit address to mmap(2).

Both cases are not automagically. To have the segments rooted in a
specific region, I probably need to tell the linker to arrange for
that. This means compile/link time visible differences. In the second
case it's even a programmer visible difference.

The second case is clearly unwanted. I'm not sure I like the first
case as well, because it definitely means an incompatibility with
the GNU toolchain, unless the options are already there.

If, on the other hand, our loader would size the segments and
create either a single region address space or a multi-region
address space based on some heuristics, then that would qualify
as automagically. It would handle the "large" application case
without any visible differences...

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel@xcllnt.net

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ia64" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011108114802.B13009>