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

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

> No, but I can confirm that, after this change, td_thr_tlsbase may return
> as much garbage for Static TLS modules as the current code may for
> dynamic TLS modules, since it doesn't check generation counts.

That sounds like you're saying your change causes a regression, which
incidentally has the same failure mode as an existing bug for a
different circumstance.  The existing bug existing is reason to fix it,
and indeed the existing bug is not the fault of your change.  But that
bug existing is not an excuse to cause a regression in a related case.

> It would be possible to change it so that it compares the generation
> count of the module and that of the DTV, so as to avoid returning
> garbage; it could even compute the address for Static TLS modules, so
> that we kept on returning the same pointer, regardless of what is
> actually in the DTV.  Should it?

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.

I gather from what you've said that it does not already meet that
standard in all cases.  We should fix that, but do it in a way that does
not leave any intermediate state that is a regression from the status
quo ante.


Thanks,
Roland