Date: Fri, 28 Jul 2000 11:21:04 +0530
Message-Id: <200007280551.LAA01406@midpec.com>
X-Authentication-Warning: midpec.com: tr set sender to tr AT eth DOT net using -f
From: Prashant TR <tr AT eth DOT net>
To: rich AT phekda DOT freeserve DOT co DOT uk
CC: djgpp-workers AT delorie DOT com
In-reply-to: <3980ADAC.5250D452@phekda.freeserve.co.uk> (message from Richard
	Dawe on Thu, 27 Jul 2000 22:46:20 +0100)
Subject: Re: Packed attribute and __dpmi_paddr
References:  <3980ADAC DOT 5250D452 AT phekda DOT freeserve DOT co DOT uk>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Yes, I think you're right. DPMI calls depend a lot on the arrangement
of the structure (especially those FWORD pointers). So yes, there
should be __attribute__ ((packed)) in all of those structures. (Of
course, this is all assuming what the docs below are saying...).

> 
> Hello.
> 
> A while ago in comp.os.msdos.djgpp I had a discussion with Eli and several
> other people (Mark, Prashant too?) about how to solve the problem of
> getting lcall to compile unchanged with various versions of binutils.
> Well, that seems to be impossible AFAICT, hence the detection of gas
> version in Makefiles.
> 
> While looking at this problem, I noticed that lcall was calling an address
> based on a __dpmi_paddr structure:
> 
>     typedef struct {
>        unsigned long  offset32;
>        unsigned short selector;
>     } __dpmi_paddr;
> 
> I was surprised to discover that this structure did not have
> __attribute__((packed)) applied to all its members. I thought all system
> structures should be packed, to ensure the correct byte ordering.
> 
> According to N843 document (an almost C99?) structures can have padding
> added anywhere, if my interpretation of the following paragraph is correct
> - from section "6.7.2.1  Structure and union specifiers" of the N843
> document:
> 
>     [#12]  Within  a structure object, the non-bit-field members
>     and the units in which bit-fields reside have addresses that
>     increase in the order in which they are declared.  A pointer
>     to a structure object, suitably  converted,  points  to  its
>     initial  member  (or  if that member is a bit-field, then to
>     the unit in which it resides), and vice versa.  There may be
>     unnamed  padding  within  a structure object, but not at its
>     beginning.
> 
> The last sentence is the one of concern to me.
> 
> For some reason I think that gcc will only pad at the end of a structure
> for alignment purposes, but it could pad in the middle, if it wanted, for
> example, to align:
> 
> struct {
>   char small_var;
>   long big_var;
> };
> 
> By inserting 3 bytes after small_var, the struct would be made
> long-aligned (NB: when long occupies 4 bytes).
> 
> Finally, to my question: should all system-related (*) structures in DJGPP
> headers be packed? I know this would make the headers look a bit ugly.
> 
> (*) e.g. calls to DOS, DPMI where byte-order will be important.
> 
> Thanks, bye,
> 
> -- 
> Richard Dawe
> [ mailto:richdawe AT bigfoot DOT com | http://www.bigfoot.com/~richdawe/ ]
> 

-- 
Prashant TR <tr AT midpec DOT com>
Web: http://www.midpec.com/