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