Re: Froggy in archer

[Thiago Jung Bauermann <bauerman at br dot ibm dot com>]

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? 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 :-) ).

> 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?
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center