From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) by mx.groups.io with SMTP id smtpd.web10.14512.1647976004661416829 for ; Tue, 22 Mar 2022 12:06:45 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@posteo.de header.s=2017 header.b=kB0JHi60; spf=pass (domain: posteo.de, ip: 185.67.36.65, mailfrom: mhaeuser@posteo.de) Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 9293C240027 for ; Tue, 22 Mar 2022 20:06:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1647976002; bh=TbKJ2USB8vvpwoEz3sXiOSyCYOMnPXk3AqFPPHwTW+E=; h=Date:Subject:From:To:Cc:From; b=kB0JHi60B3EWofMHxef1q9WlXDfw+JPN0LhgMrixsOQcsovR+W2GiC5qdH5y1raG/ VfL9v031SH9UcFGXpkxOJddXuaIscOwipwtVdBeFZluHhkUZZwZx4/QCniROAJCkps t6VXpg9BC4jcf5IgAAcjRC0W1w2KnMLc3TRifM5i2Z7he+MkAhvjwMvrbUff14g/zv 8ugt6XNfrcJ/BFkMNRpfMIeOCMqZsCDK3TXzIZ1BYJo8bLLUgCxBW7+vs/BqJb6GeE 850JwPWGxehYZdq6UixoGFf1+azD1EjRqoBAI9c9w9tfk+yGkkpmP8A11qrORdIVSP JSpBEAJ5Xu1dQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4KNLZ83cmpz9rxB; Tue, 22 Mar 2022 20:06:40 +0100 (CET) Message-ID: <243cf085-5180-8623-7033-3cd2386faa3a@posteo.de> Date: Tue, 22 Mar 2022 19:06:39 +0000 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH V2 2/3] MdePkg/Base.h: Introduce various alignment-related macros From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= To: devel@edk2.groups.io Cc: "Kinney, Michael D" , Liming Gao , "Liu, Zhiguang" , Vitaly Cheptsov , Bret Barkelew , Leif Lindholm , Ray Ni Reply-To: devel@edk2.groups.io, mhaeuser@posteo.de References: <69c6e14c4fe944d380d38dcdb851a88f51631f86.1629057790.git.mhaeuser@posteo.de> <6b4798af-92e4-3411-1586-f9e1d922e0ab@posteo.de> <56c7bb53-a6d0-efae-bf1d-20824b6c2fa8@posteo.de> In-Reply-To: <56c7bb53-a6d0-efae-bf1d-20824b6c2fa8@posteo.de> Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Considering all my branches are badly broken because of the Uncrustify=20 changes, there have been many changes to the existing PE/COFF libraries=20 in the mean time (and more external dependencies incoming with PMR), and=20 even this non-invasive patch has been mostly ignored (thanks for the=20 review, Ray!), can I now safely assume there is no (and frankly never=20 was) any actual interest in the reworked PE/COFF library? Things are at=20 a point where I cannot update all my changes to latest master on my own,=20 and if nobody provides any active support, you may best mark all related=20 BZs as WONTFIX to reflect the roadmap. Best regards, Marvin On 23.11.21 11:12, Marvin H=C3=A4user wrote: > Ping? :) > > On 16.08.21 15:10, Marvin H=C3=A4user wrote: >> Hey Ray, >> >> On 16/08/2021 11:42, Ni, Ray wrote: >>> Marvin, >>> So lucky to have you in the edk2 project looking into these=20 >>> fundamentals! >> >> Thank you. :) >> >>> +=C2=A0 #define ALIGNOF(TYPE) OFFSET_OF (struct { CHAR8 C; TYPE A; }, A= ) >>> >>> 1. Does struct{} inside a macro conform to C standard? How is the=20 >>> compatibility with different compilers? >> >> This should work, yes. The C standard defines offsetof as such: >> >> "The macros are [...] >> >> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 offsetof(type, member-designator) >> >> which expands to an integer constant expression that has type size_t,=20 >> the value of >> which is the offset in bytes, to the structure member (designated by=20 >> member-designator), >> from the beginning of its structure (designated by type). The type=20 >> and member designator >> shall be such that given >> >> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 static type t; >> >> then the expression &(t.member-designator) evaluates to an address=20 >> constant. [...]" [1] >> >> If we plug in t: >> >> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 static struct { CHAR8 C; TYPE A; }= t; >> >> we get a valid static storage duration variable declaration that=20 >> satisfies the the last condition because: >> >> "An address constant is [...], a pointer to an lvalue designating an=20 >> object of static >> storage duration, or [...]" [2] >> >> It worked with all compilers I tinkered with at https://godbolt.org/ >> I sadly do not have access to any of the compilers where this may be=20 >> used effectively (RVCT, EBC). >> >>> +#define IS_POW2(Value)=C2=A0 ((Value) !=3D 0U && ((Value) & ((Value) -= =20 >>> 1U)) =3D=3D >>> +0U) >>> >>> 2. Good to me. I learned this trick when implementing the MtrrLib. >>> >>> +#define ALIGN_VALUE_ADDEND(Value, Alignment)=C2=A0 (((Alignment) - (Va= lue)) >>> +& ((Alignment) - 1U)) >>> >>> 3. Is any other open source project using the same macro for the=20 >>> addend? >>> This is actually a general question to all new macros. >>> I would like the macros look familiar to developers from other open=20 >>> source projects. >> >> Good question, I never really saw it. I only came up with it because=20 >> for the new PE loader, we may align the PE memory within an=20 >> underaligned buffer, and for that we need the addend. I initially=20 >> used to align up and then subtract, but I saw this could be=20 >> simplified with ALIGN_VALUE_ADDEND, which was used in ALIGN_VALUE=20 >> anyway. If you have a better name, I'll change it. >> >> Best regards, >> Marvin >> >> >> [1] ISO/IEC 9899:2011, 7.19, 3. >> >> [2] ISO/IEC 9899:2011, 6.6, 9. >> >>> >>> >>> >>> >>> >> > > > >=20 > >