Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit

[Roland McGrath <roland at hack dot frob dot com>]

> - add a symbol to libpthread that, during early initialization, is set
> to points to the head of the dtv slotinfo list.  I'm not sure yet how it
> would be initialized though to work under all the situations above.

This would not be too bad.  But it's of course better to have zero runtime
overhead if it's feasible, which it seems like it is.

> - special-case the _dl_tls_dtv_slotinfo_list lookup so that we can find
> it both as a member of _rtld_global, defined in ld.so, and as a
> stand-alone symbol defined in the main static executable.  

I wouldn't really call this a special case.  It's easy enough to extend the
DB_SYMBOL macro, db-symbols.h, and td_symbol_list.c to distinguish the
object name for different symbols.  Then _rtld_global is a symbol like any
other (but for LD_SO instead of LIBPTHREAD_SO).  The td_thr_tlsbase code
can just look for _rtld_global first and if it doesn't find that, look for
_dl_tls_dtv_slotinfo_list instead.

This seems like the right thing to do.

> (Can
> ps_pglobal_lookup be generally used to look up a symbol globally, if
> given a NULL object_name or somesuch?  I can't find documentation for
> this interface, and we only use it to look up symbols in libpthread_so.

It's possible there's some old Solaris documentation to be found for the
details of the proc_service.h interface, since they invented it.  But all
that really matters is how GDB has used it for glibc systems, which might
not actually adhere to any to what any such Solaris documentation
prescribes.  

In actual fact, GDB ignores the argument entirely and just does a vanilla
symbol lookup like you'd get if you said "p &symbol".  That's why it works
at all now for statically-linked libpthread, where the main executable is
where the symbols are actually found.  That said, since the interface has
the parameter, I'd still be in favor of passing in the correct object name
just pro forma (since it's really not hard to implement).

> Plus, what if we can't get to the slotinfo_list, say, because the static
> executable is stripped and it hasn't exported this dynamic symbol we
> need?)

Then td_ta_new will have failed to find the nptl_version symbol and no use
of libthread_db will ever succeed, so you won't be there to wonder.  (It
needs some local symbols like this one, so a stripped executable with
libpthread statically linked never works, even if it is a dynamic
executable that exports every global in libpthread.a.)

> > td_the_tlsbase should return success and yield the correct pointer in
> > any circumstance where the TLS block for the module and thread requested
> > has already been initialized.  It should fail with TD_TLSDEFER only when
> > the thread could not possibly have observed any values in that TLS
> > block.  That way, the debugger can fall back to showing initial values
> > from the PT_TLS segment (and refusing attempts to mutate) for the
> > TD_TLSDEFER case, and never fail to make the values the program will
> > actually see available to the user of the debugger.
> 
> This sounds like a very reasonable goal.  Is this documented anywhere?
> If not, may I paste your paragraph as a comment next to the function
> definition?  Or to its declaration?

The Solaris documentation specifies td_thr_tlsbase quite simply,
"... returns the base address of a threads local storage block..."
The quality of implementation target that I stated just seems obvious.
Use my text however you like.


Thanks,
Roland