Re: gdb/linux-record fixes

Pedro Alves
2015-10-29T11:30:31Z

On 10/22/2015 02:34 PM, Marcin KoÅ›cielnicki wrote:
> On 20/10/15 13:15, Marcin KoÅ›cielnicki wrote:
>> On 20/10/15 13:07, Pedro Alves wrote:
>>> On 10/19/2015 06:17 PM, Marcin KoÅ›cielnicki wrote:
>>>
>>>> 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.
>>>
>>> Can I convince you to add that to the patch (and likewise to others that
>>> might not be overly hard)?
>>
>> I'll do that, if I'm not overcome by dejaGNU... I have no idea how that
>> stuff works at the moment.
>>
>>> BTW, you'll also need to include ChangeLog entries. Please check here:
>>>
>>> https://sourceware.org/gdb/wiki/ContributionChecklist
>>
>> OK, will do.
>>
>
> Here comes v2:

Many thanks for this.

>
> - ChangeLog entries added
> - I've split the last patch in two (termios and x32)
> - test cases are included that exercise #2 (getresuid), #5 (readmsg), #6
> (time, waitpid, pipe), #8 (fstatat), #12 (readv); testing the rest would
> be rather contrived
>
> Unfortunately, my waitpid test appears to trigger another bug - going
> over a fork with a breakpoint active while recording causes an error:
>
> record-full.c:1716: internal-error: record_full_remove_breakpoint:
> removing unknown breakpoint

Indeed, I ran your tests and I see that too.

> I'll try to debug this problem this weekend. Should I remove the
> waitpid test from this patchset for now, or mark it as an expected-fail
> somehow?

You can mark it known failure with setup_kfail (kfail == known gdb failure).
You'll just need to file a bug in bugzilla in order to have a PR number to
attach to the kfail.

Thanks,
Pedro Alves