GCC struct alignment and padding - OS2
This is a discussion on GCC struct alignment and padding - OS2 ; 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. ...
| | LinkBack | Tools |
|
#1
| |||
| |||
| 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. |
|
#2
| |||
| |||
| On Fri, 26 Sep 2008 23:33:13 UTC, Heiko Nitzsche > 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? 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: http://tinyurl.com/gccman |
|
#3
| |||
| |||
| > You can tell it to pack stuff up as much as possible; not sure about > alignment. -fpack-struct does that. 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. |
|
#4
| |||
| |||
| Hi, Heiko Nitzsche schrieb: >> You can tell it to pack stuff up as much as possible; not sure about >> alignment. -fpack-struct does that. > > 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. 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 |
|
#5
| |||
| |||
| [A complimentary Cc of this posting was sent to =?UTF-8?B?TWFyY2VsIE3DvGxsZXI=?= > 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. A requirement which is not very easy to satisfy when you can't recompile the kernel... ;-) Ilya |
|
#6
| |||
| |||
| >> not sure about alignment. -fpack-struct does that. > tell me when I am wrong, but an application's functionality should > not depend on this setting, isn't it? It's checkable (if (sizeof(struct)!=header_byte_count) ... , but Idon'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. --- |
|
#7
| |||
| |||
| > 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 In general you're right. Though there are exceptions. > optimization. Of course, all modules have to be compiled with the same > compiler. 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 problematicareas 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. |
|
#8
| |||
| |||
| Marcel Müller wrote: > Hi, > > Heiko Nitzsche schrieb: >>> You can tell it to pack stuff up as much as possible; not sure about >>> alignment. -fpack-struct does that. >> >> 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. > > 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 Or with the same structure mapping. -- prf |
|
#9
| |||
| |||
| Heiko Nitzsche wrote: > > 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. 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 |
|
#10
| |||
| |||
| Hi, Bob Eager schrieb: > In the absence of proper documentation, the gcc man page may prove > helpful. There is a copy here: > > http://tinyurl.com/gccman GCC is well documented: No need of reading man pages. Andreas |
|
#11
| |||
| |||
| On Tue, 30 Sep 2008 17:15:52 UTC, Andreas Kohl > Hi, > > Bob Eager schrieb: > > In the absence of proper documentation, the gcc man page may prove > > helpful. There is a copy here: > > > > http://tinyurl.com/gccman > > GCC is well documented: > > > > No need of reading man pages. Quite heavy reading, which is why I suggested the man pages. |
|
#12
| |||
| |||
| > GCC is well documented: > > That's where I looked. But I couldn't find the necessary stuff there. There seems to be no support for global config. |
« Previous Thread
|
Next Thread »
| Tools | |
| |
| | ||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Re: PATCH] firewire: add padding to some struct | unix | Kernel | 6 | 07-21-2008 07:40 AM |
| Re: PATCH] firewire: add padding to some struct | unix | Kernel | 0 | 07-18-2008 12:10 PM |
| Re: PATCH] firewire: add padding to some struct | unix | Kernel | 2 | 07-18-2008 12:10 PM |
| PATCH] firewire: add padding to some struct | unix | Kernel | 1 | 07-18-2008 10:50 AM |
| [PATCH] [RFC] shrink struct pid by removing padding on 64 bit builds | unix | Kernel | 0 | 05-11-2008 03:30 PM |
All times are GMT. The time now is 09:33 AM.

, but I
). I think I found meanwhile all potentially problematic