Makes drreg aware of some non-drreg spills/restores that use non-drreg TLS slots or mcontext slots. While scanning through the ilist during state restoration, if the current instr is not a drreg spill/restore but is one to a non-drreg TLS or mcontext slot, we update our book-keeping to correctly reflect whether the restored gpr is native or not. Even though we do not need to restore non-drreg spills, we still need to keep track of them. This is required to properly differentiate between tool value and app value spills (a spill is an app value spill if the gpr contains its native value at that point), which is particularly important if there's multi-phase drreg use.
If drreg doesn't understand some non-drreg restore, it will mark the gpr/aflags non-native. Any later drreg spills will then be incorrectly assumed to be tool value spills. This was the root-cause of i#4963.
Detects spills to mcontext slots by keeping track of whether any gpr holds the mcontext base, using the now public API instr_is_load_mcontext_base. Also adds a new API (instr_is_reg_spill_or_restore_ex) that takes in the gpr that currently has the mcontext base and also returns whether the given instr is an mcontext spill,
Adds tests to verify correct restoration of gpr and aflags native value when the gpr/aflags were spilled/restored previously using dr_save_reg/dr_restore_reg. Also adds a test where we instrument a clean call, and then reserve the gpr that was used to hold the mcontext base during the clean call instrumentation. This reproduces the i#4963 issue.
Verified that this indeed fixes the tool.drcacheoff.burst_threads failure. No
failure observed in 500 runs on a Github Actions runner.
Detecting spills/restores using stack will be done separately. Stack spills are seen in some cases of clean call instrumentation on AArch64.
Issue: #4963 (closed)