Open derekbruening opened 8 months ago
Looks like we have a pre-existing bug on the multi-dcontext solution: #1595. It points at the AArch32 global decode_state_t
and encode_state_t
used for GLOBAL_DCONTEXT
: so for AArch32, encoding is problematic as well as decoding and both have races even without switching ISA modes.
As documented at https://dynamorio.org/API_BT.html#sec_isa, each instr_t has its own ISA mode for encoding. However, for decoding, the dcontext's ISA mode is used, and instandalone mode we have just the global dcontext which uses a global ISA mode var. Thus, there is not good support for a standalone tool that wanted to decode multiple ISA modes in separate tool threads.
One possibility would be to honor the ISA mode set in the instr_t passed for decoding, for decoding routines that take an instr (so this would not help something like decode_sizeof).
Another possibility would be to use toolchain TLS support to create per-thread dcontext_t instances in standalone mode, which would give us lock-free local heap for non-STATIC_LIBRARY for thread-private objects.