This is the mail archive of the frysk@sources.redhat.com 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


Hi,

On Wed, 2006-09-06 at 01:06 -0400, Andrew Cagney wrote:
> > 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.

We could make the PtraceThread more general so you can schedule any code
for execution on it, not just direct ptrace calls. Then you could wrap
any code that depends on ptrace calls into a Runnable and just put it on
the PtraceThread run queue.

Cheers,

Mark


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