This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA/testsuite] Cleanup pending breakpoints
- From: Keith Seitz <keiths at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: "gdb-patches at sourceware dot org ml" <gdb-patches at sourceware dot org>
- Date: Thu, 25 Apr 2013 12:41:13 -0700
- Subject: Re: [RFA/testsuite] Cleanup pending breakpoints
- References: <517716B5 dot 7050406 at redhat dot com> <5177EDAF dot 6030107 at redhat dot com>
On 04/24/2013 07:35 AM, Pedro Alves wrote:
Whenever you feel compelled to say "also" in a patch description,
consider splitting the patch in two. ;-) Updating the documentation
part could go first, and would be clearly an improvement. Extending
the interface could go afterwards, and that patch would then actually
be clearer.
I now feel compelled to submit them separately. :-)
Comments/questions?
I wonder whether "allow-pending" is the right option for the "pending" tests.
As in, "allow" != "require". I wonder whether we're losing test
coverage in those cases?
Well, yes and no. From reading through all the tests, I think the
"allow-pending" option is a bit underdefined/underterministic. Many of
the tests that use it pretty much would fail miserably if a real
breakpoint was set instead, yet "allow-pending" doesn't fail if this
happens.
IMO gdb_breakpoint should set what was requested or FAIL, e.g., if
allow-pending, ONLY pending breakpoint would produce a PASS.
Nonetheless, since we have it already, I have patches now which add a
"pending" option to gdb_breakpoint, meaning that it *must* set a pending
breakpoint. Anything else will FAIL.
Or I can mutate allow-pending to this new pending and eliminate the
ambiguity that allow-pending introduced.
What would you prefer?
Keith