PC discontinuity reported as incorrect signal handler return point by invariant checker

[abhinav92003]

Today we do not check PC discontinuities between an instr followed by a "kernel xfer" marker. If there is a discontinuity, it is reported as a "Signal handler return point incorrect" invariant error later when the signal returns. E.g. the following

    28156078    20615075:       79758 ifetch       5 byte(s) @ 0x000000001a593862 66 45 89 0c fc       data16 mov    %r9w -> (%r12,%rdi,8)[2byte]
    28156079    20615075:       79758 write        2 byte(s) @ 0x0000177219ac0060 by PC 0x000000001a593862

// PC discontinuity in the kernel xfer marker address and prev instr. Not reported by invariant checker as such.
    28156080    20615075:       79758 <marker: kernel xfer from 0x1a59386d to handler>
...
    28156767    20615515:       79758 <marker: syscall xfer from 0x7ff30d21c1c9>

// Invariant error reported here due to mismatch with the pre_kernel_xfer instr (even though it is same as the kernel xfer marker address).
    28156770    20615516:       79758 ifetch       3 byte(s) @ 0x000000001a59386d 48 31 c0             xor    %rax %rax -> %rax

Such errors should be reported as what they are to avoid confusion.

[derekbruening]

Offline discussion concluded we want to do this:

A) Add our regular PC transition check to the pre-signal instruction fetch transition to the signal marker value for the interrupted PC

B) Change the signal check to compare the handler return point to the marker value, not to the pre-signal instruction fetch

[lihasgupta]

#5965 (comment)