calling code for other threads could mess up priv lib state

[derekbruening]

From bruen...@google.com on December 04, 2012 16:14:02

3rd-party lib code could store some data in priv lib tls. then on thread exit (or possibly on other cases where we invoke code for other threads, like state translation for synchwith*) when we invoke the exit event from another thread, the priv lib code could access the wrong state when trying to clean up. but, this would only happen if the client were invoking something that caches data in tls and assumes it will be called later from the same thread. I have yet to come up with an example where this might really happen.

a solution is to swap the priv tls on linux, but that's not really feasible on windows, unless we do a deep mem swap of TEB+PEB.

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1005

[derekbruening]

From bruen...@google.com on December 04, 2012 13:17:25

Issue 1006 has been merged into this issue.

[derekbruening]

From zhao...@google.com on December 04, 2012 13:32:17

An related issue: the client cannot access the tls slot on thread_exit. There should be an API to allow client to get tls slot address from dcontext on exit.

[derekbruening]

From zhao...@google.com on December 04, 2012 13:36:15

the tls I talked about is the tls allocated by dr_raw_tls_calloc.

[derekbruening]

From zhao...@google.com on December 04, 2012 13:58:38

As document says, we can use dr_get_dr_segment_base or dr_get_tls_field to obtain and store the segment base for client accessing TLS.

For private library, any library using TLS, (e.g. __thread int i; in gcc), the tls value might be messed up.