[patch] Gdbserver error codes

[patch] Gdbserver error codes

[Daniel Jacobowitz]

Thanks to Eli for making me look closer at this.  Parts of remote.c
will reject ENN; in particular, ENN will cause remote_write_bytes to return
an error but remote_read_bytes not to.  Thus the 0xffffffff gdbserver has
been printing instead of an error message for inaccessible memory regions.

Also updated some copyright dates.  Checked in.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2004-02-26  Daniel Jacobowitz  <drow@mvista.com>

	* remote-utils.c (write_enn): Use "E01" instead of "ENN" for the
	error packet.
	* server.c, target.h: Update copyright years.

Index: gdbserver/remote-utils.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/remote-utils.c,v
retrieving revision 1.17
diff -u -p -r1.17 remote-utils.c
--- gdbserver/remote-utils.c	5 Jun 2003 14:26:58 -0000	1.17
+++ gdbserver/remote-utils.c	26 Feb 2004 15:08:02 -0000
@@ -1,6 +1,6 @@
 /* Remote utility routines for the remote server for GDB.
    Copyright 1986, 1989, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001,
-   2002
+   2002, 2003, 2004
    Free Software Foundation, Inc.
 
    This file is part of GDB.
@@ -487,9 +487,10 @@ write_ok (char *buf)
 void
 write_enn (char *buf)
 {
+  /* Some day, we should define the meanings of the error codes... */
   buf[0] = 'E';
-  buf[1] = 'N';
-  buf[2] = 'N';
+  buf[1] = '0';
+  buf[2] = '1';
   buf[3] = '\0';
 }
 
Index: gdbserver/server.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/server.c,v
retrieving revision 1.17
diff -u -p -r1.17 server.c
--- gdbserver/server.c	25 Feb 2004 20:41:29 -0000	1.17
+++ gdbserver/server.c	26 Feb 2004 15:08:02 -0000
@@ -1,5 +1,5 @@
 /* Main code for remote server for GDB.
-   Copyright 1989, 1993, 1994, 1995, 1997, 1998, 1999, 2000, 2002
+   Copyright 1989, 1993, 1994, 1995, 1997, 1998, 1999, 2000, 2002, 2003, 2004
    Free Software Foundation, Inc.
 
    This file is part of GDB.
Index: gdbserver/target.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/target.h,v
retrieving revision 1.9
diff -u -p -r1.9 target.h
--- gdbserver/target.h	25 Feb 2004 20:41:29 -0000	1.9
+++ gdbserver/target.h	26 Feb 2004 15:08:02 -0000
@@ -1,5 +1,5 @@
 /* Target operations for the remote server for GDB.
-   Copyright 2002
+   Copyright 2002, 2003, 2004
    Free Software Foundation, Inc.
 
    Contributed by MontaVista Software.

Re: [patch] Gdbserver error codes

[Nathan J. Williams]

Daniel Jacobowitz <drow@false.org> writes:

> Thanks to Eli for making me look closer at this.  Parts of remote.c
> will reject ENN; in particular, ENN will cause remote_write_bytes to return
> an error but remote_read_bytes not to.  Thus the 0xffffffff gdbserver has
> been printing instead of an error message for inaccessible memory regions.

I still don't see that gdbserver will actually return an error if the
memory read fails; the target_ops read routine doesn't return an error
to the upper level, and the low transfer routines don't check the
ptrace return value and errno. I can put together my patches to
address this if there's interest.

(while I'm at it, is there anything specifying that the hex format for
returned data is lowercase hex, or is the capital-E error return the only
implicit statement of that?)

        - Nathan

Re: [patch] Gdbserver error codes

[Daniel Jacobowitz]

On Thu, Feb 26, 2004 at 12:08:08PM -0500, Nathan J. Williams wrote:
> Daniel Jacobowitz <drow@false.org> writes:
> 
> > Thanks to Eli for making me look closer at this.  Parts of remote.c
> > will reject ENN; in particular, ENN will cause remote_write_bytes to return
> > an error but remote_read_bytes not to.  Thus the 0xffffffff gdbserver has
> > been printing instead of an error message for inaccessible memory regions.
> 
> I still don't see that gdbserver will actually return an error if the
> memory read fails; the target_ops read routine doesn't return an error
> to the upper level, and the low transfer routines don't check the
> ptrace return value and errno. I can put together my patches to
> address this if there's interest.

Oops, you're right.

Of course there is interest - I'm always interested in fixes to
gdbserver.  Do you have or can you get a copyright assignment?

> (while I'm at it, is there anything specifying that the hex format for
> returned data is lowercase hex, or is the capital-E error return the only
> implicit statement of that?)

I have no idea.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch] Gdbserver error codes

[Nathan J. Williams]

Daniel Jacobowitz <drow@false.org> writes:

> Of course there is interest - I'm always interested in fixes to
> gdbserver.  Do you have or can you get a copyright assignment?

I believe Wasabi Systems has a blanket copyright assignment, so I
think I'm good. I'll get the patches together.

        - Nathan

Re: [patch] Gdbserver error codes

[Andrew Cagney]

> On Thu, Feb 26, 2004 at 12:08:08PM -0500, Nathan J. Williams wrote:
> 
>>> Daniel Jacobowitz <drow@false.org> writes:
>>> 
>>
>>>> > Thanks to Eli for making me look closer at this.  Parts of remote.c
>>>> > will reject ENN; in particular, ENN will cause remote_write_bytes to return
>>>> > an error but remote_read_bytes not to.  Thus the 0xffffffff gdbserver has
>>>> > been printing instead of an error message for inaccessible memory regions.
>>
>>> 
>>> I still don't see that gdbserver will actually return an error if the
>>> memory read fails; the target_ops read routine doesn't return an error
>>> to the upper level, and the low transfer routines don't check the
>>> ptrace return value and errno. I can put together my patches to
>>> address this if there's interest.
> 
> 
> Oops, you're right.
> 
> Of course there is interest - I'm always interested in fixes to
> gdbserver.  Do you have or can you get a copyright assignment?

Wasabi have a blanket assignment.

>>> (while I'm at it, is there anything specifying that the hex format for
>>> returned data is lowercase hex, or is the capital-E error return the only
>>> implicit statement of that?)
> 
> 
> I have no idea.

In general?  Assume its lowercase.  No, it probably isn't explicit.

Andrew