This is the mail archive of the
frysk@sources.redhat.com
mailing list for the frysk project.
Re: remote dwarf info using libunwind
On Sep 5, 2006, Tom Tromey <tromey@redhat.com> 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 http://www.lsd.ic.unicamp.br/~oliva/
Secretary for FSF Latin America http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}