From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12045 invoked by alias); 28 Feb 2003 08:33:16 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12038 invoked from network); 28 Feb 2003 08:33:15 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 28 Feb 2003 08:33:15 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h1S8XEe25732 for ; Fri, 28 Feb 2003 03:33:14 -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 h1S8XDN14324; Fri, 28 Feb 2003 03:33:13 -0500 Received: from cygbert.vinschen.de (vpn50-22.rdu.redhat.com [172.16.50.22]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h1S8XCE05498; Fri, 28 Feb 2003 00:33:12 -0800 Received: (from corinna@localhost) by cygbert.vinschen.de (8.11.6/8.9.3/Linux sendmail 8.9.3) id h1S8X8N11441; Fri, 28 Feb 2003 09:33:08 +0100 Date: Fri, 28 Feb 2003 08:33:00 -0000 From: Corinna Vinschen To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA]: File-I/O patch, Documentation Message-ID: <20030228083308.GG24097@cygbert.vinschen.de> Reply-To: gdb-patches@sources.redhat.com Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <20021121100443.U24928@cygbert.vinschen.de> <3E5D4C4C.1040502@redhat.com> <20030227083701.GE20955@cygbert.vinschen.de> <3E5E9A1A.9000708@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E5E9A1A.9000708@redhat.com> User-Agent: Mutt/1.4i X-SW-Source: 2003-02/txt/msg00805.txt.bz2 On Thu, Feb 27, 2003 at 06:07:06PM -0500, Andrew Cagney wrote: > I think the only problem here is the need for two small, simple but > concrete examples: > > - the target doing a write() call > > - the user entering CNTRL-C and a demonstration of one of the edge cases Ok. > My one concern with the protocol spec is with this structure. The size > of those various types is target compiler dependent yet the > implementation assumes specific sizes. Sure. The sizes are chosen so that they are very likely big enough to match all hosts and targets for... well... at least a long time. > c99 (what ever the standard) formalized a number of explicitly sized > types (int32 et.al. I believe). I think this table should be specified > using those types. The alternative is to generalize the > sim/common/sim-types.h file and then specify the sizes using that. I don't think so. The protocol is more or less self-contained. All definitions are based on the assumption, that you'll never find a really matching combination of values as they are defined on all machines. Looking into the fileio code you'll see, that gdb has a couple of functions which transform all protocol datatypes to host datatypes and all protocol values to host values and vice versa. This is done that way to be totally independent from other sources of definition (especially machine dependent definitions). It's *expected* that the gdb plugin on the target side is doing the same. > The time unit of st_*time should be defined. Second since epoche but you're right, it should be mentioned. > The byte order of all the values should be defined. It is. Quote from the text: 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. > The reference to B.1 should be removed. Nope. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen@redhat.com