Re: memory allocation magic numbers in glibc

[Geoff Keating <geoffk at cygnus dot com>]

> From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> Date: Fri, 1 Sep 2000 23:49:11 +0200

> 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?

One way to improve matters is to have ld.so determine its address.
Then on ppc at least the algorithm for deciding where .so files get
loaded will put them below 0x08000000 instead, at least to start with.

The code to do it would replace this code in ld.so:

/* Don't bother trying to work out how ld.so is mapped in memory.  */
  _dl_rtld_map.l_map_start = ~0;
  _dl_rtld_map.l_map_end = ~0;

-- 
- Geoffrey Keating <geoffk@cygnus.com>