From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14987 invoked by alias); 13 Nov 2002 15:44:30 -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 14976 invoked from network); 13 Nov 2002 15:44:30 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 13 Nov 2002 15:44:30 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id gADFLHw02554 for ; Wed, 13 Nov 2002 10:21:17 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gADFiSx22577 for ; Wed, 13 Nov 2002 10:44:28 -0500 Received: from cygbert.vinschen.de (vpn50-5.rdu.redhat.com [172.16.50.5]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id gADFiRH03466 for ; Wed, 13 Nov 2002 07:44:27 -0800 Received: (from corinna@localhost) by cygbert.vinschen.de (8.11.6/8.9.3/Linux sendmail 8.9.3) id gADFiOF21641 for gdb@sources.redhat.com; Wed, 13 Nov 2002 16:44:24 +0100 Date: Wed, 13 Nov 2002 07:44:00 -0000 From: Corinna Vinschen To: gdb@sources.redhat.com Subject: Re: [RFC] File-I/O, target access to host file system via gdb remote protocol enhancement Message-ID: <20021113164424.X10395@cygbert.vinschen.de> Reply-To: gdb@sources.redhat.com 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> <20021113150942.GA8861@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021113150942.GA8861@nevyn.them.org> User-Agent: Mutt/1.3.22.1i X-SW-Source: 2002-11/txt/msg00141.txt.bz2 On Wed, Nov 13, 2002 at 10:09:42AM -0500, Daniel Jacobowitz wrote: > On Wed, Nov 13, 2002 at 03:51:54PM +0100, Corinna Vinschen wrote: > > 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? No, it isn't. I tried to find a well defined behaviour. The target shouldn't be forced to know much about it's host. Quote from my proposal: Memory transfer: Structured data which is transferred using a memory read or write packet as e.g. a struct stat is expected to be in a protocol specific format with all numerical multibyte datatypes being big endian. [...] > > 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? Yes, probably you're right. But actually, gdb could fake everything. That's not barred by the protocol. So, in theory, we could write a gdb for a host which itself has no file system, faking a file system to its remote target. Ok, that's academically, but I like the idea :-) Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen@redhat.com