> On 7 Mar 2018, at 17:11, Frediano Ziglio <fziglio@xxxxxxxxxx> wrote: > >> >> Interesting and creative follow up on our discussion :-) >> >>> On 7 Mar 2018, at 12:08, Frediano Ziglio <fziglio@xxxxxxxxxx> wrote: >>> >>> Assuming the packing of structure can be a portability issue. >>> Currently there are no real-world ABI that would break these structure >>> however to be safe force a 4 byte packing. >> >> Like Christophe F, I’m a bit confused by the notion of “packed but aligned. >> I’m not sure what you want to achieve with that. Maybe illustrate it with an >> example of code, and the difference that you expect between this and just >> using start-packed.h / end-packed.h? >> > > Some documentation at: > https://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Type-Attributes.html Sorry, I was not very clear. I wanted that in the commit log, not on-list ;-) > > How does it work. Misaligned access, as we should know, are slower, > no matter if there are done with one single instructions. > > If I have this structure: > > struct { > uint32_t i; > }; > > and uint32_t requires a 4 byte alignment the compiler (if not forced > otherwise) assumes that a pointer to that structure is at least 4 byte > aligned. If I add the "packed" attribute (different compilers have > different ways, is the GCC way) alone the compiler assumes the structure > and all its fields are not aligned and structure alignment are 1 byte. > So compiler potentially will use un-aligned instructions or in the > worst case read byte-byte-byte and reconstruct the value with arithmetic. > Now you can think: "but if my architecture support unaligned access > by default I have no penalty". This is wrong. If the structure is > contained in another structure it can happen that the field is not > aligned making all field not aligned and you'll have the penalty. > > Using a minimal alignment (4 in this case) make the structure > 4 bytes aligned, in that case the compiler will assume that the > uint32_t is aligned and if the structure is embedded will assure > 4 bytes alignment too. I understand what the alignment does. What I don’t understand (from the commit log or this answer) is the benefit you are expecting. If you want to avoid faults on some specific systems like ARM, maybe we could restrict alignment to those systems. If there is another reason, I was unable to guess it. > > Frediano > >> >>> >>> Signed-off-by: Frediano Ziglio <fziglio@xxxxxxxxxx> >>> --- >>> spice/Makefile.am | 2 ++ >>> spice/end-packed4.h | 38 ++++++++++++++++++++++++++++++ >>> spice/start-packed4.h | 64 >>> +++++++++++++++++++++++++++++++++++++++++++++++++++ >>> spice/stream-device.h | 4 ++++ >>> 4 files changed, 108 insertions(+) >>> create mode 100644 spice/end-packed4.h >>> create mode 100644 spice/start-packed4.h >>> >>> diff --git a/spice/Makefile.am b/spice/Makefile.am >>> index 4f9a607..1b48d30 100644 >>> --- a/spice/Makefile.am >>> +++ b/spice/Makefile.am >>> @@ -6,6 +6,7 @@ spice_protocol_include_HEADERS = \ >>> barrier.h \ >>> controller_prot.h \ >>> end-packed.h \ >>> + end-packed4.h \ >>> enums.h \ >>> error_codes.h \ >>> foreign_menu_prot.h \ >>> @@ -15,6 +16,7 @@ spice_protocol_include_HEADERS = \ >>> qxl_dev.h \ >>> qxl_windows.h \ >>> start-packed.h \ >>> + start-packed4.h \ >>> stats.h \ >>> types.h \ >>> vd_agent.h \ >>> diff --git a/spice/end-packed4.h b/spice/end-packed4.h >>> new file mode 100644 >>> index 0000000..648370b >>> --- /dev/null >>> +++ b/spice/end-packed4.h >>> @@ -0,0 +1,38 @@ >>> +/* -*- Mode: C; tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*- >>> */ >>> +/* >>> + Copyright (C) 2009-2018 Red Hat, Inc. >>> + >>> + Redistribution and use in source and binary forms, with or without >>> + modification, are permitted provided that the following conditions are >>> + met: >>> + >>> + * Redistributions of source code must retain the above copyright >>> + notice, this list of conditions and the following disclaimer. >>> + * Redistributions in binary form must reproduce the above copyright >>> + notice, this list of conditions and the following disclaimer in >>> + the documentation and/or other materials provided with the >>> + distribution. >>> + * Neither the name of the copyright holder nor the names of its >>> + contributors may be used to endorse or promote products derived >>> + from this software without specific prior written permission. >>> + >>> + THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER AND CONTRIBUTORS "AS >>> + IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED >>> + TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A >>> + PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT >>> + HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, >>> + SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT >>> + LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, >>> + DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY >>> + THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT >>> + (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE >>> + OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. >>> +*/ >>> + >>> +/* See start-packed4.h for details */ >>> + >>> +#undef SPICE_ATTR_PACKED4 >>> + >>> +#if defined(__MINGW32__) || !defined(__GNUC__) >>> +#pragma pack(pop) >>> +#endif >>> diff --git a/spice/start-packed4.h b/spice/start-packed4.h >>> new file mode 100644 >>> index 0000000..a402c64 >>> --- /dev/null >>> +++ b/spice/start-packed4.h >>> @@ -0,0 +1,64 @@ >>> +/* -*- Mode: C; tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*- >>> */ >>> +/* >>> + Copyright (C) 2009-2018 Red Hat, Inc. >>> + >>> + Redistribution and use in source and binary forms, with or without >>> + modification, are permitted provided that the following conditions are >>> + met: >>> + >>> + * Redistributions of source code must retain the above copyright >>> + notice, this list of conditions and the following disclaimer. >>> + * Redistributions in binary form must reproduce the above copyright >>> + notice, this list of conditions and the following disclaimer in >>> + the documentation and/or other materials provided with the >>> + distribution. >>> + * Neither the name of the copyright holder nor the names of its >>> + contributors may be used to endorse or promote products derived >>> + from this software without specific prior written permission. >>> + >>> + THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER AND CONTRIBUTORS "AS >>> + IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED >>> + TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A >>> + PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT >>> + HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, >>> + SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT >>> + LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, >>> + DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY >>> + THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT >>> + (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE >>> + OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. >>> +*/ >>> + >>> +/* Ideally this should all have been macros in a common headers, but >>> + * its not possible to put pragmas into header files, so we have >>> + * to use include magic. >> >> This comment is a bit outdated. With C99 and C++11, you can use _Pragma(…) in >> macros in a portable way. Do we still care about pre-C99? >> >> >> >>> + * >>> + * Use it like this: >>> + * >>> + * #include <spice/start-packed4.h> >>> + * >>> + * typedef struct SPICE_ATTR_PACKED4 { >>> + * ... >>> + * } Type; >>> + * >>> + * #include <spice/end-packed4.h> >>> + * >>> + */ >>> + >>> +#ifdef __GNUC__ >>> + >>> +#define SPICE_ATTR_PACKED4 __attribute__ ((__packed__, __aligned__(4))) >>> + >>> +#ifdef __MINGW32__ >>> +#pragma pack(push,4) >>> +#endif >> >> (also applies to start-packed.h) >> So if we compile with gcc on MinGW, we have both the packed attributes and >> the pragma pack? Is it to workaround some old MinGW bug, or is there another >> subtle reason that eludes me? >> >> The approach with two #include works, but you could also use the Symbian >> packing macro: >> >> #ifdef _MSC_VER >> // Use _Pragma instead of __pragma if you want to be more “portable" >> #define PACK(Decl) __pragma(pack(push, 1)) Decl __pragma(pack(pop)) >> #else >> #define PACK(Decl) Decl __attribute__((__packed__)) >> #endif >> >> >> >>> + >>> +#else >>> + >>> +#pragma pack(push) >>> +#pragma pack(4) >>> +#define SPICE_ATTR_PACKED4 >>> +#pragma warning(disable:4200) >>> +#pragma warning(disable:4103) >> >> Don’t you love the way Microsoft identifies messages by number, so you get no >> clue what warning these disable… >> >>> + >>> +#endif >>> diff --git a/spice/stream-device.h b/spice/stream-device.h >>> index 2e7c50e..e72a675 100644 >>> --- a/spice/stream-device.h >>> +++ b/spice/stream-device.h >>> @@ -43,6 +43,8 @@ >>> >>> #include <spice/types.h> >>> >>> +#include <spice/start-packed4.h> >>> + >>> /* >>> * Structures are all "naturally aligned" >>> * containing integers up to 64 bit. >>> @@ -210,4 +212,6 @@ typedef struct StreamMsgCursorMove { >> >> Don’t you also need to use the SPICE_ATTR_PACKED4 attribute in the structures >> themselves, or is this a follow-up patch? As is, it looks to me like it >> would pack differently on MinGW (where pragma pack would be in effect) and >> other platforms (where we’d rely on the packed attribute but don’t have it). >> >> >> >>> int32_t y; >>> } StreamMsgCursorMove; >>> >>> +#include <spice/end-packed4.h> >>> + >>> #endif /* SPICE_STREAM_DEVICE_H_ */ > _______________________________________________ > Spice-devel mailing list > Spice-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel