Re: remote dwarf info using libunwind

[Andrew Cagney <cagney at redhat dot com>]

>   
> > Is there any code available right now? If yes, we would be very happy to have a look at that first.
> >     
>
> Here's the patch I've just completed, that works on x86, and fixes a
> potential libunwind memory leak while at that.
>
> As it turns out, libunwind already has all that we need, we were just
> missing the proper way to use it.  dwarf_find_proc_info() was not it,
> since it's specifically designed to operate on the local process.
> Part of the libunwind-ptrace interface offers access to everything we
> need as far as locating unwind tables et al is concerned, while still
> using our own callbacks to interact with the process using ptrace or
> whatever.  I'm not sure why we don't just bite the bullet and use all
> of the libunwind interface (it looks like it would be much simpler and
> would get us what we want), but I figured I wouldn't remove any such
> code for now.
>   
Unfortunatly having frysk use the ptrace calls found in 
libunwind-ptrace.a would be wrong.  All ptrace calls to an attached 
process must be routed through a single thread and libunwind code won't 
be executed within that thread; and would immediatly limit frysk to 
native only.  If you think the ptrace limitation is lame then argue it 
out with the kernel developers.

Do any of the _UPT_* calls you added interact with either /proc or ptrace?

Why is the cpu specific library required?
+ ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a

Andrew