[ECOS] FW: Re: How to stop gcc padding structs???

[ECOS] FW: Re: How to stop gcc padding structs???

[Gary Thomas]

This may be useful although the reply was not copied to the list.
I personally found that __attribute() only works on structures,
not at the element level.

Also, as is said here, whether it works or not may be luck (sadly).

-----FW: <200101291026.KAA13364@cam-mail2.cambridge.arm.com>-----

Date: Mon, 29 Jan 2001 10:26:40 +0000
Sender: gcc-owner@gcc.gnu.org
From: Richard Earnshaw <rearnsha@arm.com>
To: Grant Edwards <grante@visi.com>
Subject: Re: How to stop gcc padding structs???
Cc: gcc@gcc.gnu.org, Richard.Earnshaw@arm.com

> 
> I'm again fighting with gcc trying (and failing) to get it to
> stop putting padding bytes into structs.  Has anybody figured
> out how to prevent gcc from padding structs?
> 
> I ran into this problem before and gave up, finally having to
> use hand-calculated constants instead of "sizeof (struct foo)"
> in numerous places.  For example, it's impossible to define an
> Ethernet header structure that ends up having a size of 14
> bytes!

Relying on sizeof to do this is *very* non-portable.

> 
> In the following example, gcc insists that each of the "high"
> structs occupies four bytes despite my putting a "packed"
> attribute evryplace that doesn't generate a syntax warning.
> 
> $ arm-elf-gcc -v   
> Reading specs from /usr/local/lib/gcc-lib/arm-elf/2.95.2/specs
> gcc version 2.95.2 19991024 (release)
> 
> 
> typedef struct
> {
>   volatile unsigned char data __attribute__((packed));
>   volatile unsigned char _xxx __attribute__((packed));
> } high __attribute((packed));

Try:

typedef struct
{
  volatile unsigned char data;
  volatile unsigned char _xxx;
} __attribute((packed)) high;

etc.

The following also works:

struct foo
{
  volatile unsigned char data;
  volatile unsigned char _xxx;
} __attribute((packed));

typedef struct foo high;

IMO it's a long-standing bug in gcc's parser grammar that your example 
doesn't pack things as expected but doesn't generate a diagnostic either.

R.

--------------End of forwarded message-------------------------