Re: [RFA]: File-I/O patch, Documentation

[Andrew Cagney <ac131313@redhat.com>]

> 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