RE: Symbols for address space bounds

["Boehm, Hans" <hans_boehm at hp dot com>]

Thanks.  That helps significantly, but it doesn't quite solve all the problems:
> From: Roland McGrath [mailto:roland@redhat.com]
> > 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.
> 
> ...
> 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.
That sounds like a good idea.  Jakub already supplied a patch to use dl_iterate_phdr in the collector whenever possible to find dynamic library data segments.  Is there any documentation beyond the dl_iterate_phdr source code and what Jakub sent me? 

> 
> > 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. 
That would indeed be fine.  But it's also hard to get from library code.  (If the library is loaded as a malloc replacement with LD_PRELOAD, I guess it should be possible to intercept main.  But that seems very messy at best, in the general case.)

> 
> > 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.
Currently we get the stack base of everything but the main thread by intercepting pthread_create, using one of several mechanisms.  Although it would be great to avoid that, it's probably hard for other reasons.  Thus the hard problem is the main stack, or the only stack in a single-threaded process.  It's important that this mechanism work either with or without pthreads.  I guess that doesn't completely preclude using pthread_getattr_np, but I don't think it's a beautiful solution.

Hans