This is the mail archive of the mailing list for the frysk 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: remote dwarf info using libunwind

On Sep  5, 2006, Tom Tromey <> wrote:

>     opsy. ./frysk-core/frysk/bindir/fdtrace ../Closer
>     bad close() call at:
>     val = frysk.rt.StackFrame@157de0; in function:  (Unknown file at line 0)
>     val = frysk.rt.StackFrame@157db0; in function:  (Unknown file at line 0)
>     val = frysk.rt.StackFrame@157d80; in function:  (Unknown file at line 0)

> This is an improvement since stack tracing used to just crash.  And it
> is clearly doing something correctly, because that looks like a
> reasonable number of stack frames.

Yeah, but it's not quite correct.  The innermost frame is for the vdso
syscall, the second is for the glibc entry point, and the last is not
for main as one might expect, but rather for _start, which has no
debug info.

So get_proc_name() is working as expected (assuming you don't have
glibc-debuginfo, that is).  I don't see anything in libdw that will
try to get vdso debug info over ptrace or somesuch, and I see that
there's no debug info for _start.

What I don't know is why it's skipping the main() frame.  I'll get
back to it after getting some sleep.

FWIW, I experimented with libunwind-ptrace's get_proc_name before, and
that didn't quite work because it needs the pid passed to
_UPT_create() to be correct, and we don't have the target process's
pid readily availabel at that point.  The reason for this is that it
opens /proc/<pid>/maps to figure out the nwhat binaries are mapped in
or some such.

Alexandre Oliva
Secretary for FSF Latin America
Red Hat Compiler Engineer   aoliva@{,}
Free Software Evangelist  oliva@{,}

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