ld.so.1 "overflow" mapping

[Matthew Clark <linux dot matthew at gmail dot com>]

I'm trying to do some software fault injection into a PPC based system
for some reliability measurement, but I'm running into a conundrum
regarding the memory mapping and I thought someone here might have
answers.  Basically, the program makes so many linkages, that I'm
seeing an ldd of:

ldd /usr/local/bin/srp
      libgosrk.so => /usr/local/lib/libgosrk.so (0x0ff67000)
      libgokey.so => /usr/local/lib/libgokey.so (0x0ff44000)
      libpthread.so.0 => /lib/libpthread.so.0 (0x0fe30000)
      libdl.so.2 => /lib/libdl.so.2 (0x0fe60000)
      libc.so.6 => /lib/libc.so.6 (0x30009000)
      /lib/ld.so.1 (0x0ffd0000)

This is also indicated by catting the /proc/<pid>/maps of the binary
during execution.  I'm being thrown by libc being mapped into
0x30000000 which (from what I've read on PPC memory management on
linux) is meant for dynamic memory allocations (eg, malloc).  But
because of all the mappings at between 0xff00000 and 0x10000000 (where
the vma of the srp binary starts at 0x10000000), I'm guessing that
libc is being "overflowed" into the 0x30000000 range by ld.so.1.  Can
anyone verify this behavior by ld.so.1?

Thanks!

Matt