This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

responses to remote target errors

Examining GDB's handling of responses to errors on a remote target, I
see that

    E<2 hex digits>

is always accepted as an error return; and that


appears to sometimes be accepted.  Now, how

    E<2 hex digits>

is handled depends upon whether the first hex digit is a 1 or not, if it
is a 1, then the second hex digit indicates which field the remote
target objected to.  But, if the user does not have remote debugging
turned on, they probably don't know which low level command caused the
problem never mind what was sent in that field to the remote target.

If the first hex digit is not a 1, then the error code is thrown away
and never seen by the user.  The user only knows that there was an error
and which user GDB command was the last command issued.

I would like


or some variant of it to be accepted whenever

    E<2 hex digits>

is accepted.  And for the string to be printed!

One question is whether there should be some `structure' within the
string.  Possibilities include 2 hex digits followed by a space at the

    E.<2 hex digits> <string>

or maybe:

    E.[<2 hex digits> ]<string>

I lean towards


(i.e., no hex digits -- keep it simple), but I could envision the hex
digits being used by a GUI.

Do others think that this would be a good idea?  And, if yes, what form
should it take?


David Taylor
dtaylor at emc dot com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]