From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8944 invoked by alias); 12 Nov 2002 21:24:17 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8936 invoked from network); 12 Nov 2002 21:24:15 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 12 Nov 2002 21:24:15 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18BkOY-0000VZ-00 for ; Tue, 12 Nov 2002 17:24:34 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18BiXG-0007ch-00 for ; Tue, 12 Nov 2002 16:25:26 -0500 Date: Tue, 12 Nov 2002 13:24:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: [RFC] File-I/O, target access to host file system via gdb remote protocol enhancement Message-ID: <20021112212526.GA28814@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <20021111131354.N10395@cygbert.vinschen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021111131354.N10395@cygbert.vinschen.de> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-11/txt/msg00127.txt.bz2 On Mon, Nov 11, 2002 at 01:13:54PM +0100, Corinna Vinschen wrote: > Hi, > > this RFC tries to introduce a remote protocol enhancement, which > already has been implemented at Red Hat. The idea is to allow > the remote target (which likely has no own file system at all) > to access the host file system to store and retrieve data from > a gdb session, as if the hosts filesystem is local to the target. This is a great thing. I remember using similar functionality both for debugging and for running certain unnamed industry benchmarks... > A second part of this implementation is to map the basic stdio > streams (file descriptors 0-2) to the gdb console, to enable > the user to serve a remote target application interactively. > This should work in gdb's CLI as well as in the GUI. I like this one too; but I'm not sure that I like linking it to the remote-syscall interface. Implementation-wise, that's the most useful method for a stub like RedBoot; but for a larger system like gdbserver, it's useful to allocate the program a normal pseudo-terminal as if it had a console. And to do character rather than line I/O. As I'm sure Andrew will remind me, my suggestion doesn't fit the current remote protocol very well; it's not synchronous enough for one thing. So don't take this as an objection, and I'll come back to proper remote console support a little later. This'll be a nice starting point. > B.3 struct stat > > The buffer of type struct stat used by the target and GDB is defined > as follows: > > struct stat { > unsigned int st_dev; /* device */ > unsigned int st_ino; /* inode */ > mode_t st_mode; /* protection */ > unsigned int st_nlink; /* number of hard links */ > unsigned int st_uid; /* user ID of owner */ > unsigned int st_gid; /* group ID of owner */ > unsigned int st_rdev; /* device type (if inode device) */ > unsigned long st_size; /* total size, in bytes */ > unsigned long st_blksize; /* blocksize for filesystem I/O */ > unsigned long st_blocks; /* number of blocks allocated */ > time_t st_atime; /* time of last access */ > time_t st_mtime; /* time of last modification */ > time_t st_ctime; /* time of last change */ > }; > > The integral datatypes are conforming to the definition in B.1 so this > structure is of size 64 bytes. Ick, 32-bit st_ino... why bother to transfer it if you say "no meaning for the target"? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer