[drcachesim] Provide branch target for branch just prior to signal delivery

[derekbruening]

For #2638 we aided core simulation of drcachesim traces by guaranteeing that a branch's target immediately followed it and would not be interrupted by a thread switch.

But then in #3937 we allowed a signal to arrive after a branch, and removed the branch target guarantee for that case.

This issue covers addressing that lack of guarantee. DR did execute that branch,
and after the signal it will go to the branch target rather than re-execute
the branch instruction. Yet the core simulator doesn't know the branch
target, especially for an indirect branch. It seems like we should figure out
a solution here. Previously we discarded the idea of explicitly storing the
branch target. Maybe we could insert the branch target as an instruction fetch
entry that gets interrupted and re-executed post-signal (easiest to do this in
the tracer as the post-processor will have a hard time finding the target, just
like a core simulator).

[derekbruening]

To get the ind br target: we'd have to augment dr_kernel_xfer_info_t?

[derekbruening]

It looks like the current info passed to the kernel xfer event does have
what we want, including indirect branch targets:

$ ctest -V -R histogram.offline
$ ninja && bin64/drrun -t drcachesim -indir suite/tests/tool.histogram.offline.drmemtrace.signal_invariants.2558442.0550.dir -simulator_type view 2>&1 | less

  0x00007f59e9bcfadb  0f 0b                ud2a
<marker: kernel xfer to handler>
<marker: kernel interrupted pc 0x7f59e9bcfadb>
<marker: timestamp 13268857302478344>
<marker: tid 2558442 on core 3>
  0x00007f59e9bcfac4  0f 18 0c 25 01 00 00 prefetcht0 0x01
                      00
  0x00007f59e9bcfacc  e9 8c fc ff ff       jmp    $0x00007f59e9bcf75d


  0x00007f59ed638725  5d                   pop    %rbp
  0x00007f59ed638726  c3                   ret
<marker: kernel xfer to handler>
<marker: kernel interrupted pc 0x7f59e9bcfa13>
<marker: timestamp 13268857302643640>
<marker: tid 2558442 on core 3>
  0x00007f59e9bcfac4  0f 18 0c 25 01 00 00 prefetcht0 0x01
                      00
  0x00007f59e9bcfacc  e9 8c fc ff ff       jmp    $0x00007f59e9bcf75d
  0x00007f59e9bcf75d  55                   push   %rbp
  0x00007f59e9bcf75e  48 89 e5             mov    %rsp, %rbp
  0x00007f59e9bcf761  48 83 ec 40          sub    $0x40, %rsp
  0x00007f59e9bcf765  89 7d dc             mov    %edi, -0x24(%rbp)
  0x00007f59e9bcf768  48 89 75 d0          mov    %rsi, -0x30(%rbp)
  0x00007f59e9bcf76c  48 89 55 c8          mov    %rdx, -0x38(%rbp)
  0x00007f59e9bcf770  83 7d dc 0b          cmp    -0x24(%rbp), $0x0b
  0x00007f59e9bcf774  74 2f                jz     $0x00007f59e9bcf7a5
  0x00007f59e9bcf776  83 7d dc 0b          cmp    -0x24(%rbp), $0x0b
  0x00007f59e9bcf77a  7f 77                jnle   $0x00007f59e9bcf7f3
  0x00007f59e9bcf77c  83 7d dc 04          cmp    -0x24(%rbp), $0x04
  0x00007f59e9bcf780  74 60                jz     $0x00007f59e9bcf7e2
  0x00007f59e9bcf782  83 7d dc 0a          cmp    -0x24(%rbp), $0x0a
  0x00007f59e9bcf786  75 6b                jnz    $0x00007f59e9bcf7f3
  0x00007f59e9bcf788  48 8b 45 c8          mov    -0x38(%rbp), %rax
  0x00007f59e9bcf78c  48 83 c0 28          add    $0x28, %rax
  0x00007f59e9bcf790  48 89 45 f0          mov    %rax, -0x10(%rbp)
  0x00007f59e9bcf794  48 8b 45 f0          mov    -0x10(%rbp), %rax
  0x00007f59e9bcf798  48 8b 80 80 00 00 00 mov    0x80(%rax), %rax
  0x00007f59e9bcf79f  48 89 45 e8          mov    %rax, -0x18(%rbp)
  0x00007f59e9bcf7a3  eb 6d                jmp    $0x00007f59e9bcf812
  0x00007f59e9bcf812  90                   nop
  0x00007f59e9bcf813  c9                   leave
  0x00007f59e9bcf814  c3                   ret
  0x00007f59ed643140  48 c7 c0 0f 00 00 00 mov    $0x0000000f, %rax
  0x00007f59ed643147  0f 05                syscall
<marker: timestamp 13268857302643649>
<marker: tid 2558442 on core 3>
<marker: syscall xfer>
<marker: timestamp 13268857302649042>
<marker: tid 2558444 on core 1>
  0x00007f59ed5360d7  c3                   ret
  0x00007f59e9bcf82f  be 0a 00 00 00       mov    $0x0000000a, %esi
  0x00007f59e9bcf834  89 c7                mov    %eax, %edi
  0x00007f59e9bcf836  e8 c5 f8 ff ff       call   $0x00007f59e9bcf100
  0x00007f59e9bcf100  ff 25 7a 3f 00 00    jmp    <rel> 0x00007f59e9bd3080
  0x00007f59ed4a6080  b8 3e 00 00 00       mov    $0x0000003e, %eax
  0x00007f59ed4a6085  0f 05                syscall
<marker: timestamp 13268857302650069>
<marker: tid 2558442 on core 1>
  0x00007f59e9bcfa13  85 c0                test   %eax, %eax
  0x00007f59e9bcfa15  74 25                jz     $0x00007f59e9bcfa3c

[derekbruening]

I was worried about a signal causing an rseq abort -- will int pc have the abort handler instead of the original interrupted pc? But it seems this has already been dealt with by #4041:

        /* i#4041: Provide the actually-interrupted mid-rseq PC to this event. */

[derekbruening]

A final task here is to regenerate the traces in DynamoRIO/drmemtrace_samples