RE: Conservative GC and glibc data structures

[Roland McGrath <roland at redhat dot com>]

To follow up on this: I added a couple of things to glibc-2.4, which is now
available and will be seen on new systems like Fedora Core 5 next week.
These give one new avenue to address the problems you mentioned about TLS
in particular.  (When I get a chance, I will write separately about your
issues relating to symbol interposition.  Those issues are well-understood,
but it will take a while to write up the brain dump, and it doesn't boil
down to any simple answers.)

The additions in glibc-2.4 give you ways to see the TLS blocks allocated.
You already use dl_iterate_phdr.  I've extended the `struct dl_phdr_info'
that it gives your callback with two new fields:

    /* If there is a PT_TLS segment, its module ID as used in
       TLS relocations, else zero.  */
    size_t dlpi_tls_modid;

    /* The address of the calling thread's instance of this module's
       PT_TLS segment, if it has one and it has been allocated
       in the calling thread, otherwise a null pointer.  */
    void *dlpi_tls_data;

The modid value is probably not of any use to you.  If you wish to test it,
it will be zero when there is no TLS segment in that module, and nonzero
(and unique among modules presently loaded) when there is one.  (You will
of course see the PT_TLS in one of the dlpi_phdr elements too.)

The dlpi_tls_data pointer tells you the block of roots you need to know,
for the thread that calls dl_iterate_phdr.  It will be null for a module
that does have a PT_TLS when the calling thread has not lazy-allocated it
yet.  To find the size of that block (which is of course the same for all
threads), you need to find the PT_TLS element in dlpi_phdr and get its
p_memsz value.  (I didn't make the function do that for you, since it would
have to do exactly the same work itself.)

The same information is also now available via dlinfo (see <dlfcn.h>),
using the new RTLD_DI_TLS_MODID and RTLD_DI_TLS_DATA request codes.
Here too, the data pointer is the current thread's information.
You call dlinfo on an individual module, rather than iterating through all.
dlinfo does not take locks, which dl_iterate_phdr does.

Both of these are "soft" ABIs.  Only the new glibc-2.4 header files
(link.h, dlfcn.h) define the new RTLD_DI_* values and the longer version of
`struct dl_phdr_info'.  However, if you wanted to make your sources
hard-code the missing values and/or struct layout, then you could build a
single binary that can cope with either an older libc DSO (2.3) or a newer
one (2.4) being loaded at run time.  For dl_iterate_phdr, the second
argument to the callback gives the struct size so you can see if the new
fields are defined.  For dlinfo, passing the new request codes to an old
DSO will get a -1 return with dlerror reporting "unsupported dlinfo request".

I hope this helps.  These additions were simple and noninvasive to make and
were what was feasible for the glibc-2.4 time frame.


Thanks,
Roland