Symbols for address space bounds

[Boehm, Hans]

[I'm forwarding this mail on behalf of Hans Boehm, because it is
 relevant to libc-hacker and he can't post to the list himself.
 I hope that's OK. --david]

Is there some way to find the base of the main stack for recent glibc
versions, for which __libc_stack_end is private?  How about an
equivalent for __libc_ia64_register_backing_store_base?  If not, could
we make those available in some other way, e.g. through a nonportable
sysconf-like call?

It would be nice if it were also possible to find the bounds of the
main program data/bss segments using a similar mechanism.
__data_start and _end can mostly be used this way.  But, it was
pointed out on java@gcc.gnu.org recently
(http://gcc.gnu.org/ml/java/2002-12/msg00057.html) that this
apparently doesn't work when the symbols are referenced from a dynamic
library in the presence of -Bsymbolic.

Background:
The garbage collector I maintain needs to discover most of the address
space layout.  Thus its clients (gcj, w3m, the mono project, and
others) are indirectly dependent on some facility for doing so.  I
wouldn't be surprised if there were other applications
(e.g. checkpointing) that used a similar facility.

Much of this can be deduced from /proc under Linux.  And indeed we
currently do so in some cases if the above symbols are unavailable.
But this isn't very appealing to me for a number of reasons:

1) I would prefer to have gcj-compiled applications function without
   /proc mounted.  /proc shouldn't be necessary on small devices.  I
   think a potentially important application of gcj is to build small
   security-sensitive applications without buffer overrun risks.
   These may well run in a chrooted environment without /proc.
2) Getting some of this information from /proc is ugly, not always
   robust, and increases startup overhead.  The libc startup code
   either already knows this stuff, or could get it very cheaply.
3) There isn't a clean way to get the equivalent of
   __libc_ia64_register_backing_store_base.

Thanks.

Hans