This is the mail archive of the mailing list for the GDB 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]

Re: gdb/linux-record fixes

On 19/10/15 17:37, Pedro Alves wrote:
Hi Marcin,

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 the bug.

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 :(

Pedro Alves

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]