From: "Boehm, Hans" <hans_boehm@hp.com>
To: "MOSBERGER, DAVID (HP-PaloAlto,unix3)" <davidm@hpl.hp.com>
Cc: "'Hans_Boehm@hpl.hp.com'" <Hans_Boehm@hpl.hp.com>,
"'tromey@redhat.com'" <tromey@redhat.com>,
libc-hacker@sources.redhat.com
Subject: Symbols for address space bounds
Date: Tue, 10 Dec 2002 16:18:00 -0000 [thread overview]
Message-ID: <75A9FEBA25015040A761C1F74975667DA13514@hplex4.hpl.hp.com> (raw)
[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
reply other threads:[~2002-12-11 0:18 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=75A9FEBA25015040A761C1F74975667DA13514@hplex4.hpl.hp.com \
--to=hans_boehm@hp.com \
--cc=Hans_Boehm@hpl.hp.com \
--cc=davidm@hpl.hp.com \
--cc=libc-hacker@sources.redhat.com \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).