RE: remote/2560: valid reponse packet can be treated as 'ENN'error packet

RE: remote/2560: valid reponse packet can be treated as 'ENN'error packet

[Richard Stuckey]

The following reply was made to PR remote/2560; it has been noted by GNATS.

From: "Richard Stuckey" <Richard.Stuckey@arc.com>
To: "Daniel Jacobowitz" <drow@false.org>
Cc: <gdb-gnats@sources.redhat.com>
Subject: RE: remote/2560: valid reponse packet can  be treated as 'ENN'error packet
Date: Tue, 2 Dec 2008 17:22:38 -0000

 Yes, it was getting a register frame: the first hex digit for the first
 register was 'E' !
 
 Good idea about the lowercase.
 
     Thanks
 
 -----Original Message-----
 From: Daniel Jacobowitz [mailto:drow@false.org]=20
 Sent: 02 December 2008 17:19
 To: Richard Stuckey
 Cc: gdb-gnats@sources.redhat.com
 Subject: Re: remote/2560: valid reponse packet can be treated as
 'ENN'error packet
 
 On Tue, Dec 02, 2008 at 05:04:33PM -0000, richard.stuckey@arc.com wrote:
 > This test is too weak: if the response packet contains valid data
 which happens to begin with an 'E' then it will be incorrectly treated
 as an error.
 
 remote_send is only used in four cases: p/P and g/G.  If you
 encountered it in one of those, I suggest sending back lowercase
 hex rather than uppercase hex.
 
 That does not invalidate your correct report; merely a suggestion.
 
 --=20
 Daniel Jacobowitz
 CodeSourcery
 

Re: remote/2560: valid reponse packet can be treated as 'ENN' error packet

[Daniel Jacobowitz]

The following reply was made to PR remote/2560; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@false.org>
To: richard.stuckey@arc.com
Cc: gdb-gnats@sources.redhat.com
Subject: Re: remote/2560: valid reponse packet can  be treated as 'ENN'
	error packet
Date: Tue, 2 Dec 2008 12:19:13 -0500

 On Tue, Dec 02, 2008 at 05:04:33PM -0000, richard.stuckey@arc.com wrote:
 > This test is too weak: if the response packet contains valid data which happens to begin with an 'E' then it will be incorrectly treated as an error.
 
 remote_send is only used in four cases: p/P and g/G.  If you
 encountered it in one of those, I suggest sending back lowercase
 hex rather than uppercase hex.
 
 That does not invalidate your correct report; merely a suggestion.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery

remote/2560: valid reponse packet can be treated as 'ENN' error packet

[richard.stuckey]

>Number:         2560
>Category:       remote
>Synopsis:       valid reponse packet can  be treated as 'ENN' error packet
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Dec 02 17:08:01 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator:     ARC International
>Release:        insight 6.8
>Organization:
>Environment:

>Description:
In file remote.c, the function remote_send is used to send a packet to the remote target and receive a response packet back to it.  It checks whether the response packet is an 'ENN' error response with the test

  if ((*buf)[0] == 'E')
    error (_("Remote failure reply: %s"), *buf);

This test is too weak: if the response packet contains valid data which happens to begin with an 'E' then it will be incorrectly treated as an error.

The correct test is performed in the function  packet_check_result in this file:

      if (buf[0] == 'E'
          && isxdigit (buf[1]) && isxdigit (buf[2])
          && buf[3] == '\0')
        /* "Enn"  - definitly an error.  */
        return PACKET_ERROR;

In fact, this function should be used throughout this file to check all response packets; e.g. in the function remote_rcmd there is the code

      if (buf[0] == '\0')
        error (_("Target does not support this command."));
      if (buf[0] == 'O' && buf[1] != 'K')
        {
          remote_console_output (buf + 1); /* 'O' message from stub.  */
          continue;
        }
      if (strcmp (buf, "OK") == 0)
        break;
      if (strlen (buf) == 3 && buf[0] == 'E'
          && isdigit (buf[1]) && isdigit (buf[2]))
        {
          error (_("Protocol error with Rcmd"));
        }

where the tests essentially duplicate the code in packet_check_result (though strlen is a very inefficient means of checking that the 4th character in a buffer is a NUL!).
  
>How-To-Repeat:

>Fix:
Replace all checks on the response packet with calls to packet_check_result and check the result of this function call.
>Release-Note:
>Audit-Trail:
>Unformatted: