From: Pedro Alves <pedro_alves@portugalmail.pt>
To: gdb@sourceware.org
Subject: Small remote file transfer protocol adition
Date: Tue, 29 Jan 2008 04:29:00 -0000 [thread overview]
Message-ID: <479EAB6F.8040505@portugalmail.pt> (raw)
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
next reply other threads:[~2008-01-29 4:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-29 4:29 Pedro Alves [this message]
2008-01-29 13:58 ` Daniel Jacobowitz
2008-01-29 15:21 ` Pedro Alves
2008-01-29 16:43 ` Daniel Jacobowitz
2008-01-29 17:52 ` Pedro Alves
2008-01-31 14:56 ` Daniel Jacobowitz
2008-01-31 18:15 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=479EAB6F.8040505@portugalmail.pt \
--to=pedro_alves@portugalmail.pt \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox