ldrex..strex pair constraints challenge instrumentation and even core operation

A ldrx..strex pair has some constraints that make inserting instrumentation in between, or even core DR operation, challenging:

From the ARMv8 manual, section E2.10.5:

  An implementation might clear an exclusive monitor between the LoadExcl
  instruction and the StoreExcl, instruction without any application-related
  cause. For example, this might happen because of cache evictions.  Software
  must, in any single thread of execution, avoid having any explicit memory
  accesses or cache maintenance instructions between the LoadExcl instruction
  and the associated StoreExcl instruction.

  Implementations can benefit from keeping the LoadExcl and StoreExcl
  operations close together in a single thread of execution. This minimizes
  the likelihood of the exclusive monitor state being cleared between the
  LoadExcl instruction and the StoreExcl instruction. Therefore, for best
  performance, ARM strongly recommends a limit of 128 bytes between
  LoadExcl and StoreExcl instructions in a single thread of execution.

One-time switches back to dispatch (during code discovery, or synchall or something) should be fine, because the ldrex..strex code has to loop and be prepared to fail a few times. The problems are all related to inserted memory operations that execute every single time.

Thus we have problems with:

• Stolen register mangling in between or on ldrex/strex themselves
• Inserted instrumentation

There could be multiple cbr's in between ldrex and strex, so do we give up on getting into a single bb? Should we study sequences we see in the wild to see if having some assumptions would make the problem drastically easier? Should we have a special trace head trigger and stop supporting -disable_traces?

One suggestion is adding a check for each instrumentation memory reference to skip if it's in the middle of ldrex/strex: but this gets tricky without allowing memory refs itself.