This is the mail archive of the gdb@sourceware.org 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]

Small remote file transfer protocol adition


Hi all,

For the remote file transfer support added recently to gdb
head, I would like to be able to optionally pass the
native error back to gdb in addition to the current
error values supported.

The reply packet is currently:

F$(retcode),$(remote_error);

where remote_error is one of the FILEIO_XXX defines defined
in src/include/gdb.h :

/* errno values */
#define FILEIO_EPERM                1
#define FILEIO_ENOENT               2
#define FILEIO_EINTR                4
#define FILEIO_EIO                  5
#define FILEIO_EBADF                9
(...)
#define FILEIO_ENOSYS              88
#define FILEIO_ENAMETOOLONG        91
#define FILEIO_EUNKNOWN          9999

These values clearly map to a subset of the possible values of
errno.  However, it doesn't map all the possible values.  On the
other hand, there is at least one supported target where
the mapping is awkward, and lossy.  Perhaps not suprisingly,
it is a Windows based target -- Windows CE.  This target has
no concept of errno in the C runtime; one must use the standard
Win32 API GetLastError/SetLastError calls to read/write error codes,
which aren't few.  It is easy to imagine other targets out there
that would want to pass more finer grained error codes back to
the user which aren't covered by the FILEIO_* constants.

To be able support this, this proposal adds an optional field
to the reply packet:

F$(retcode),$(remote_error),$(native_error);

By keeping the remote_error in place, gdb common code
can continue to be agnostic to which target it is talking
to.  In the future, if more advanced and automatic (from GDB's
perspective) file error handling is needed, GDB will always
use the remote_error field.  The native_error field's
only purpose is to report back to the user an error code that
is as accurate as possible, instead of displaying
an uninformative "unknown error".

Like the remote_error field, the native_error is formatted
as an hexadecimal number.

Please note that this field, if added, will be optional, and that
there is currently no GDB release that has remote file transfer
support.  That support was added after 6.7 was released.

Would that be OK?

--
Pedro Alves


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