From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:4864:20::344; helo=mail-wm1-x344.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 6254521198CA8 for ; Tue, 4 Dec 2018 04:22:10 -0800 (PST) Received: by mail-wm1-x344.google.com with SMTP id f81so6672911wmd.4 for ; Tue, 04 Dec 2018 04:22:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=88LoxGEGoI9+/omqA9J9wGbueaFU0Ck+J2c4+ajV2BI=; b=cWK+MOi5oXMpCSnjQgYFM8QZPmlxNF9tYn9EnBsGyKDXyLBOQXNR5n94o9sXKfTJds lKmoCeSkPYXdKW3PTSTU8hh5ZNBTgP7S81W+5CZ0qQxU37wcZu/avbKzdsertIp/jdf0 b4H+AtOLNDxer/GtJx6e5cvWr6lDM+5zrdHww= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=88LoxGEGoI9+/omqA9J9wGbueaFU0Ck+J2c4+ajV2BI=; b=YAnS1qQ8b54HcR0URqJNEDTAhwDyvNMhjbD1MsXYHtjOxzKbahbJ278TQ4wCjaUyjn M83bNXh/KBIKxxsGlO4X8Vz9WYhrqNP9HAfoB4Z/QR6dPUYzD4a2IeuUBJgaNhaNcO3k TJe2sq6RC5rtL+c8tnmUK12HtdI5rZZ/6CQqXeaaxvPcVVLx3511Y9EBGDjHvTtW3I0V RZpnYDNIuH79q13kPon/tNACHdawsQSkeWO99JOBOdwemAYYF35E5TFt7JQDSlQZBIP4 5+qA79BJes2ZKAGuyHuc0H+T7Hr+XK9q9KkoYahUbcb3nF1AYw2zzqB+fPMCb0LWKdrF /Yiw== X-Gm-Message-State: AA+aEWaN3YadCpAJ26aZO3zX/s3CUrAz4pGNy0iwUv/FvnH7HoLkKyf4 JOYVTJbaf5kEr72hM6pbBSbvZw== X-Google-Smtp-Source: AFSGD/XMmMyMiih6d6i8C4sFdY1Zogmzh3wgT6FNNviRunOpkpCX+ZfANyaT2T/S0NsvyhyhJO5w9w== X-Received: by 2002:a1c:174f:: with SMTP id 76mr11375136wmx.116.1543926128617; Tue, 04 Dec 2018 04:22:08 -0800 (PST) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id n82sm9303851wma.42.2018.12.04.04.22.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 04 Dec 2018 04:22:07 -0800 (PST) Date: Tue, 4 Dec 2018 12:22:05 +0000 From: Leif Lindholm To: Ard Biesheuvel Cc: Chris Co , "edk2-devel@lists.01.org" , Michael D Kinney Message-ID: <20181204122205.n7myzh66uidtbdlq@bivouac.eciton.net> References: <20180921082542.35768-1-christopher.co@microsoft.com> <20180921082542.35768-10-christopher.co@microsoft.com> <20181101182020.w5qvmjbi3ukhxf2t@bivouac.eciton.net> <20181203094241.n6nbk4zvs73xf4k3@bivouac.eciton.net> <0C3C717E-BA00-46A9-844D-DE013F89E944@linaro.org> MIME-Version: 1.0 In-Reply-To: <0C3C717E-BA00-46A9-844D-DE013F89E944@linaro.org> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [PATCH edk2-platforms 09/27] Silicon/NXP: Add headers for SoC-specific i.MX packages to use X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2018 12:22:10 -0000 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Tue, Dec 04, 2018 at 10:33:23AM +0100, Ard Biesheuvel wrote: > >>>>> +#pragma pack(push, 1) > >>>> > >>>> I don't see this #pragma making any difference to the structs below, > >>>> can it be dropped? > >>> > >>> The pragma pack is defensive. Without it, we rely on the compiler > >>> packing structures by default and this may not happen on 64 bit > >>> compiles. > >> > >> I understand that is what the pragma does. My comment was because all of the > >> variables in the below structs are naturally aligned. > >> The reason I dislike its use when effectively a no-op, is that it makes it look like it > >> it isn't a no-op. > >> > >> If it covers a larger set of structs, some of which require the packed attribute I'm > >> OK with that. But I'm not a fan of adding it "just in case" without contemplating > >> the statement's (lack of) effect. > >> > >> Regards, > >> > >> Leif > >> > > > > Makes sense. I am checking to make sure this pragma wasn't > > included due to some observed compiler behavior on our end, since > > this header is also used on our ARM64 work. > > Will remove it once confirmed it is safe. > > I’d prefer to keep the pragma. It doesn’t only remove padding, it > also informs the compiler that the whole struct may appear at any > unaligned offset. > On 32 bit ARM, this means the compiler will > refrain from using load/store double or load/store multiple to > access the contents when dereferencing a pointer to such a struct, > which would result in a crash otherwise. OK, if it is a real concern that the structs themselves may appear unaligned in memory, please ignore this feedback. / Leif