Re: gdb/linux-record fixes

Marcin Kościelnicki
2015-10-19T17:18:00Z

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

>
> Thanks,
> Pedro Alves
>