This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Fix regression in "commands"
- From: Pedro Alves <palves at redhat dot com>
- To: Tom Tromey <tom at tromey dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 4 Dec 2017 15:49:58 +0000
- Subject: Re: [RFA] Fix regression in "commands"
- Authentication-results: sourceware.org; auth=none
- References: <20171103190747.389-1-tom@tromey.com> <3a860acf-6e64-b2ba-e3fd-560406077259@redhat.com> <87vahq5rcw.fsf@tromey.com>
On 12/01/2017 04:45 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
>
> Pedro> Hmm, for the truly "no breakpoints specified" case,
> Pedro> it seems to me that before we can reach this error, we've already
> Pedro> hit the error at the top of map_breakpoint_numbers:
> Pedro> if (args == 0 || *args == '\0')
> Pedro> error_no_arg (_("one or more breakpoint numbers"));
> Pedro> and for the case where the user specifies some argument
> Pedro> that doesn't match any breakpoint, map_breakpoint_numbers
> Pedro> already printed one of:
> Pedro> warning (_("bad breakpoint number at or near '%s'"), p);
> Pedro> printf_unfiltered (_("No breakpoint number %d.\n"), num);
> Pedro> when the "No breakpoints specified." error is reached.
>
> I think the problem is that if the error call is removed from
> commands_command_1, then a failure here won't throw at all, because
> map_breakpoint_number_range just prints a message (either with warning
> or printf_unfiltered -- not sure why the discrepancy), and doesn't
> throw.
>
> But, this would mean that an script erroneously using "commands" would
> not be interrupted, which seems like maybe a bad result. Though, as you
> point out, "delete" doesn't do this, so maybe it is ok?
I think it's OK in the principle that "delete", "disable", etc.
which seem like used-more-frequently commands, don't do this.
I think that if we want to error out, then we should do that
to all the commands that take command lists/ranges, and then
maybe do it directly in map_breakpoint_number_range, perhaps.
But I'd start with making "commands" not-error like the
others.
>
> Making map_breakpoint_number_range throw would mean that the case where
> you have breakpoint 2 and do "commands 1-3" would now fail -- although
> that's worked with a warning since ranges were added.
Right, doesn't seem very friently to make those error out.
Thanks,
Pedro Alves