Printable View
After some days of unsuccessful research I have another
question about GCC 3.3.5.
Is there an option to globally enforce a specific struct
alignment and padding?
IBM VAC has /Sp4, OpenWatcom /zp4 but I cannot find something
similar for GCC. Of course, pragma pack(4) works but this
way I'd have to touch many files.
On Fri, 26 Sep 2008 23:33:13 UTC, Heiko Nitzsche
<hn-expires-30dec08@arcor.de> wrote:
[color=blue]
> After some days of unsuccessful research I have another
> question about GCC 3.3.5.
>
> Is there an option to globally enforce a specific struct
> alignment and padding?[/color]
You can tell it to pack stuff up as much as possible; not sure about
alignment. -fpack-struct does that.
In the absence of proper documentation, the gcc man page may prove
helpful. There is a copy here:
[url]http://tinyurl.com/gccman[/url]
> You can tell it to pack stuff up as much as possible; not sure about[color=blue]
> alignment. -fpack-struct does that.[/color]
Only the base option -fpack-struct but not -fpack-struct[=N]
seems to be supported. I get an error when for -fpack-struct=4.
Fortunately GCC seems to use by default the same packing like VAC
and OpenWatcom.
Hi,
Heiko Nitzsche schrieb:[color=blue][color=green]
>> You can tell it to pack stuff up as much as possible; not sure about
>> alignment. -fpack-struct does that.[/color]
>
> Only the base option -fpack-struct but not -fpack-struct[=N]
> seems to be supported. I get an error when for -fpack-struct=4.
>
> Fortunately GCC seems to use by default the same packing like VAC
> and OpenWatcom.[/color]
tell me when I am wrong, but an application's functionality should not
depend on this setting, isn't it? Normally one has only to care about
that in I/O and communication structs. Everything else should be
optimization. Of course, all modules have to be compiled with the same
compiler.
Marcel
[A complimentary Cc of this posting was sent to
=?UTF-8?B?TWFyY2VsIE3DvGxsZXI=?=
<news.5.maazl@spamgourmet.com>], who wrote in article <48e0f7de$0$6577$9b4e6d93@newsspool4.arcor-online.net>:[color=blue]
> tell me when I am wrong, but an application's functionality should not
> depend on this setting, isn't it? Normally one has only to care about
> that in I/O and communication structs. Everything else should be
> optimization. Of course, all modules have to be compiled with the same
> compiler.[/color]
A requirement which is not very easy to satisfy when you can't
recompile the kernel... ;-)
Ilya
[color=blue][color=green]
>> not sure about alignment. -fpack-struct does that.[/color][/color]
[color=blue]
> tell me when I am wrong, but an application's functionality should
> not depend on this setting, isn't it?[/color]
It's checkable (if (sizeof(struct)!=header_byte_count) ...;), but I
don't really understand why sizeof() never should matter. You may
e.g. allocate far more memory than available or required, and I'm not
sure how to solve the checkable mismatch above.
---
> tell me when I am wrong, but an application's functionality should not[color=blue]
> depend on this setting, isn't it? Normally one has only to care about
> that in I/O and communication structs. Everything else should be[/color]
In general you're right. Though there are exceptions.
[color=blue]
> optimization. Of course, all modules have to be compiled with the same
> compiler.[/color]
Exactly. This is Linux/Unix thinking as the compiler is provided by the
system. Thus the program/lib must be compiled especially for this system.
That's where the mess with for instance graphics drivers (e.g. ATI) comes
from. For each Linux distribution and each kernel revision a different
one is needed. Just because there is no stable ABI.
We don't want this on OS/2, even 15 years old programs still run on a
recent eCS which is a dream for a Linux/Unix system.
You should not go this way if you want long standing binary compatible
interfaces for a shared library. A move from one compiler to another one
for just a few modules might cause serious interoperability issues that
are hard to find. Also for 3rd party extension a stable ABI is needed.
I need this for binary compatibility of a DLL interface (you know
GBM.DLL :) ). I think I found meanwhile all potentially problematic
areas and covered them via #pragma pack().
BTW, also in GPI there are some APIs that require correct padding.
One example is BITMAPINFO2 for GpiDrawBits. As long as you use the Toolkit
headers, this is covered by them via #pragma pack() but in case you can't
(like in GBM BMP codec which is portable), you have to deal with it by
yourself.
There are also other areas where it can be useful, for instance if the
default padding would waste huge amount of memory. You might lose some
performance but this might be preferable.
Marcel Müller wrote:[color=blue]
> Hi,
>
> Heiko Nitzsche schrieb:[color=green][color=darkred]
>>> You can tell it to pack stuff up as much as possible; not sure about
>>> alignment. -fpack-struct does that.[/color]
>>
>> Only the base option -fpack-struct but not -fpack-struct[=N]
>> seems to be supported. I get an error when for -fpack-struct=4.
>>
>> Fortunately GCC seems to use by default the same packing like VAC
>> and OpenWatcom.[/color]
>
> tell me when I am wrong, but an application's functionality should not
> depend on this setting, isn't it? Normally one has only to care about
> that in I/O and communication structs. Everything else should be
> optimization. Of course, all modules have to be compiled with the same
> compiler.
>
>
> Marcel[/color]
Or with the same structure mapping.
--
prf
Heiko Nitzsche wrote:[color=blue]
>
> You should not go this way if you want long standing binary compatible
> interfaces for a shared library. A move from one compiler to another one
> for just a few modules might cause serious interoperability issues that
> are hard to find. Also for 3rd party extension a stable ABI is needed.[/color]
This is especially annoying for someone from a mainframe background,
where compatibility is usually taken for granted. OS/2 is better than
other systems because the OS developer (IBM) established some standards
and stuck to them. Other systems where more anarchic, and anything can
happen, and usually does.
--
prf
Hi,
Bob Eager schrieb:[color=blue]
> In the absence of proper documentation, the gcc man page may prove
> helpful. There is a copy here:
>
> [url]http://tinyurl.com/gccman[/url][/color]
GCC is well documented:
<http://gcc.gnu.org/onlinedocs/>
<http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/>
No need of reading man pages.
Andreas
On Tue, 30 Sep 2008 17:15:52 UTC, Andreas Kohl <ak0120@gmail.com> wrote:
[color=blue]
> Hi,
>
> Bob Eager schrieb:[color=green]
> > In the absence of proper documentation, the gcc man page may prove
> > helpful. There is a copy here:
> >
> > [url]http://tinyurl.com/gccman[/url][/color]
>
> GCC is well documented:
> <http://gcc.gnu.org/onlinedocs/>
> <http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/>
>
> No need of reading man pages.[/color]
Quite heavy reading, which is why I suggested the man pages.
> GCC is well documented:[color=blue]
> <http://gcc.gnu.org/onlinedocs/>
> <http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/>[/color]
That's where I looked. But I couldn't find the necessary
stuff there. There seems to be no support for global config.