This is the mail archive of the archer@sourceware.org mailing list for the Archer 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] |
Did some research on how gdb uses ptrace. All calls to ptrace in an x86 32-bit build are from one of exactly four files, gdb/i386-linux-nat.c, gdb/inf-ptrace.c, gdb/linux-fork.c. and gdb/linux-nat.c. Among them, they make twenty-one unique ptrace request types; of that twenty-one, I've already implemented emulations for seven of them in froggy, five more are trivial deltas to the existing ones, five I haven't looked at in detail yet, but implemented something similar in froggy's predecessor utracer, and the remaining four (PTRACE_GETEVENTMSG, PTRACE_GETSIGINFO, PTRACE_GET_THREAD_AREA, and PTRACE_SETOPTIONS) I haven't looked at at all. 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. 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. Of course, all this only gets you maybe a half or a third of what froggy/utrace can do--it omits entirely the report_* callback stuff which can probably be used to replace signal() and waitpid() stuff, but I haven't looked at that at all--I'll look into that later. 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.) -- 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |