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

+ Reply to Thread
Results 1 to 12 of 12

Thread: GCC struct alignment and padding

  1. GCC struct alignment and padding

    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.

  2. Re: GCC struct alignment and padding

    On Fri, 26 Sep 2008 23:33:13 UTC, Heiko Nitzsche
    wrote:

    > 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. Re: GCC struct alignment and padding

    > 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. Re: GCC struct alignment and padding

    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. Re: GCC struct alignment and padding

    [A complimentary Cc of this posting was sent to
    =?UTF-8?B?TWFyY2VsIE3DvGxsZXI=?=
    ], who wrote in article <48e0f7de$0$6577$9b4e6d93@newsspool4.arcor-online.net>:
    > 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. Re: GCC struct alignment and padding


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



    ---

  7. Re: GCC struct alignment and padding

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

  8. Re: GCC struct alignment and padding

    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. Re: GCC struct alignment and padding

    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. Re: GCC struct alignment and padding

    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. Re: GCC struct alignment and padding

    On Tue, 30 Sep 2008 17:15:52 UTC, Andreas Kohl wrote:

    > 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. Re: GCC struct alignment and padding

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

+ Reply to Thread