From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 712 invoked by alias); 13 Nov 2002 15:08:31 -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 702 invoked from network); 13 Nov 2002 15:08:29 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 13 Nov 2002 15:08:29 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18Bz80-00018f-00 for ; Wed, 13 Nov 2002 09:08:28 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18Bz9C-0002Jp-00 for ; Wed, 13 Nov 2002 10:09:42 -0500 Date: Wed, 13 Nov 2002 07:08: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: <20021113150942.GA8861@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <20021111131354.N10395@cygbert.vinschen.de> <20021112212526.GA28814@nevyn.them.org> <20021113143522.T10395@cygbert.vinschen.de> <20021113143140.GA7232@nevyn.them.org> <20021113155154.V10395@cygbert.vinschen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021113155154.V10395@cygbert.vinschen.de> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-11/txt/msg00139.txt.bz2 On Wed, Nov 13, 2002 at 03:51:54PM +0100, Corinna Vinschen wrote: > On Wed, Nov 13, 2002 at 09:31:40AM -0500, Daniel Jacobowitz wrote: > > On Wed, Nov 13, 2002 at 02:35:22PM +0100, Corinna Vinschen wrote: > > > On Tue, Nov 12, 2002 at 04:25:26PM -0500, Daniel Jacobowitz wrote: > > > > Ick, 32-bit st_ino... why bother to transfer it if you say "no meaning > > > > for the target"? > > > > > > The point is mainly to have all fields available which a POSIX compliant > > > application may expect. > > > > Right; but you require that the stub convert to host format anyway, so > > In case of the stat structure it's always gdb which creates/sends the > structure. The struct is filled by gdb on behalf of the target OS. > I'm not aware of a system call which takes a stat struct as input parameter. Right. Sorry, I meant "you require the stub to convert _from_ host format" - isn't that correct? So if you are explicitly defining the st_ino field to have a useless value, I don't see why you're sending it over the wire. This is a nit; it's not important. > > it seems odd to send the unused members over the wire. I guess they > > might be used someday. > > So you'd change st_ino to 64 bit? It offends my sense of elegance but I don't see a reason to bother - not when you've already got a stub using this. Any application that relies on a property of st_ino probably wants to have a real filesystem anyway, right? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer