This is the mail archive of the gdb-patches@sourceware.org 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] |
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=19187Thanks.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? :)
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |