Dave, after some digging, I also realized that some syscalls are being
handled as vdso calls, such as gettimeofday. However, if they are vdso
calls, I shouldn't be able to see them using ptrace when collecting only
syscalls. The weird thing is I see a lot of gettimeofday syscalls being
made. Then I stumbled upon this article here:
https://stackoverflow.com/questions/42622427/gettimeofday-not-using-vdso,
which describes why some vdso calls on Xen VMs are actually real syscalls.

I guess the problem I'm really having is that for some syscalls being
handled as vdso calls, but due to specific virtualization platform (Xen),
are eventually handled as real syscalls, their backtrace seems to be
screwed up. Is there something special in those couple of vdso pages that
kernel sets up that libunwind will need some kind of workaround to get a
proper backtrace?

Thanks!

-
Hai

On Wed, Aug 16, 2017 at 1:07 PM, Dave Watson <davejwat...@fb.com> wrote:

> On 08/16/17 09:50 AM, hai huang wrote:
> > Actually, this problem can be reproduced with an even simpler program:
> >
> > #include <stdio.h>
> > #include <unistd.h>
> > #include <sys/time.h>
> >
> > int main() {
> >         struct timeval tv;
> >         gettimeofday(&tv, NULL);
> > }
> >
> >
> > If I compile this with `gcc -O2 -o test_O2 test.c` and run
> > `libunwind/tests/test-ptrace -s -v ./test_O2` to trace it, I will get the
> > same behavior as above with `main+0x1e` showing up twice in the
> backtrace.
> > However, the weird thing is if I replace gettimeofday() call with a
> > sleep(1) call, even compiling with the `-O2` flag, backtrace looks fine.
> > Maybe there's a strange interaction between libunwind and gettimeofday
> > syscall?
>
> So my first guess would be that it's because you are trying to ptrace
> and backtrace syscalls, but gettimeofday is no longer a syscall on
> modern linux systems, it's a vdso call:
>
> https://github.com/lattera/glibc/blob/master/sysdeps/
> unix/sysv/linux/x86_64/gettimeofday.c#L34
>
> And this is why sleep works fine - it's stil a normal syscall
>
_______________________________________________
Libunwind-devel mailing list
Libunwind-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/libunwind-devel

Reply via email to