[PATCH 0/9] using libdw as an alternative unwinder

[Mark Wielaard]

Hi,

On Fri, Mar 16, 2018 at 06:25:03PM +0300, Dmitry V. Levin wrote:
> Also I wonder why both libunwind and libdw use legacy ptrace calls?
> 
> $ ./strace -qq -esignal=none -eptrace -o'|grep PTRACE_PEEKDATA' ./strace -eexit_group cat /dev/null 
> exit_group(0)                           = ?
> +++ exited with 0 +++
> 
> $ ./strace -qq -esignal=none -eptrace -o'|grep PTRACE_PEEKDATA' ./strace -klibdw -eexit_group cat /dev/null 
> ptrace(PTRACE_PEEKDATA, 5678, 0x7ffc5ece1328, [0x7f2fb0c12ad2]) = 0
> ptrace(PTRACE_PEEKDATA, 5678, 0x7ffc5ece1348, [NULL]) = 0
> ptrace(PTRACE_PEEKDATA, 5678, 0x7ffc5ece1350, [0x4052f0]) = 0
> ptrace(PTRACE_PEEKDATA, 5678, 0x7ffc5ece1358, [0x402150]) = 0
> ptrace(PTRACE_PEEKDATA, 5678, 0x7ffc5ece1360, [0x7ffc5ece1460]) = 0
> ptrace(PTRACE_PEEKDATA, 5678, 0x7ffc5ece1368, [NULL]) = 0
> ptrace(PTRACE_PEEKDATA, 5678, 0x7ffc5ece1370, [NULL]) = 0
> ptrace(PTRACE_PEEKDATA, 5678, 0x7ffc5ece1378, [0x7f2fb0c12afa]) = 0
> ptrace(PTRACE_PEEKDATA, 5678, 0x7ffc5ece1388, [0x7f2fb0bfcc1e]) = 0
> ptrace(PTRACE_PEEKDATA, 5678, 0x7ffc5ece1428, [NULL]) = 0
> ptrace(PTRACE_PEEKDATA, 5678, 0x7ffc5ece1430, [NULL]) = 0
> ptrace(PTRACE_PEEKDATA, 5678, 0x7ffc5ece1438, [0x402150]) = 0
> ptrace(PTRACE_PEEKDATA, 5678, 0x7ffc5ece1440, [0x7ffc5ece1460]) = 0
> ptrace(PTRACE_PEEKDATA, 5678, 0x7ffc5ece1448, [0x40217a]) = 0
> exit_group(0)                           = ?
> +++ exited with 0 +++
>  > /lib64/libc-2.27.so(_exit+0x36) [0xc4bc6]
>  > /lib64/libc-2.27.so() [0x37ad1]
>  > /lib64/libc-2.27.so(exit+0x19) [0x37af9]
>  > /lib64/libc-2.27.so(__libc_start_main+0xed) [0x21c1d]
>  > /bin/cat() [0x402179]
> 
> As you can see, all these PTRACE_PEEKDATA calls are made for addresses from the same page,
> one can use a single process_vm_readv call to fetch the whole page.

That is an interesting idea. I hadn't thought about that. It would
require the library to speculate that multiple addresses will be
requested from the same page. In this case that is obviously true
because those addresses all come from the stack. But that is also
a problem, because the stack contents will change as soon as the
program/thread runs again. So it will require some design to know
when and for how long we should cache a remote process memory page.
But if we can make that work, then that should safe us a lot of
syscalls for doing the backtrace.

Thanks,

Mark