This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [COMMIT PATCH] remote: Map invalid signal numbers to GDB_SIGNAL_UNKNOWN.
- From: Pedro Alves <palves at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 22 Oct 2013 17:53:57 +0100
- Subject: Re: [COMMIT PATCH] remote: Map invalid signal numbers to GDB_SIGNAL_UNKNOWN.
- Authentication-results: sourceware.org; auth=none
- References: <1382450923-28676-1-git-send-email-palves at redhat dot com> <87li1lgv8c dot fsf at fleche dot redhat dot com>
On 10/22/2013 04:50 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
>
> Pedro> I realized that remote.c is not validating input here. Currently, if
> Pedro> a remote stub sends in an invalid signal number (or put another way,
> Pedro> if a future stub sends a new signal an old GDB doesn't know about),
> Pedro> GDB will do out of bounds accesses in the
> Pedro> signal_pass/signal_stop/signal_program arrays. It'll probably be a
> Pedro> long while before we add another signal number (and buggy stubs should
> Pedro> just be fixed), but can't hurt to be defensive.
>
> Pedro> + if (GDB_SIGNAL_FIRST <= sig && sig < GDB_SIGNAL_LAST)
> Pedro> + event->ws.value.sig = (enum gdb_signal) sig;
> Pedro> + else
> Pedro> + event->ws.value.sig = GDB_SIGNAL_UNKNOWN;
>
> Perhaps if remote_debug, this could print a message about the change.
Yeah, I had one at first, but then I realized
with "set debug remote 1"/"set debug infrun 1" we'll see the broken
signal number in the RSP, and then see infrun stop for a
random "?" signal. All the info seemed to be there, so I then
ended up just dropping that extra bit.
--
Pedro Alves