Ahhh, I think I remember you. I found your patches to implement
a per process version of TASK_UNMAPPED_BASE, and was wondering
if this might make it into the "official" release.
I had once submitted a "system wide" version of this idea, but it was not
accepted. When newer linux kernels were released, my patch no
longer worked, and I did not have the time to keep upgrading it.
In my case, I have some control on the linking of my executable. It is
built with a runtime library that I don't have source to, and that is
where the need for the contiguous memory comes into play. I was
thinking I could link against a clib.a since all the other libraries will
still load releative to TASK_UNMAPPED_BASE.
We are probably within a year or two of 64 bit needs anyway, but
that requires a new proprietary compiler, so we will have squeeze out
all 32 bits worths of address space for a while.
And if I got it correct, we should be able to get another 1/4 gig using
the AMD Hammer in 32 bit mode. I read where it's compatibility
mode lets a 32 bit process use all 4 gigs since the 64-bit-kernel would
use space outside the 32 bit space of these sorts of legacy processes.
> > > > So, does anyone know how to* this problem. Say, is there a
> > > > way to modify the clib.so to load at a different offset.
> > > > Or, does this mean that redhat built a clib that is not reloacatable?
> > > IIRC, we had a discussion on this ng (or .apps, or possibly c.u.p.)
> > > about this very thing about 2 weeks ago. Check the history, I'm
> > > sure it'll turn up.
> > Last time the poster could tell us that this change happened
> > between 7.2 and 7.3. It turned out that with 7.3 the simplest
> > workaround would be to install the i386 version of glibc
> > instead of the i686 version. If you want a better solution,
> > you will have to grab the source rpm, modify the spec file,
> > and build a new rpm file.
> It is now in the faq:
> Kasper Dupont -- der bruger for meget tid p? usenet.
> Don't do this at home kids: touch -- -rf