From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 831A3C77B73 for ; Thu, 20 Apr 2023 07:16:52 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 56248861A4; Thu, 20 Apr 2023 09:16:50 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="cKyff6Et"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id C502C861A4; Thu, 20 Apr 2023 09:16:48 +0200 (CEST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id A13128563C for ; Thu, 20 Apr 2023 09:16:45 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=takahiro.akashi@linaro.org Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-1a69e101070so1574905ad.1 for ; Thu, 20 Apr 2023 00:16:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1681975004; x=1684567004; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=cc4os8lpr869n7FmiSS3vM80LEO5hYbGLhyEOFvvdZg=; b=cKyff6EtzIRYBcLbyXJ8coRoTJKsXGth7n5p9jZagfhDimF17/RuEwh7oZ78yNkg1r R9OlW7GoxHTmaNi4oh2nq84FTVC71LriaJAb2Eea1Pzwjgphvq6uEHexkQ0qKrYnn8On 0bguDlr6FgLsAvKv25V8fHYxa6eNSZKWXXbzUylF2Tx8gEjXZLwETt/g4yk5KJmqvGWy izQ9VaCnT0+DLtUUvC2huskX2BpapRrUBo6Wd0JMlhaIqW2KudQfXMpNEjC/8EbDM8ME QhuNAEjMzRBHBL503m2eIeN6YQk1f9RnFkWpgKRQGY+CXb9rkPwX5J7Dv57ZjIX2nZvU eM7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681975004; x=1684567004; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cc4os8lpr869n7FmiSS3vM80LEO5hYbGLhyEOFvvdZg=; b=dlF4LMn50v8mtIdO8aXt+wHk3a4LVMYChGsCTdDJMkBOEYgLikQ72VGaA4cHpglpgv xJmyX4gJaXYB3yCMKySznKFWo3sce3fUrdKr1nS9Ge1idwJtf7L4Tszwq9i57ItYX1Wy B67aC1h09UDEcdBf2B0ykF1ObMFyyt+MHKKg8yl1Hhil/GlWRGSs1RvCipPVSpuctQAN ebEZh2Z2h/y/tjHd2KFSB9ERdaN3GRC6+H1bgLN7gc+Z5rA+FE/yBifGoiJ1O4l1wJt3 Z3/FxyyZOyeB8dI+jLe/J96nSErdXXlx/oKeN+TcVq3JXztj2YsemZab/MIjitcNzror kjtA== X-Gm-Message-State: AAQBX9eAdiMF8l0une4KlT7hSPMqDLRFnYqkoB6SVu4YmWcQIE+XDyBu WuU79vkoti/6724jlrXsSdQurQ== X-Google-Smtp-Source: AKy350YshnQ1POcE89S+L/MYw+xBmbb9w1Qf9x6KLguaXxRlKdVxnkcYPkaKOJUjNX6r7sb56lPXlg== X-Received: by 2002:a17:902:c942:b0:1a7:db2f:e92d with SMTP id i2-20020a170902c94200b001a7db2fe92dmr855366pla.2.1681975003968; Thu, 20 Apr 2023 00:16:43 -0700 (PDT) Received: from laputa ([2400:4050:c3e1:100:8680:bb89:81b:e736]) by smtp.gmail.com with ESMTPSA id o5-20020a17090aac0500b0024677263e36sm570732pjq.43.2023.04.20.00.16.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Apr 2023 00:16:43 -0700 (PDT) Date: Thu, 20 Apr 2023 16:16:40 +0900 From: AKASHI Takahiro To: Ilias Apalodimas Cc: u-boot@lists.denx.de, Tom Rini , Heinrich Schuchardt , Heinrich Schuchardt Subject: Re: [PATCH 2/2] efi_loader: Fix warnings on unaligned accesses Message-ID: <20230420071640.GB38118@laputa> Mail-Followup-To: AKASHI Takahiro , Ilias Apalodimas , u-boot@lists.denx.de, Tom Rini , Heinrich Schuchardt , Heinrich Schuchardt References: <20230406193707.2238981-1-ilias.apalodimas@linaro.org> <20230406193707.2238981-2-ilias.apalodimas@linaro.org> <20230407014608.GA42603@laputa> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean On Thu, Apr 20, 2023 at 09:35:42AM +0300, Ilias Apalodimas wrote: > Akashi-san > > On Fri, 7 Apr 2023 at 10:33, Ilias Apalodimas > wrote: > > > > On Fri, 7 Apr 2023 at 04:46, AKASHI Takahiro wrote: > > > > > > Hi Ilias, > > > > > > On Thu, Apr 06, 2023 at 10:37:07PM +0300, Ilias Apalodimas wrote: > > > > Tom reports that when building with clang we see this warning: > > > > field guid within 'struct efi_hii_keyboard_layout' is less aligned than 'efi_guid_t' and is usually due to 'struct efi_hii_keyboard_layout' being packed, which can lead to unaligned accesses [-Wunaligned-access] > > > > > > > > This happens because 'struct efi_hii_keyboard_layout' is defined as > > > > packed while efi_guid_t is 32bit aligned. > > > > > > There are a couple of 'struct' definitions which are *packed* > > > and contain an 'efi_guid_t' member in efi_api.h. > > > If 'efi_hii_keyboard_layout' is the only place that causes a clang warning, > > > we need a more specific explanation to clarify the problem. > > > > I assumed that all other definitions are aligned regardless of packed, > > i.e they are defined right after a u32, u64, 2xu16 etc, but I'll have > > a closer look > > So I did look closer and my assumption was indeed correct. > IOW the warning is the only place in the struct definition where > efi_guid_t happens to be be aligned. My concern is that we use char[] in one place and efi_guid_t elsewhere. It sounds arbitrary without any clear explanation. -Takahiro Akashi > Tom would you like me to send a v2 on this? > I think what happens here is that struct efi_hii_keyboard_layout is > defined as packed, and efi_guid_t is aligned(4). > So clang is trying to tell us: I will generate safe code for unaligned > accesses, but one of the struct members requires specific alignment. > > Regards > /Ilias > > > > > > > > > However the EFI spec describes the EFI_GUID as > > > > "128-bit buffer containing a unique identifier value. > > > > Unless otherwise specified aligned on a 64-bit boundary" > > > > > > That's right, but this text in this context may sound misleading. > > > (It doesn't explain why 'efi_guid_t' is 32-bit aligned.) > > > > commit 1dd705cf9903 ("efi: use 32-bit alignment for efi_guid_t") > > explains why, but it's a bit orthogonal to this commit. In any case > > I'll include it in v2 > > > > Thanks > > /Ilias > > > > > > -Takahiro Akashi > > > > > > > > > > > So convert the efi_guid_t -> u8 b[16] here and skip the alignment > > > > requirements. > > > > > > > > Reported-by: Tom Rini > > > > Suggested-by: Heinrich Schuchardt > > > > Signed-off-by: Ilias Apalodimas > > > > --- > > > > include/efi_api.h | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/include/efi_api.h b/include/efi_api.h > > > > index 2fd0221c1c77..b84b577bd7b5 100644 > > > > --- a/include/efi_api.h > > > > +++ b/include/efi_api.h > > > > @@ -1170,7 +1170,7 @@ struct efi_key_descriptor { > > > > > > > > struct efi_hii_keyboard_layout { > > > > u16 layout_length; > > > > - efi_guid_t guid; > > > > + u8 guid[16]; > > > > u32 layout_descriptor_string_offset; > > > > u8 descriptor_count; > > > > /* struct efi_key_descriptor descriptors[]; follows here */ > > > > -- > > > > 2.39.2 > > > >