Re: Froggy in archer

[Chris Moller <cmoller at redhat dot com>]

Thiago Jung Bauermann wrote:
> El mar, 18-11-2008 a las 13:30 -0500, Chris Moller escribiÃ:
>   
>> My plan du jour for replacing ptrace with froggy is to add a new entry
>> point in libfroggy.so, froggy_ptrace(), and replace all the ptrace()
>> calls with froggy_ptrace() calls.  The first thing froggy_ptrace() will
>> do is test for the existence of /sys/kernel/debug/froggy.  If that
>> doesn't exist, froggy_ptrace() will fall back on standard ptrace();
>> otherwise, if a froggy emulation of the given ptrace request exists, it
>> will use that emulation.  Otherwise, again, it will fall back on
>> ptrace.  Eventually, all the ptrace calls should be replaced by froggy
>> calls.
>>     
>
> By "all the ptrace calls" you mean the froggy_ptrace calls right? 

Every instance of ptrace(request, ...) in those four gdb source files
will be replaced, probably by something along the lines of
froggy_ptrace(froggy, request,...), where the first parameter, froggy,
is context information froggy needs.  (It's a pointer to a struct
returned by a froggy_open() call.)

> Your
> plan is an interesting first step, but the final goal should be (like
> Daniel mentioned before) to move away from relying on SIGTRAPs for
> receiving inferior information from the kernel, and use something else
> like a file descriptor or whichever mechanism froggy provides (except
> signals :-) ).
>   

The froggy file descriptor is used in two ways: in ioctl()s for control
(like emulating ptrace singlestep, etc.) and immediate data like reading
and writing registers.  It can also be the fd of blocking reads which
unblock when the froggy module gets asynchronous events like process
changes of state (e.g., dying) and signals.  In the froggy i/f lib,
froggy.so, that's handled in a separate thread with callbacks to a
calling client like gdb.  If the archer architecture can be made
compatible with that paradigm, I'll work on that later on.

>   
>> One of the cool things froggy can do I don't think is possible in
>> current gdb is simultaneously following both the parent and child procs
>> after a fork in code being tested.  Earlier this year I wrote a kind of
>> skeletal utracer-based debugger that could do that and I think it might
>> be worth while looking into providing the capability in archer.
>>     
>
> That will come in handy when the sourcerers bring us multi-process
> GDB. :-)
>
>   
>> Also, some
>> IBM guys are talking about sucking the breakpoint/probepoint stuff out
>> of uprobes and making it stand-alone.  They seem agreeable to having
>> froggy use the code, thereby allowing froggy to be the mechanism by
>> which archer could manage breakpoints.  (I haven't looked at all into
>> how that's done right now.)
>>     
>
> I spent a small amount of time thinking about that when I read that
> message in the utrace ml, and my initial impression is that what GDB
> would gain from this is: 1- being relieved from having to worry about
> managing shadow memory contents (i.e., the original instruction that was
> there before GDB replaced it with a trap insn), and 2- out of line
> single stepping. Both features would be implemented by utrace. GDB
> already has implementation for them, but I guess it would be better in
> terms of code maintenance to have an implementation centralized in the
> kernel.
>
> Also, I was disappointed to see that for out of line single stepping
> their proposal expects the utrace client to provide space for storing
> the relocated instruction. This is an issue with current GDB code, we
> have only one such space: the executable entrypoint. I was hoping that
> the kernel would be in a better position to come up with this kind of
> resource than the userspace client. Perhaps froggy can provide that?
>   


I'd planned on doing that in the froggy module, but haven't looked that
closely at the details yet.

-- 
Chris Moller

  I know that you believe you understand what you think I said, but
  I'm not sure you realize that what you heard is not what I meant.
      -- Robert McCloskey

Attachment: signature.asc
Description: OpenPGP digital signature