This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix remote 'g' command error handling
- From: Pedro Alves <palves at redhat dot com>
- To: Andrzej Kaczmarek <andrzej dot kaczmarek at codecoup dot pl>, gdb-patches at sourceware dot org
- Date: Thu, 26 Apr 2018 23:55:00 +0100
- Subject: Re: [PATCH] Fix remote 'g' command error handling
- References: <20180426205304.610-1-andrzej.kaczmarek@codecoup.pl>
On 04/26/2018 09:53 PM, Andrzej Kaczmarek wrote:
> 'g' command returns hex-string as response so simply checking for 'E'
> to determine if it failed is not enough and can trigger spurious error
> messages. For example, invalid behaviour can be easily triggered on
> Cortex-M as follows:
>
> (gdb) set $r0 = 0xe0
> Sending packet: $P0=e0000000#72...Packet received: OK
> Packet P (set-register) is supported
> Sending packet: $g#67...Packet received: E0000000849A0020...
> Remote failure reply: E0000000849A0020...
>
> This patch fixes the problem by calling putpkt()/getpkt() directly and
> checking result with packet_check_result(). This works fine since Enn
> response has odd number of bytes while proper response has even number
> of bytes.
>
> Also, remote_send() is now not used anywhere so it can be removed.
Thanks, I've merged it with minor tweaks to the ChangeLog entry.
This is an old one -- see PR 9665 at
<https://sourceware.org/bugzilla/show_bug.cgi?id=9665>.
As mentioned in the PR, the workaround is simple -- make the stub
send back lowercase hex digits instead of uppercase. It seems
possible that others packets have the same problem, even, so
I'd suggest doing that in any case.
Thanks,
Pedro Alves