This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: full dwarf backtracing kernel to user


On Mon, 2011-07-11 at 13:35 +0200, Mark Wielaard wrote:
> I have been cleaning up the dwarf unwinder a bit, and after some small
> fixes (all in git trunk now) it is now finally possible to unwind fully
> from kernel space right into user space. This provides better user
> backtraces when a probe point triggered in kernel space. Up till now,
> when we wanted a user backtrace when the probe point was in kernel space
> we took the set of registers saved by the kernel and erased all others
> because they might have been changed by the kernel (and to not leak
> possible private data). This often worked, but as soon as the unwinder
> needed one of the registers possibly "trashed" and not saved by the
> kernel we would be stuck. With the new setup it is now possible to get a
> full user space register set to start the user space dwarf unwinder and
> always do a full unwind. One example is setting a probe point on
> syscall.close and then doing a print_ubacktrace(). Previously (on
> x86_64) at least early on in a glibc wrapper we would get stuck because
> we needed access to an unsaved register, with "full" dwarf unwinding we
> can just continue unwinding into the user space application.
> [...]
> My thinking is that the (kernel) backtrace related functions shouldn't
> change at all (except to make sure that non-x86 arches also use the
> dwarf unwinder, that is on my list next). All ubacktrace related
> functions should check whether they are called from a user context, in
> which case we already have a full register set, otherwise it should do a
> kernel unwind, without setting/printing anything except recording the
> final register set, and do the ubacktrace using that set.

This has finally been implemented. A vacation came in between and there
was more runtime cleanup necessary than anticipated. Some lingering bugs
found and fixed. But now this final commit implements the above step:

commit eacd41d38bfec95e39f32d399ecc4e4f98eafe3d
Author: Mark Wielaard <mjw@redhat.com>
Date:   Fri Sep 23 13:34:37 2011 +0200

  stack.c (_stp_get_uregs): Recover user registers from kernel context.
    
  When possible recover full pt_regs user register set by unwinding
  using kernel context till we hit user space.

Please let me know if you have any questions about this commit or any of
the runtime changes done earlier to support this functionality.

There is one annoying bug/regression left. PR13210 "vma/vdso tracking is
broken". This makes things much less useful since now we cannot unwind
through the vdso, which is always used on i386 at least. I don't know
when this regression was introduced. But I did add a testcase for it
vma_vdso.exp, which checks a couple of ways of calling into the kernel
and making sure the we always knows the "originating" vma. Currently
this fails for the vdso vma. I am looking into this and it seems this is
only because our build-id checking is not working correctly, since the
vdso vma is detected, but then rejected.

> We should also introduce a full_backtrace function that gets/prints a full
> kernel&user backtrace in one go (which people should use instead of a
> print_backtrace(); print_ubacktrace() to save some work in the probe).
> That last one should NOT be marked unprivileged since we don't do that
> for kernel backtraces either.

I am not planning to add this anymore. Instead I'll introduce an
optimization for a [print_]backtrace() and [print_]ubacktrace() done in
the same probe.

Then I'll try and hook up some non-x86 platforms. Since all of the above
only works when the DWARF unwinder is used.

Cheers,

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]