Re: Symbols for address space bounds

[Roland McGrath <roland at redhat dot com>]

> [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]

I redirected CC's to libc-alpha, which is a list anyone can post to.

I reordered the paragraphs I'm replying to, because the stack issue and the
data segment issue are actually unrelated.

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

When you use -Bsymbolic you are asking not to be able to use any symbols
defined in the main executable, so that's what you get. 

You can examine the ELF program headers if you really want to, using
dl_iterate_phdr (declared in <link.h>).  There is nothing that prevents a
main executable from having scattered mutable data sections if you write
your own linker script, so using the phdrs handles more cases than any pair
of symbols.  It also shows you the data segments of any shared libraries
and dlopen'd modules, which you also need to know.

> The garbage collector I maintain needs to discover most of the address
> space layout.  

When main is called, there aren't any pointers being kept live on its
caller's stack.  So I can't see why you really need anything other than the
address of the call frame for `main' as bottom-enough.  

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

There is a public interface for that is in libpthread, but a quick look at
the sources suggests it doesn't have the values for the main thread.
pthread_getattr_np will fill in a pthread_attr_t that you can then use
pthread_attr_getstack on.  We could fix it so it works the same in the main
thread as in any other.