Re: memory allocation magic numbers in glibc

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>]

On Fri, 01 Sep 2000, Geoff Keating wrote:
> > From: SL Baur <steve@turbolinux.co.jp>
> > Date: 01 Sep 2000 21:19:06 +0900
> >
> > Why does the following program give two different numbers depending
> > upon how it is invoked?
>
> Because the memory map is different.

Yes, and it seems something goes wrong with the memory map. On Linux/PPC, the 
icondata/tst-loading testcase allocates memory like this if called directly:

  0x30000000++ ld.so
  0x10000000++ tst-loading, malloc allocates behind it, upwards
  0x10000000-- .so shared libs, memory is allocated starting from top

Now, when using ld.so.1 manually to run the programs as in the testsuite, 
memory is allocated as follows:

  0x10000000++ tst-loading
  0x10000000-- .so shared libs, memory is allocated starting from top
  0x08000000++ ld.so, malloc allocates behind it, upwards

So it is quite clear that after a while the area between 
0x08000000..0x10000000 is stuffed with shared libs and malloc() returns 
ENOMEM then and the testcase fails.

I guess on alpha something similar happens.

How do we handle that? Why is ld.so loaded at different addresses anyway?

Franz.