Re: remote dwarf info using libunwind

[Mike Cvet <mcvet at redhat dot com>]

On Fri, 2006-09-15 at 06:48 -0300, Alexandre Oliva wrote:
> On Sep 13, 2006, Alexandre Oliva <aoliva@redhat.com> wrote:
> 
> > there's still something broken in the way compute addresses for
> > stack traces.
> 
> > The internal computations are carried out correctly, but when
> > frysk::rt::StackFrame::initialize() calls unw_get_proc_info(), it
> > often gets back a fake procedure spec because we can't find unwind
> > info for it (apparently because of the lack for dyn_list_addr or some
> > such), so it returns proc_info with a one-byte range covering only the
> > given IP, but when it calls unw_get_proc_name(), it uses a difference
> > piece of code that succeeds in locating information about the
> > procedure, and then it sets offset according to that base address, so
> > we end up adding the offset to the wrong base address and get wrong
> > info printed out.
> 
> > It still fails to print line numbers for main and for kernel vdso
> > syscalls and their callers, but other than that, it's much better than
> > before.
> 
> Here's the patch that fixes line numbers for main() and addresses
> printed in backtraces for PCs in modules that don't have unwind info.
> I wonder if I should set an upper limit on the symbol name size
> instead of keeping retrying until memory is really exhausted or so.
> Thoughts?
> 
> 
> Fixing vdso will take new code in libunwind to fetch the vdso ELF
> image from the target process memory.  It doesn't look hard, I'll take
> a stab at it in my next hacking session.
> 
> 
> Meanwhile, ok to install in the frysk tree?
> 

I tested out the new changes and everything looks better than before.
Looks good to commit, thanks!

- Mike