Marcus Engene <meng...@engene.se> writes:
> Hi, > > I'd like to do instruction traces with library+function name included. > > From what I understand in_asm only shows instructions when they are being > JIT:ed. > If I call a function twice I only see the instructions once so it makes sense. > > As a workaround, I tried to do a plugin. I looked at the examples in > contrib/plugins and it seems to work nicely. I see all instructions in > userspace: > > 0000004000802100 48 89 e7 movq %rsp, %rdi > 0000004000802103 e8 08 0e 00 00 callq 0x4000802f10 > 0000004000802f10 f3 0f 1e fa endbr64 > 0000004000802f14 55 pushq %rbp > 0000004000802f15 48 89 e5 movq %rsp, %rbp > 0000004000802f18 41 57 pushq %r15 This looks like you could expand/tweak the existing execlog to get what you want rather than writing a whole new plugin. > However, for it to be super useful, I'd also like to see what library or > source file each instruction lives, and what function we're in. > > Example output from perf + intel_pt > > a.out 602812 [006] 206712.277263361: 7f8d50217084 brk+0x4 > (/usr/lib/x86_64-linux-gnu/ld-2.31.so) mov $0xc, %eax > a.out 602812 [006] 206712.277263361: 7f8d50217089 brk+0x9 > (/usr/lib/x86_64-linux-gnu/ld-2.31.so) syscall > a.out 602812 [006] 206712.277264027: 7f8d5021708b brk+0xb > (/usr/lib/x86_64-linux-gnu/ld-2.31.so) cmp $0xfffffffffffff000, %rax > a.out 602812 [006] 206712.277264027: 7f8d50217091 brk+0x11 > (/usr/lib/x86_64-linux-gnu/ld-2.31.so) jnbe 0x7f8d502170a8 > a.out 602812 [006] 206712.277264027: 7f8d50217093 brk+0x13 > (/usr/lib/x86_64-linux-gnu/ld-2.31.so) movq %rax, 0x1106e > (%rip) > > Is this doable? Do you have any advice on where to start? Totally. > > I tried to get the "symbol" in the plugin, but I only get null values. You mean using qemu_plugin_insn_symbol()? IIRC that only works on the main binary and of course needs a non-stripped binary. Basically we would need to expand the elf loader to consider libraries as well. However that will require some sort of hook to spot them getting mapped in by the guests ld.so. Maybe we could add some heuristics to the mmap syscalls to spot that? > > Kind regards, > Marcus -- Alex Bennée
