ASSERT drcachesim invariant checker falsely triggers "Branch target not immediately after branch" when branching crosses chunks

Created by: lihasgupta

Describe the bug

Consider the following snippet:

126673902: T676257 ifetch       7 byte(s) @ 0x0000000010e33e22 80 bd 4f ff ff ff 00 cmp    0xffffff4f(%rbp)[1byte] $0x00
126673903: T676257 read         1 byte(s) @ 0x00007f2c726d5dff by PC 0x0000000010e33e22
126673904: T676257 ifetch       6 byte(s) @ 0x0000000010e33e29 0f 88 24 85 3e 00    js     $0x000000001121c353
126673905: T676257 <marker: chunk footer #8>
126673906: T676257 <marker: timestamp 13311683087087727>
126673907: T676257 <marker: tid 676257 on core 16>
126673908: T676257 ifetch       7 byte(s) @ 0x0000000010e33e2f 48 8d 8d 38 ff ff ff lea    0xffffff38(%rbp) -> %rcx
126673909: T676257 ifetch       4 byte(s) @ 0x0000000010e33e36 48 8b 41 10          mov    0x10(%rcx)[8byte] -> %rax

The timestamp at 126673906 is a start-of-chunk timestamp (we get these timestamps at the start of every chunk) and is NOT used for interleaving. All analysis tools should ignore this timestamp. However, the invariant checker triggers the "Branch target not immediately after branch" invariant. This behavior is incorrect.

To Reproduce This can easily be reproduced in a synthetic test case by having some branching, then the end of a chunk, and start of a new chunk. The test case will trigger this invariant even if the branch target does immediately follow the branch.

Expected behavior There should be no invariant error.