This is the mail archive of the
mailing list for the Archer project.
Re: Froggy in archer
- From: Tom Tromey <tromey at redhat dot com>
- To: Chris Moller <cmoller at redhat dot com>
- Cc: Project Archer <archer at sourceware dot org>
- Date: Tue, 18 Nov 2008 13:27:19 -0700
- Subject: Re: Froggy in archer
- References: <492309D0.firstname.lastname@example.org>
- Reply-to: Tom Tromey <tromey at redhat dot com>
Chris> Did some research on how gdb uses ptrace. All calls to ptrace
Chris> in an x86 32-bit build are from one of exactly four files,
Chris> gdb/i386-linux-nat.c, gdb/inf-ptrace.c, gdb/linux-fork.c. and
Chris> My plan du jour for replacing ptrace with froggy is to add a
Chris> new entry point in libfroggy.so, froggy_ptrace(), and replace
Chris> all the ptrace() calls with froggy_ptrace() calls.
In the short term, whatever is convenient for your hacking is fine.
In the long run, we want something we can send upstream. This may be
as simple as some configury -- anyway, keep it in mind.
Chris> Of course, all this only gets you maybe a half or a third of what
Chris> froggy/utrace can do--it omits entirely the report_* callback stuff
Chris> which can probably be used to replace signal() and waitpid()
Yeah, I think we'd like to do this. My hope is that this will make
the Python integration a bit more robust.
Once SÃrgio's syscall tracing patch goes in, that will be another area
where froggy would be an improvement, because then we could filter the
syscalls in the kernel. This patch series is upstream, pending review.
It is also on a branch in the archer repo.