From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6659 invoked by alias); 29 Jan 2008 04:29:00 -0000 Received: (qmail 6645 invoked by uid 22791); 29 Jan 2008 04:28:57 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.169) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jan 2008 04:28:38 +0000 Received: by ug-out-1314.google.com with SMTP id h2so309077ugf.12 for ; Mon, 28 Jan 2008 20:28:35 -0800 (PST) Received: by 10.67.22.14 with SMTP id z14mr973082ugi.24.1201580915338; Mon, 28 Jan 2008 20:28:35 -0800 (PST) Received: from ?192.168.0.101? ( [85.240.245.95]) by mx.google.com with ESMTPS id j8sm8298536gvb.7.2008.01.28.20.28.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 28 Jan 2008 20:28:34 -0800 (PST) Message-ID: <479EAB6F.8040505@portugalmail.pt> Date: Tue, 29 Jan 2008 04:29:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Small remote file transfer protocol adition Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00302.txt.bz2 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