raw2trace failing with function markers: regression from memref elision

575b6d41 PR #3977 caused a regression in function marker handling with offline traces:

[drmemtrace]: Appending 8 instrs in bb 0x7fe49ed2d9e6 in mod 4 +0x809e6 = /lib/x86_64-linux-gnu/libc-2.28.so
  0x00007f1098d1b9e6 add    $0x0000000000000038 %rsp -> %rsp
  0x00007f1098d1b9ea pop    %rsp (%rsp)[8byte] -> %rbx %rsp
[drmemtrace]: Appended memref type 0 size 8 to 0x7fffc6042138
  0x00007f1098d1b9eb pop    %rsp (%rsp)[8byte] -> %rbp %rsp
[drmemtrace]: Appended memref type 0 size 8 to 0x7fffc6042140
  0x00007f1098d1b9ec pop    %rsp (%rsp)[8byte] -> %r12 %rsp
[drmemtrace]: Appended memref type 0 size 8 to 0x7fffc6042148
  0x00007f1098d1b9ee pop    %rsp (%rsp)[8byte] -> %r13 %rsp
[drmemtrace]: Appended memref type 0 size 8 to 0x7fffc6042150
  0x00007f1098d1b9f0 pop    %rsp (%rsp)[8byte] -> %r14 %rsp
[drmemtrace]: Appended memref type 0 size 8 to 0x7fffc6042158
  0x00007f1098d1b9f2 pop    %rsp (%rsp)[8byte] -> %r15 %rsp
[drmemtrace]: Appended memref type 0 size 8 to 0x7fffc6042160
  0x00007f1098d1b9f4 ret    %rsp (%rsp)[8byte] -> %rsp
[drmemtrace]: Appended memref type 0 size 8 to 0x7fffc6042168
[drmemtrace]: Appending delayed branch for thread 0
[drmemtrace]: Appending 2 instrs in bb 0x7fe49f0c78fc in mod 1 +0x5b8fc = /home/bruening/dr/git/build_x64_dbg_tests/clients/bin64/tool.drcacheoff.burst_malloc
  0x00005572392ae8fc add    $0x00000001 0xffffffe4(%rbp)[4byte] -> 0xffffffe4(%rbp)[4byte]
[drmemtrace]: Missing memref from predication, 0-iter repstr, or filter (next type is 0xc204000000000005)
[drmemtrace]: Filling in elided addr with remembered rbp: (nil)
[drmemtrace]: Appended memref type 1 size 4 to 0xffffffffffffffe4
  0x00005572392ae900 jmp    $0x00005572392ae8d4
[drmemtrace]: Appended marker type 4 value 0x5
[drmemtrace]: Appended marker type 7 value 0x20005b8fc
[drmemtrace]: Appending delayed branch for thread 0
[drmemtrace]: Worker 0 hit error Failed to process file for thread 94586: memref entry found outside of bb on trace thread 0
ERROR: Conversion failed: Failed to process file for thread 94586: memref entry found outside of bb

The problem is that the function return value (type=7) marker and its associated id (type=4) are now after the PC entry for the post-return block:

13a750 00007fffc6042100 00007f109963c768
13a760 20100008000809e6 00007fffc6042138
13a770 00007fffc6042140 00007fffc6042148
13a780 00007fffc6042150 00007fffc6042158
13a790 00007fffc6042160 00007fffc6042168
13a7a0 200400020005b8fc c204000000000005
13a7b0 c20700020005b8fc 00007fffc60421c0
13a7c0 200400020005b8d4 00007fffc60421c0

They used to always be before the PC entry.

This was masked by #3974 (closed) whose assert happens during tracing, so we never get to post-processing.

While we'd prefer the return markers to be before the post-call instruction in the final trace, we should also put in handling for markers between a PC entry and memref entries, because future markers could occur there.

I took some time to figure out the root cause here. identify_elidable_addresses() inserts labels in the analysis phase. tracer.cpp's event_app_instruction() inserts its PC entry on the first instr regardless of whether it's an app instr (uses drmgr_is_first_instr()). Yet drwrap_event_bb_insert() has to wait for the app instr b/c it looks for a post-call PC match.

I would prefer drmgr_is_first_instr() to only look at app instrs, but that could break somebody. I am proposing to add drmgr_is_first_app_instr() to solve this problem.