[Bug remote/9665] valid response packet can be treated as 'ENN' error packet

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=9665

Pedro Alves <palves at redhat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |palves at redhat dot com
Summary|valid reponse packet can |valid response packet can
|be treated as 'ENN' error |be treated as 'ENN' error
|packet |packet

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=9665

--- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pedro Alves <***@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b75abf5bb636869fd893ecf98414b8b2fe0d4a12

commit b75abf5bb636869fd893ecf98414b8b2fe0d4a12
Author: Andrzej Kaczmarek <***@codecoup.pl>
Date: Thu Apr 26 23:47:25 2018 +0100

Fix remote 'g' command error handling (PR remote/9665)

'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.

gdb/Changelog:
2018-04-26 Andrzej Kaczmarek <***@codecoup.pl>

PR remote/9665
* remote.c (send_g_packet): Use putpkt/getpkt/packet_check_result
instead of remote_send.
(remote_send): Remove.