Re: [libunwind] libunwind kernel vrs. userspace

[David Mosberger]

Hi Troy,

>>>>> On Thu, 19 Aug 2004 10:42:44 -0600, Troy Heber <address@hidden> said:

  Troy> The basic question is, can libunwind be use to unwind the
  Troy> kernel stacks.

Most definitely.  In fact, if you use Ski's cstack command, that's
exactly what happens: the Linux Ski uses libunwind to unwind the
kernel stack.

  Troy> I'm trying to use libunwind to unwind a physical memory kernel
  Troy> dump. To me it looks like libunwind is really intended for
  Troy> user space application unwinding, because there already exists
  Troy> a kernel unwind interface that utilizes the kernel's own
  Troy> unwind table.

That conclusion doesn't follow.  The kernel unwind API was designed
long before libunwind and in fct libunwind embodies many lessons I
learned from designing the kernel API.  The goal is to replace the
kernel API with a (trimmed down) version of libunwind in the future.
Just a small matter of finding some spare time...

  Troy> For example:

  Troy> When using the find_proc_info accessor call back, it appears
  Troy> that void *unwind_info wants to receive a pointer to the ELF
  Troy> .IA_64.unwind section.

Well, find_proc_info() needs to return the unwind info for a
particular IP.  Where that info comes from doesn't matter to
libunwind.

  Troy> I could supply the ELF .IA_64.unwind section from the vmlinux
  Troy> file, but it wouldn't contain module unwind entries from the
  Troy> unw_add_unwind_table() routine.

You need to provide the unwind info that matches the IP that is being
looked up.  If the IP falls into the range of a module, you can return
that module's unwind info.  To do this, you'd have to traverse the
kernel's list of registered unwind-tables (unw.tables).  We could
simplify this by changing the kernel to cast the module's
unwind-tables as dynamic unwind info.  This would be nice because then
find_proc_info would essentially become a no-op.  However, it would
require kernel changes.  Depending on what you're aiming for, this may
or may not be an option.

        --david