expose GLOBAL_DCONTEXT to clients?

_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) on June 04, 2014 12:19:42_

This was PR 243008

Pasting notes from old conversation:

We should document that the drcontext passed to the bb and trace hooks are
thread-specific, yet the fragments are thread-shared, and any data
structures tied to the lifetime of the fragments should be allocated in
global memory (via dr_global_alloc). Temporary structures, like instr_t
and instrlist_t, are fine to be thread-private.

In fact, we provide no mechanism today for a client to allocate global IR
objects (since we don't expose GLOBAL_DCONTEXT): is that a problem?

Xref PR 216936 re-arranging of init to give a thread-private dcontext
rather than exposing GLOBAL_DCONTEXT. At exit I'm documenting that the
deletion event might pass NULL (since the dcontext is already freed).

Given that we changed the way dr_replace works (and it's
thread_private anyways), can't think of a good situation. Maybe
there'd be some reason to decode_bb once and keep it around (maybe if
going to replace it multiple times or for multiple thread? but that
would have other problems too).
and in any case replace is thread private only
Supporting it would probably only encourage people to mix allocation
contexts within instrlists which would really mess us up. So is
probably good we don't unless we come up with a compelling use case.

_Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1453_