This is the mail archive of the
mailing list for the GDB project.
Re: gdb/linux-record fixes
- From: Marcin KoÅcielnicki <koriakin at 0x04 dot net>
- To: Pedro Alves <palves at redhat dot com>, gdb-patches at sourceware dot org
- Date: Mon, 19 Oct 2015 19:17:53 +0200
- Subject: Re: gdb/linux-record fixes
- Authentication-results: sourceware.org; auth=none
- References: <1445118081-10908-1-git-send-email-koriakin at 0x04 dot net> <56250E2D dot 7020009 at redhat dot com>
On 19/10/15 17:37, Pedro Alves wrote:
Thanks for working on this.
On 10/17/2015 10:41 PM, Marcin KoÅcielnicki wrote:
When working on process record and replay support for s390-linux,
I found quite a few problems in syscall handling. I fixed the most
important of these in this patchset. Please review.
I'm assuming none of the bugs you're fixing are presently covered by the
reverse debugging testsuite (testsuite/gdb.reverse/)? E.g,. sounds like a
test that steps forward over pipe/time/waitpid calls and then backwards
would exercise patch #06?
Yeah, they're not covered by the testsuite. Actually, there seem to be
only two tests in gdb.reverse suite that even touch syscalls:
sigall-reverse (signal, sigprocmask, exit_group) and watch-reverse
(read, write). No wonder that syscall handling is buggy...
Stepping forward and backward over pipe/time/waitpid would indeed do the
trick for patch #6. Some others are trickier to test, though - for
example to test #3 (overlong sigaction/sigset_t) you'd need to manually
invoke the actual linux syscalls, taking care to pull the right struct
definitions from kernel headers, and make sure they're located near the
end of segment bounduary (so that accessing after the end causes an
error) - the glibc wrappers will always allocate relevant structs on
stack, which almost certainly has extra bytes after the struct, hiding
BTW, I was thinking of a self-testing approach for linux-record:
- if gdb debugging is enabled, record changes on each instruction twice:
before and after execution
- memory/register contents recorded in "before" stage should match
contents previously recorded in "after" stage, if any (ie. if it's not
the first time we see a register or a memory byte). If there's a
mismatch, record missed something.
Unfortunately, that's a non-starter for multithreaded programs, or for
progams involving shared memory :(