public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Gary Thomas <gthomas@cambridge.redhat.com>
To: eCos Discussion <ecos-discuss@sourceware.cygnus.com>
Subject: [ECOS] FW: Re: How to stop gcc padding structs???
Date: Mon, 29 Jan 2001 04:34:00 -0000	[thread overview]
Message-ID: <XFMail.20010129053332.gthomas@cambridge.redhat.com> (raw)

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-------------------------

                 reply	other threads:[~2001-01-29  4:34 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=XFMail.20010129053332.gthomas@cambridge.redhat.com \
    --to=gthomas@cambridge.redhat.com \
    --cc=ecos-discuss@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).