[lkml]   [2001]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Repost: could ia32 mmap() allocations grow downward?
On Thu, 13 Dec 2001, Petr Vandrovec wrote:

> If you have legacy app, how it comes that it uses mmap?

Very good question. The app per se does not call mmap(), but mmap() is
called once when I execute it. So it must be something from libc:

[whitney@mf1 whitney]$ ldd `which magma`
not a dynamic executable
[whitney@mf1 whitney]$ magma
[ . . .]
[2]+ Stopped magma
[whitney@mf1 whitney]$ cat /proc/`pidof magma`/maps
08048000-08afb000 r-xp 00000000 21:07 64318 magma
08afb000-08c3e000 rw-p 00ab2000 21:07 64318 magma
08c3e000-0bc54000 rwxp 00000000 00:00 0
40000000-40001000 rw-p 00000000 00:00 0
bfffd000-c0000000 rwxp ffffe000 00:00 0

> So maybe MAGMA uses some API which it should not use under any
> circumstances... Such as that you linked it with libc6 stdio.

Indeed. How can I avoid the map at 0x40000000? Must I avoid using
certain glibc2 functions, and then link the executable carefully to leave
out their initialization routines? Or can I set some magic environment
variable to tell glibc2 to mmap() the single map with MAP_FIXED at a
higher addresss? Of course I could modify glibc2 so that it does all (or
most) of its mmap()'s with MAP_FIXED at a higher address. Is there an
alternative libc that might work out of the box or require less

So it seems like for MAGMA I should be able to work around the fact that
mmap()'s start at 0x40000000. But as difficulties with other programs
come up here fairly regularly, I still think it makes sense to fully
understand the downside of modifying the kernel to allocate mmap() VMAs
going downward. If the downside is small, I think it is a good tradeoff.

Cheers, Wayne

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:14    [W:0.054 / U:0.696 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site