Re: [PATCH v2 01/13] gdb/linux-record: Add testcases for a few syscalls.

Marcin Kościelnicki
2015-11-02T01:34:23Z

On 30/10/15 11:37, Pedro Alves wrote:
> On 10/29/2015 07:31 PM, Marcin KoÅ›cielnicki wrote:
>>>> +
>>>> +gdb_test "break marker1" \
>>>> + "Breakpoint $decimal at $hex: file .*$srcfile, line $decimal.*" \
>>>> + "set breakpoint at marker1"
>>>> +
>>>> +gdb_test "break marker2" \
>>>> + "Breakpoint $decimal at $hex: file .*$srcfile, line $decimal.*" \
>>>> + "set breakpoint at marker2"
>>>> +
>>>> +gdb_continue_to_breakpoint "marker1" ".*$srcfile:.*"
>>>> +
>>>> +gdb_continue_to_breakpoint "marker2" ".*$srcfile:.*"
>>>
>>> Most (all?) these tests run to marker1 and then immediately to
>>> marker2. Can't they just continue to marker2 directly?
>>>
>>
>> Huh. I've done that and, funnily enough, the waitpid testcase magically
>> started to pass.
>
> Eh.
>
>> For the record, I've reported the bug here:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=19187
>
> Thanks.
>
>> I guess there won't be a KFAIL after all.
>>
>
> OK.
>
> I'll take a look at the new version.
>
> Thanks,
> Pedro Alves
>

Well, this is embarassing...

Turns out gdb_continue_to_breakpoint doesn't care all that much about
the name of the breakpoint passed in as the first parameter, it just
happily continues to the next breakpoint, whatever it happens to be.

So the testcases as commited never actually make it to marker2, and they
all trivially pass (state when reaching marker1 is, after all, exactly
identical to reaching marker2 and then correctly reversing to marker1).

I should've known that stepping over fork suddenly starting to work was
too good to be true.

So... can I get that push access now and fix my mess, or do I no longer
qualify as having submitted a good patch due to the above? :)