[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MIT-Scheme-devel] Re: Executable memory: some apps that work on RH9 don

From: Roland McGrath
Subject: [MIT-Scheme-devel] Re: Executable memory: some apps that work on RH9 don't on FC1
Date: Mon, 17 Nov 2003 19:35:20 -0800

> I appear to be missing some of the context of this discussion.  What
> kernels have this behavior?  I have run MIT/GNU Scheme on Debian
> unstable using many different 2.4 and a handful of 2.6-test kernels,
> and I haven't seen this problem.

This is about Fedora Core 1 kernels (, which have
some changes to how mapping addresses are chosen.

> That mapping code dates back to the days of libc5.  At that time, if
> you tried to map some space that overlapped a shared library, you got
> an error.

I can't speak to that vintage of Linux libc or Linux kernels.  The
specification of mmap has always been that MAP_FIXED overwrites other mmap
mappings, and in no recent time have shared libraries been anything other
than mmap mappings.

> But the problem remains that this code doesn't do what it's supposed
> to.  Is there some way for me to probe the address space to find the
> largest hole in a given region of the space?  (Not using signal
> handlers to catch SIGSEGV traps!)

If you want a Linux-specific kludge, you can always see the complete memory
map by looking at /proc/self/maps.  If you want a portable programmatic
solution correct for POSIX systems with mmap, the only kind of probing you
can do is try large mmaps without MAP_FIXED and see where they fit.

> [...] we need the largest possible block of space under 2^26 -- ideally
> all of it.

I see.

> It's possible to modify the implementation to handle a block outside
> of this space

I don't think you should have to.  Your address space is yours to control.
You just haven't been exercising control in the specified proper ways.

> Faced with this situation, I'll probably just statically link the
> program.

Support for static linking is severely limited in a variety of ways.
If you make any but the most low-level use of system library facilities,
static linking is almost certainly a recipe for future aggravation.

> IMO it's a bug that the application doesn't have any control over its
> address space.  

The application has complete control over its address space within the size
limits provided by the kernel (3GB with most Linux kernels, 4GB-16MB with
some FC1 kernels).  Presumption of what addresses the kernel will use in
cases where the specification says it may choose any address, is not an
aspect of the control interface.

> I should be able to tell the linker and loader that certain areas are
> reserved.  That's possible with the linker, but I'm not aware of any way
> to control the loader.

I'm not sure what level of control you have in mind when you distinguish
what you can specify to the linker and to the loader, or whether by "the
loader" you mean the kernel's loading of executable files, or the dynamic
linker's loading of DSOs, or both.  I don't see why it's not sufficient to
specify the layout you want at link time.  That you can do.  If your
executable contains PT_LOAD program header entries for each region you want
reserved, it will be.  You can use entries with none of PF_[RWX] set to get
PROT_NONE mappings that you can overwrite later with MAP_FIXED mappings.

> So why does the kernel care where shared libraries are mapped?  Why is
> the application working for the kernel instead of the other way around?

You are misrepresenting reality.  The kernel does not care.  You specified
that you did not care, and so the kernel is doing what it thinks might be
best for you given the constraints you have specified.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]