To resolve jumps to dynamically linked shared objects we currently trace mmap and openat syscalls to track what is in memory. Aside from the overhead of the extra tracing, the syscalls made by ELF interpreters for different architectures vary slightly which makes it harder to support more architectures. Also it seems that vaddrs for non-native binaries can't be dereferenced without adding an offset provided by QEMU so even just checking the filename passed to openat on arm32 is a hassle.
An easier alternative may be to check what's in memory by looking at /proc/$PID/maps. It turns out that QEMU (and the plugin) and the emulated process have the same pid so instead of tracing syscalls and manually tracking what's in memory we can look at proc/self/maps from the plugin when we need to resolve any jump. For more info on the format we'd need to parse look for "/proc/[pid]/maps" on this page.
To resolve jumps to dynamically linked shared objects we currently trace mmap and openat syscalls to track what is in memory. Aside from the overhead of the extra tracing, the syscalls made by ELF interpreters for different architectures vary slightly which makes it harder to support more architectures. Also it seems that vaddrs for non-native binaries can't be dereferenced without adding an offset provided by QEMU so even just checking the filename passed to openat on arm32 is a hassle.
An easier alternative may be to check what's in memory by looking at
/proc/$PID/maps. It turns out that QEMU (and the plugin) and the emulated process have the same pid so instead of tracing syscalls and manually tracking what's in memory we can look atproc/self/mapsfrom the plugin when we need to resolve any jump. For more info on the format we'd need to parse look for "/proc/[pid]/maps" on this page.