This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
[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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |