Closed
requested to merge i5848-false-invariant-branch-target-not-immediately-after-branch into master
Created by: lihasgupta
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.
This PR adds a test case that reproduces this issue, and then it adds some logic to make the timestamp marker at the start of a new chunk be invisible to the invariant_checker. This logic makes the added test case pass.
Issue: #5848 (closed)