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

["Marcin Kościelnicki" <koriakin@0x04.net>]

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? :)