<div dir="ltr">Yes, I think that makes sense. I'll remove the register macro for now, which initializes the types. The record macro I'll leave in place to ensure the toggling between boundaries doesn't get affected by this. The "nice" side effect is that it will trigger an assertion during replay, which hopefully makes this easier to triage down the line. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 7, 2019 at 12:52 AM Pavel Labath via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">labath added a comment.<br>
<br>
Jonas, would it be possible to just not intercept the functions which work with thread IDs and similar stuff (an all OSs)?<br>
Using the naive serialization approach will not be correct for these, even if the types happen to be implemented as primitive types (most likely we will need some runtime remapping of thread id's or something), so I am hoping it would not affect the ability to record&replay the recordings which don't use these functions.<br>
<br>
<br>
Repository:<br>
  rLLDB LLDB<br>
<br>
CHANGES SINCE LAST ACTION<br>
  <a href="https://reviews.llvm.org/D57475/new/" rel="noreferrer" target="_blank">https://reviews.llvm.org/D57475/new/</a><br>
<br>
<a href="https://reviews.llvm.org/D57475" rel="noreferrer" target="_blank">https://reviews.llvm.org/D57475</a><br>
<br>
<br>
<br>
</blockquote></div>