From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1229 invoked by alias); 28 Feb 2003 15:27:54 -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 1222 invoked from network); 28 Feb 2003 15:27:53 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 28 Feb 2003 15:27:53 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id EA8112A9C; Fri, 28 Feb 2003 10:30:05 -0500 (EST) Message-ID: <3E5F807D.9080506@redhat.com> Date: Fri, 28 Feb 2003 15:27:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Corinna Vinschen Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA]: File-I/O patch, Documentation References: <20021121100443.U24928@cygbert.vinschen.de> <3E5D4C4C.1040502@redhat.com> <20030227083701.GE20955@cygbert.vinschen.de> <3E5E9A1A.9000708@redhat.com> <20030228083308.GG24097@cygbert.vinschen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00810.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. Right. That is fine. >> 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 problem is that the protocol spec isn't self contained. As best as I can tell, the specification is making assumptions about the underlying characteristics of `int', `long', `time_t', et.al. types. `int', for instance, can be anything from 16 to 64 bits. For the target side for this to be correctly, the types: - the size of these types. - the byte order of these types - the underlying implementation of these types all need to be specified (I'm sure there is other stuff that someone will point out later :-). I don't see that information. >> 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. If it is defined somewhere else, then cross references are needed. >> The reference to B.1 should be removed. > > > Nope. Er, `B.1' is meaningless. If the intent was to reference another section of the document, then a texinfo cross-reference should be used. Andrew