From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101778 invoked by alias); 20 Sep 2017 22:01:45 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 101764 invoked by uid 89); 20 Sep 2017 22:01:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=Hx-languages-length:1606, online, H*Ad:D*io X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Sep 2017 22:01:43 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 68547302AB2C; Thu, 21 Sep 2017 00:01:41 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 53314422D719; Thu, 21 Sep 2017 00:01:41 +0200 (CEST) Message-ID: <1505944901.16945.57.camel@klomp.org> Subject: Re: [PATCH v2] Make sure packed structs follow the gcc memory layout From: Mark Wielaard To: Ulf Hermann Cc: elfutils-devel@sourceware.org, Ulf Hermann Date: Wed, 20 Sep 2017 22:01:00 -0000 In-Reply-To: <603c23c4-05f2-4cc9-8081-1065774486c6@email.android.com> References: <603c23c4-05f2-4cc9-8081-1065774486c6@email.android.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.22.6 (3.22.6-10.el7) Mime-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2017-q3/txt/msg00121.txt.bz2 Hi, Looks like you sent this as HTML-only email, which are rejected by the mailinglist. On Mon, 2017-08-21 at 12:57 +0200, Ulf Hermann wrote: > > Wouldn't this be a general problem for=C2=A0 > > any struct that might be layed out differently but that we might > > map=C2=A0to some on-disk data structure?=C2=A0 > > We should generally not rely on the layout of non-packed structs. The > compiler can insert padding in various places. I didn't find any > places where we do, though. I don't think the compiler can do that without breaking ABI. I believe we are very careful about the in-memory/on-disk struct layout matching. I am online now and found the documentation: https://gcc.gnu.org/onlinedocs/gcc/x86-Type-Attributes.html https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-mms-bitfields > If packed is used on a structure, or if bit-fields are used, it may > be that the Microsoft ABI lays out the structure differently than the > way GCC normally does. Particularly when moving packed data between > functions compiled with GCC and the native Microsoft compiler (either > via function call or as data in a file), it may be necessary to > access either format. >=20 > This option is enabled by default for Microsoft Windows targets. OK, so it is x86-only and it only affects packed structs or if the struct contains bitfields. Otherwise the layout should be the same. So I do think your patch is correct. I don't think we ever use structs that contain bit-fields to map from disk to memory. Applied to master now. Thanks, Mark