From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) by mx.groups.io with SMTP id smtpd.web10.4615.1580948239723969476 for ; Wed, 05 Feb 2020 16:17:20 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@protonmail.com header.s=default header.b=kwLSp0Lx; spf=pass (domain: protonmail.com, ip: 185.70.40.134, mailfrom: vit9696@protonmail.com) Date: Thu, 06 Feb 2020 00:17:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1580948236; bh=e6mCapnNiByryLBt6HHii54XtBSpFLD5LVte3CVIb0E=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=kwLSp0Lxr1XezVF/jjAj0leIgQqUAU+EneGlzRfUEMSTMPzNZnnaMuA+bJwFz5fBs RZFXWFvpl51kEK+PUzfy4eHAiv5ZIsKe+XZt2ku1pANXPxTMAtg8Mp5bxgENCt4IXh Xuys9MownehH0Aj1TrZdokkbBORoDSXJlxJEenbA= To: "Gao, Liming" From: "Vitaly Cheptsov" Cc: "devel@edk2.groups.io" , =?UTF-8?Q?Marvin_H=C3=A4user?= , Laszlo Ersek , "Kinney, Michael D" Reply-To: vit9696 Subject: Re: [edk2-devel] [PATCH 0/1] Use _MSC_VER to determine MSVC compiler Message-ID: <4C1625AC-3669-4ADE-BC33-DAD8DF05528F@protonmail.com> In-Reply-To: <6c48ddd40a904bed967f45a6394f2b77@intel.com> References: <20200131211705.18511-1-vit9696@protonmail.com> <76f4dee34c9c4cf4b876dcd1c6776a73@intel.com> <71ZwJ4XFqzI7MI5QFePibWms3vLacIwHqgcxeat52NYQy-iNvZ6eiEqEYlgrJaYaVNUlYZ5sRm_CuOvlkHuUUs8_sqsgGg1rMpA1flr8OIs=@protonmail.com> <6c48ddd40a904bed967f45a6394f2b77@intel.com> Feedback-ID: p9QuX-L1wMgUm6nrSvNrf8juLupNs0VSnzXGVXuYDxlEahFdWtaedWDMB9zpwGDklGt7kzs1-RBc0cqz327Gcg==:Ext:ProtonMail MIME-Version: 1.0 X-Spam-Status: No, score=-0.7 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,FREEMAIL_REPLYTO_END_DIGIT,HTML_MESSAGE shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.protonmail.ch X-Groupsio-MsgNum: 53835 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256; boundary="---------------------385a21a5b4907626114907b7d0e93a30"; charset=UTF-8 -----------------------385a21a5b4907626114907b7d0e93a30 Cc: "devel@edk2.groups.io" , =?utf-8?Q?Marvin_H=C3=A4user?= , Laszlo Ersek , "Kinney, Michael D" Content-Type: multipart/alternative; boundary="Apple-Mail=_375D3B15-F8A6-4FA3-82D9-5B89796903AC" Date: Thu, 6 Feb 2020 03:16:01 +0300 From: vit9696 In-Reply-To: <6c48ddd40a904bed967f45a6394f2b77@intel.com> Message-Id: <4C1625AC-3669-4ADE-BC33-DAD8DF05528F@protonmail.com> Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) References: <20200131211705.18511-1-vit9696@protonmail.com> <76f4dee34c9c4cf4b876dcd1c6776a73@intel.com> <71ZwJ4XFqzI7MI5QFePibWms3vLacIwHqgcxeat52NYQy-iNvZ6eiEqEYlgrJaYaVNUlYZ5sRm_CuOvlkHuUUs8_sqsgGg1rMpA1flr8OIs=@protonmail.com> <_ENYz5wqyjjopR5YlRA_dqoSGR2GuB9cbedunTkc7FS-Zxof4rNFlcr1tcwkG2anXS3eZWYfUlhj7zO7enmbXg==@protonmail.internalid> <6c48ddd40a904bed967f45a6394f2b77@intel.com> Subject: Re: [edk2-devel] [PATCH 0/1] Use _MSC_VER to determine MSVC compiler To: "Gao, Liming" X-Mailer: Apple Mail (2.3608.60.0.2.5) --Apple-Mail=_375D3B15-F8A6-4FA3-82D9-5B89796903AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Liming, We performed the initial exploration of CLANGPDB toolchain issue on our en= d and believe we can suggest a solid solution. In addition to all the issues I mentioned in the BZ[1] there are several m= ore. 1. CLANGPDB uses -target x86_64-unknown-windows, and this basically means = different behaviour for Windows and other operating systems: - On Windows it will "attach" to installed Visual Studio and will gather t= he parameters from this installation, i.e. it will define _MSC_VER to insta= lled Visual Studio version. For example, for me it is implicitly passing -f= ms-compatibility-version=3D19.16.27026 and setting full triple to x86_64-un= known-windows-msvc19.16.27026. - On Mac and Linux it will obviously not find Visual Studio, and as a resu= lt the full triple will be x86_64-unknown-windows-msvc with _MSC_VER macro = not being defined. There basically is no control to it except -U_MSC_VER, which is ugly, as d= ifferent include directories, other defines will still happen between insta= llations. 2. EDK II relies on UINT32_MAX being a valid value for enum. This is not t= he case in the specification, as it requires enum to be either INT32 or UIN= T32: Element of a standard ANSI C enum type declaration. Type INT32.or UINT32. = ANSI C does not define the size of sign of an enum so they should never be = used in structures. ANSI C integer promotion rules make INT32 or UINT32 int= erchangeable when passed as an argument to a function. However, since I am not positive that no existing code relies on this, it = is best to preserve the current behaviour. Supporting this is valid for GNU= flavour or as a Microsoft Extension. Disabling -fms-compatibility will res= ult in a compile error for enums having 0xFFFFFFFF values, like in Base.h. All in all, we believe that CLANGPDB simply has an overlook in the -target= argument due to a misconsideration of the clang triple implementation. Nor= mally for target only 3 words are provided, but for Windows it is crucial t= o have 4, as there are different drivers with different automatics. To reso= lve the problem, we should use GNU targets i686-unknown-windows-gnu and x86= _64-unknown-windows-gnu. This is basically the only and the least hurtful s= olution, as using MSVC mode will define _MSC_EXTENSIONS, which already brea= ks many places and will require a heavy codebase refactoring, and randomly = define _MSC_VER and use Visual Studio headers and configuration, which make= s reproducible builds on different operating systems questionable if not im= possible. I will submit another patch that will replace this one later this week. In= addition to GNU targets I additionally pass -nostdlib and -nostdlibinc so = that a freestanding target is used and only builtin headers are accessible = (like stdint.h, stddef.h, and stdbool.h). This is not required but an extra= safety measure. Our initial validation of the changes found no issues with= our projects. We also performed building of most common EDK II packages li= ke CryptoPkg, MdePkg, and MdeModulePkg. While the change is fairly minor, I= will still request others to perform a brief check of their packages in ca= se they want to use CLANGPDB. For a quick test I include the diff of the pa= tch beforehand. Best wishes, Vitaly [1] https://bugzilla.tianocore.org/show_bug.cgi?id=3D2397 > 4 =D1=84=D0=B5=D0=B2=D1=80. 2020 =D0=B3., =D0=B2 09:56, Gao, Liming =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): >=20 > Vitaly: > Yes. I think we should have better solution in OpenSSL to support EDK2= usage. But, this is a long term solution. For now, I will try the solution= to remove -fms-compatibility option in CLANGPDB tool chain. > > Thanks > Liming > From: vit9696 =20 > Sent: Monday, February 3, 2020 7:29 PM > To: Gao, Liming ; devel@edk2.groups.io; Marvin H= =C3=A4user > Subject: RE: [edk2-devel] [PATCH 0/1] Use _MSC_VER to determine MSVC com= piler > > Liming, > > I believe it is reasonable to fix OpenSSL, but most likely it is faster = to address EDK II code at first. In future we should still stick to _MSC_VE= R, but for now just ensuring that any toolchain by MSVC does not define _MS= C_EXTENSIONS should work too. > > I believe that -fms-compatibility option is not needed for CLANGPDB, as = CLANGPDB is literally using clang, and that worked fine before in CLANG38 a= nd XCODE5. We may still have to update some preprocessor conditions to incl= ude __clang__ near __GNUC__ if __GNUC__ is left undefined even when we remo= ve -fms-compatibility, but that sounds fine for me. > > We will investigate that on our own and submit a new patch, but help fro= m other parties is strongly appreciated. We mostly use XCODE5 and are not w= ell aware of other platforms. > > Best wishes, > Vitaly > > On Mon, Feb 3, 2020 at 11:00, Gao, Liming > wrote: > Vitaly: > This change will cause CryptoPkg openssl build failure, because OpensslL= ib.inf undefines _MSC_VER macro to make sure openssl source code be built i= n edk2 project without using MS VS functions. >=20 > Now, I have no good solution to fix this issue. One way is to use define= d(_MSC_EXTENSIONS) && !defined(__clang__), another way is to investigate wh= ether we can remove -fms-compatibility option in CLANGPDB. >=20 > Thanks > Liming > > -----Original Message----- > > From: devel@edk2.groups.io > On Behalf Of Vitaly Cheptsov via Gr= oups.Io > > Sent: Saturday, February 1, 2020 5:17 AM > > To: devel@edk2.groups.io > > Subject: [edk2-devel] [PATCH 0/1] Use _MSC_VER to determine MSVC compi= ler > > > > Patch details are explained in https://bugzilla.tianocore.org/show_bug= .cgi?id=3D2397 . > > We request this to be merged in edk2-stable202002. > > > > Vitaly Cheptsov (1): > > MdePkg: Use _MSC_VER to determine MSVC compiler > > > > MdePkg/Include/AArch64/ProcessorBind.h | 2 +- > > MdePkg/Include/Arm/ProcessorBind.h | 8 ++++---- > > MdePkg/Include/Base.h | 10 +++++----- > > MdePkg/Include/Ia32/ProcessorBind.h | 6 +++--- > > MdePkg/Include/X64/ProcessorBind.h | 6 +++--- > > 5 files changed, 16 insertions(+), 16 deletions(-) > > > > -- > > 2.21.1 (Apple Git-122.3) > > > > > > -=3D-=3D-=3D-=3D-=3D-=3D > > Groups.io Links: You receive all messages sent to this group. > > > > View/Reply Online (#53623): https://edk2.groups.io/g/devel/message/536= 23 > > Mute This Topic: https://groups.io/mt/70882954/1759384 > > Group Owner: devel+owner@edk2.groups.io > > Unsubscribe: https://edk2.groups.io/g/devel/unsub [liming.gao@intel.com] > > -=3D-=3D-=3D-=3D-=3D-=3D >=20 Liming, We performed the initial exploration of CLANGPDB toolchain issue on our en= d and believe we can suggest a solid solution. In addition to all the issues I mentioned in the BZ[1] there are several m= ore. 1. CLANGPDB uses -target x86_64-unknown-windows, and this basically means = different behaviour for Windows and other operating systems: - On Windows it will "attach" to installed Visual Studio and will gather t= he parameters from this installation, i.e. it will define _MSC_VER to insta= lled Visual Studio version. For example, for me it is implicitly passing -f= ms-compatibility-version=3D19.16.27026 and setting full triple to x86_64-un= known-windows-msvc19.16.27026. - On Mac and Linux it will obviously not find Visual Studio, and as a resu= lt the full triple will be x86_64-unknown-windows-msvc with _MSC_VER macro = not being defined. There basically is no control to it except -U_MSC_VER, which is ugly, as d= ifferent include directories, other defines will still happen between insta= llations. 2. EDK II relies on UINT32_MAX being a valid value for enum. This is not t= he case in the specification, as it requires enum to be either INT32 or UIN= T32: Element of a standard ANSI C enum type declaration. Type INT32.or UINT32. = ANSI C does not define the size of sign of an enum so they should never be = used in structures. ANSI C integer promotion rules make INT32 or UINT32 int= erchangeable when passed as an argument to a function. However, since I am not positive that no existing code relies on this, it = is best to preserve the current behaviour. Supporting this is valid for GNU= flavour or as a Microsoft Extension. Disabling -fms-compatibility will res= ult in a compile error for enums having 0xFFFFFFFF values, like in Base.h. All in all, we believe that CLANGPDB simply has an overlook in the -target= argument due to a misconsideration of the clang triple implementation. Nor= mally for target only 3 words are provided, but for Windows it is crucial t= o have 4, as there are different drivers with different automatics. To reso= lve the problem, we should use GNU targets i686-unknown-windows-gnu and x86= _64-unknown-windows-gnu. This is basically the only and the least hurtful s= olution, as using MSVC mode will define _MSC_EXTENSIONS, which already brea= ks many places and will require a heavy codebase refactoring, and randomly = define _MSC_VER and use Visual Studio headers and configuration, which make= s reproducible builds on different operating systems questionable if not im= possible. I will submit another patch that will replace this one later this week. In= addition to GNU targets I additionally pass -nostdlib and -nostdlibinc so = that a freestanding target is used and only builtin headers are accessible = (like stdint.h, stddef.h, and stdbool.h). This is not required but an extra= safety measure. Our initial validation of the changes found no issues with= our projects. We also performed building of most common EDK II packages li= ke CryptoPkg, MdePkg, and MdeModulePkg. While the change is fairly minor, I= will still request others to perform a brief check of their packages in ca= se they want to use CLANGPDB. For a quick test I include the diff of the pa= tch beforehand. Best wishes, Vitaly [1] https://bugzilla.tianocore.org/show_bug.cgi?id=3D2397>=20 > 4 =D1=84=D0=B5=D0=B2=D1=80. 2020 =D0=B3., =D0=B2 09:56, Gao, Liming < li= ming.gao@intel.com > =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): >=20 >=20 > Vitaly: > Yes. I think we should have better solution in OpenSSL to support EDK2 > usage. But, this is a long term solution. For now, I will try the soluti= on > to remove -fms-compatibility option in CLANGPDB tool chain. >=20 > Thanks > Liming > *From:* vit9696 < vit9696@protonmail.com > > *Sent:* Monday, February 3, 2020 7:29 PM > *To:* Gao, Liming < liming.gao@intel.com >; devel@edk2.groups.io ; Marvi= n > H=C3=A4user < marvin.haeuser@outlook.com > > *Subject:* RE: [edk2-devel] [PATCH 0/1] Use _MSC_VER to determine MSVC > compiler >=20 > Liming, >=20 > I believe it is reasonable to fix OpenSSL, but most likely it is faster = to > address EDK II code at first. In future we should still stick to _MSC_VE= R, > but for now just ensuring that any toolchain by MSVC does not define > _MSC_EXTENSIONS should work too. >=20 > I believe that -fms-compatibility option is=C2=A0not needed for CLANGPDB= , as > CLANGPDB is literally using=C2=A0clang, and=C2=A0that worked fine before= in CLANG38 > and XCODE5. We may still have to update some preprocessor conditions to > include __clang__ near __GNUC__ if __GNUC__ is left undefined even when = we > remove -fms-compatibility, but that sounds fine for me. >=20 > We will=C2=A0investigate that on our own=C2=A0and submit a new patch, bu= t help from > other parties is strongly appreciated. We=C2=A0mostly use XCODE5 and are= not > well aware of other platforms. >=20 > Best wishes, > Vitaly >=20 > On Mon, Feb 3, 2020 at 11:00, Gao, Liming < liming.gao@intel.com > wrote= : >=20 >>=20 >>=20 >> Vitaly: >> This change will cause CryptoPkg openssl build failure, because >> OpensslLib.inf undefines _MSC_VER macro to make sure openssl source cod= e >> be built in edk2 project without using MS VS functions. >>=20 >> Now, I have no good solution to fix this issue. One way is to use >> defined(_MSC_EXTENSIONS) && !defined(__clang__), another way is to >> investigate whether we can remove -fms-compatibility option in CLANGPDB= . >>=20 >> Thanks >> Liming >> > -----Original Message----- >> > From: devel@edk2.groups.io < devel@edk2.groups.io > On Behalf Of Vita= ly >> Cheptsov via Groups.Io >> > Sent: Saturday, February 1, 2020 5:17 AM >> > To: devel@edk2.groups.io >> > Subject: [edk2-devel] [PATCH 0/1] Use _MSC_VER to determine MSVC >> compiler >> > >> > Patch details are explained in https://bugzilla.tianocore.org/show_bu= g.cgi?id=3D2397 >> . >> > We request this to be merged in edk2-stable202002. >> > >> > Vitaly Cheptsov (1): >> > MdePkg: Use _MSC_VER to determine MSVC compiler >> > >> > MdePkg/Include/AArch64/ProcessorBind.h | 2 +- >> > MdePkg/Include/Arm/ProcessorBind.h | 8 ++++---- >> > MdePkg/Include/Base.h | 10 +++++----- >> > MdePkg/Include/Ia32/ProcessorBind.h | 6 +++--- >> > MdePkg/Include/X64/ProcessorBind.h | 6 +++--- >> > 5 files changed, 16 insertions(+), 16 deletions(-) >> > >> > -- >> > 2.21.1 (Apple Git-122.3) >> > >> > >> > -=3D-=3D-=3D-=3D-=3D-=3D >> > Groups.io ( http://Groups.io ) Links: You receive all messages sent t= o >> this group. >> > >> > View/Reply Online (#53623): https://edk2.groups.io/g/devel/message/53= 623 >>=20 >> > Mute This Topic: https://groups.io/mt/70882954/1759384 >> > Group Owner: devel+owner@edk2.groups.io >> > Unsubscribe: https://edk2.groups.io/g/devel/unsub [ liming.gao@intel.= com >> ] >> > -=3D-=3D-=3D-=3D-=3D-=3D >>=20 >>=20 >=20 >=20 > --Apple-Mail=_375D3B15-F8A6-4FA3-82D9-5B89796903AC Content-Type: multipart/mixed; boundary="Apple-Mail=_D8A14B8B-FB1E-4890-89A9-FDA2F9055E81" --Apple-Mail=_D8A14B8B-FB1E-4890-89A9-FDA2F9055E81 Content-Type: multipart/alternative; boundary="47b6d4e638b4ebd0e53703fddd86aede5eb16c5cfd4d85c2e44246043c2c" --47b6d4e638b4ebd0e53703fddd86aede5eb16c5cfd4d85c2e44246043c2c Content-Transfer-Encoding: quoted-printable Content-Type: text/html
Liming= ,

We performed th= e initial exploration of CLANGPDB toolchain issue on our end and believe we= can suggest a solid solution.

In addition to all the issues I mentioned in the BZ[1] there = are several more.

1. CLANGPDB uses -target x86_64-unknown-windows, and this basically means = different behaviour for Windows and other operating systems:
- On Windows it will "attach" to installed Visual Studio and will ga= ther the parameters from this installation, i.e. it will define _MSC_VER to= installed Visual Studio version. For example, for me it is implicitly pass= ing -fms-compatibility-version=3D19.16.27026 and setting full triple to x86= _64-unknown-windows-msvc19.16.27026.
- On Mac and Linu= x it will obviously not find Visual Studio, and as a result the full triple= will be x86_64-unknown-windows-msvc with _MSC_VER macro not being defined.

There basically is no control to it except -U_MSC_VER, which is ugly, as d= ifferent include directories, other defines will still happen between insta= llations.

2. EDK = II relies on UINT32_MAX being a valid value for enum. This is not the case = in the specification, as it requires enum to be either INT32 or UINT32:

Element of a standar= d ANSI C enum type declaration. Type INT32.or UINT32. ANSI C does not defin= e the size of sign of an enum so they should never be used in structures. A= NSI C integer promotion rules make INT32 or UINT32 interchangeable when pas= sed as an argument to a function.

However, since I am not positive that no existing code rel= ies on this, it is best to preserve the current behaviour. Supporting this = is valid for GNU flavour or as a Microsoft Extension. Disabling -fms-compat= ibility will result in a compile error for enums having 0xFFFFFFFF values, = like in Base.h.

A= ll in all, we believe that CLANGPDB simply has an overlook in the -target a= rgument due to a misconsideration of the clang triple implementation. Norma= lly for target only 3 words are provided, but for Windows it is crucial to = have 4, as there are different drivers with different automatics. To resolv= e the problem, we should use GNU targets i686-unknown-windows-gnu and x86_6= 4-unknown-windows-gnu. This is basically the only and the least hurtfu= l solution, as using MSVC mode will define _MSC_EXTENSIONS, which already b= reaks many places and will require a heavy codebase refactoring, and randomly define _MSC_VER and use Visual Studio headers and configuration, = which makes reproducible builds on different operating systems = questionable if not impossible.

=
I will submit another patch that will replace = this one later this week. In addition to GNU targets I additionally pass -n= ostdlib and -nostdlibinc so that a freestanding target is used and only bui= ltin headers are accessible (like stdint.h, stddef.h, and stdbool.h). This = is not required but an extra safety measure. Our initial validation of the = changes found no issues with our projects. We also performed building of mo= st common EDK II packages like CryptoPkg, MdePkg, and MdeModulePkg. While t= he change is fairly minor, I will still request others to perform a brief c= heck of their packages in case they want to use CLANGPDB. For a quick test = I include the diff of the patch beforehand.

Best wishes,
Vitaly
=

[1] https://bug= zilla.tianocore.org/show_bug.cgi?id=3D2397



4 =D1=84=D0=B5=D0=B2=D1=80. 2020 =D0=B3., =D0=B2 09:56, Gao, Liming = <liming.gao@intel.com= > =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):

Vi= taly:
  Yes. I = think we should have better solution in OpenSSL to support EDK2 usage. But,= this is a long term solution. For now, I will try the solution to remove -= fms-compatibility option in CLANGPDB tool chain.
 
Thanks
Liming
From: vit9696 <= vit9696@protonmail.com= > 
<= b class=3D"">Sent: Mo= nday, February 3, 2020 7:29 PM
To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io; Marvin H= =C3=A4user <ma= rvin.haeuser@outlook.com>
Subject: RE: [edk2-devel] [PATCH 0/= 1] Use _MSC_VER to determine MSVC compiler
 
Liming,
 
I believe it is reasonable to fix = OpenSSL, but most likely it is faster to address EDK II code at first. In f= uture we should still stick to _MSC_VER, but for now just ensuring that any= toolchain by MSVC does not define _MSC_EXTENSIONS should work too.
 
= I believe that -fms-compatibility option is not needed for CLANGPDB, a= s CLANGPDB is literally using clang, and that worked fine before = in CLANG38 and XCODE5. We may still have to update some preprocessor condit= ions to include __clang__ near __GNUC__ if __GNUC__ is left undefined even = when we remove -fms-compatibility, but that sounds fine for me.
 
We will investigate that on our own and submit a new patch, bu= t help from other parties is strongly appreciated. We mostly use XCODE= 5 and are not well aware of other platforms.
 =
Best wishes,
Vita= ly
 
On Mon, Feb 3, 2020 at 11:00, Gao, Liming <= ;liming.gao@intel.com> wrote:

Vitaly:
This cha= nge will cause CryptoPkg openssl build failure, because OpensslLib.inf unde= fines _MSC_VER macro to make sure openssl source code be built in edk2 proj= ect without using MS VS functions.

Now, I have= no good solution to fix this issue. One way is to use defined(_MSC_EXTENSI= ONS) && !defined(__clang__), another way is to investigate whether = we can remove -fms-compatibility option in CLANGPDB.

Thanks
Liming
> -----Original Message= -----
> From: <= /span>devel@edk2.groups.io <devel@e= dk2.groups.io> On Behalf Of Vitaly Cheptsov via Groups.Io
> Sent: Saturday, February 1, 2020 5:17 AM
> To:=  devel@edk2.groups.io
> Subject: [edk2-devel] [P= ATCH 0/1] Use _MSC_VER to determine MSVC compiler
>
> Patch details are explained in h= ttps://bugzilla.tianocore.org/show_bug.cgi?id=3D2397.
>= ; We request this to be merged in edk2-stable202002.
>
> Vitaly Cheptsov (1):
> MdePkg: Use _MSC_VE= R to determine MSVC compiler
>
> MdePkg/I= nclude/AArch64/ProcessorBind.h | 2 +-
> MdePkg/Include/Arm= /ProcessorBind.h | 8 ++++----
> MdePkg/Include/Base.h | 10= +++++-----
> MdePkg/Include/Ia32/ProcessorBind.h | 6 +++-= --
> MdePkg/Include/X64/ProcessorBind.h | 6 +++---
> 5 files changed, 16 insertions(+), 16 deletions(-)
>
> --
> 2.21.1 (Apple Git-122.3)>
>
> -=3D-=3D-=3D-=3D-=3D= -=3D
> Groups.io Links: You receive all messages sent to this group.
>> View/Reply Online (#53623): https://= edk2.groups.io/g/devel/message/53623
> Mute This Topic= : https://groups.io/mt/70882954/1759384
>= ; Group Owner: devel+owner@edk2.groups.io
> = Unsubscribe: https://edk2.groups.io/g/devel/unsub [liming.gao@intel.com]
> -=3D-=3D-= =3D-=3D-=3D-=3D


--47b6d4e638b4ebd0e53703fddd86aede5eb16c5cfd4d85c2e44246043c2c-- --Apple-Mail=_D8A14B8B-FB1E-4890-89A9-FDA2F9055E81 Content-Disposition: attachment; filename=clangpdb.diff Content-Transfer-Encoding: quoted-printable Content-Type: application/octet-stream; x-unix-mode=0644; name="clangpdb.diff" diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.t= emplate index feee2bbf16..6bf6c5768e 100755 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -2755,11 +2755,11 @@ RELEASE_CLANG38_AARCH64_DLINK_FLAGS =3D DEF(CLANG38= _AARCH64_DLINK_FLAGS) -flto -Wl DEFINE CLANGPDB_IA32_PREFIX =3D ENV(CLANG_BIN) DEFINE CLANGPDB_X64_PREFIX =3D ENV(CLANG_BIN) =20 -DEFINE CLANGPDB_IA32_TARGET =3D -target i686-unknown-windows -DEFINE CLANGPDB_X64_TARGET =3D -target x86_64-unknown-windows +DEFINE CLANGPDB_IA32_TARGET =3D -target i686-unknown-windows-gnu +DEFINE CLANGPDB_X64_TARGET =3D -target x86_64-unknown-windows-gn= u =20 DEFINE CLANGPDB_WARNING_OVERRIDES =3D -Wno-parentheses-equality -Wno-ta= utological-compare -Wno-tautological-constant-out-of-range-compare -Wno-emp= ty-body -Wno-unused-const-variable -Wno-varargs -Wno-unknown-warning-option= -Wno-microsoft-enum-forward-reference -DEFINE CLANGPDB_ALL_CC_FLAGS =3D DEF(GCC48_ALL_CC_FLAGS) DEF(CLANG= PDB_WARNING_OVERRIDES) -fno-stack-protector -mms-bitfields -Wno-address -Wn= o-shift-negative-value -Wno-unknown-pragmas -Wno-incompatible-library-redec= laration -fno-asynchronous-unwind-tables -mno-implicit-float -ftrap-functi= on=3Dundefined_behavior_has_been_optimized_away_by_clang -funsigned-char -f= no-ms-extensions -Wno-null-dereference -fms-compatibility -mno-stack-arg-pr= obe +DEFINE CLANGPDB_ALL_CC_FLAGS =3D DEF(GCC48_ALL_CC_FLAGS) DEF(CLANG= PDB_WARNING_OVERRIDES) -fno-stack-protector -fno-asynchronous-unwind-tables= -funsigned-char -ftrap-function=3Dundefined_behavior_has_been_optimized_aw= ay_by_clang -Wno-address -Wno-shift-negative-value -Wno-unknown-pragmas -Wn= o-incompatible-library-redeclaration -Wno-null-dereference -mno-implicit-fl= oat -mms-bitfields -mno-stack-arg-probe -nostdlib -nostdlibinc =20 ########################### # CLANGPDB IA32 definitions --Apple-Mail=_D8A14B8B-FB1E-4890-89A9-FDA2F9055E81 Content-Type: multipart/alternative; boundary="3feb3662205a8eb907b78577f2337c5c7e5a468c1f47719f4c3925383248" --Apple-Mail=_D8A14B8B-FB1E-4890-89A9-FDA2F9055E81-- --Apple-Mail=_375D3B15-F8A6-4FA3-82D9-5B89796903AC-- -----------------------385a21a5b4907626114907b7d0e93a30 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsBmBAEBCAAQBQJeO1sACRBPsoxt7Hy0xQAKCRBPsoxt7Hy0xTEsB/9JXmuU ViFDEjpwn7qz/LMFs+uWozr+HcEIvBPQHKAg55XhybpL6NdB09fDOKLPMglZ kWup5Lij7DD3dXm2glENj6X0Xk7yXmVjmGJXpjLA7KSLusdz0hqATx+hL/NO fyHK3Yy9DPfbyGz7Rnz0czH8v2lHUb2sZOSaUbIDlW033qGzWX08pQp57nTN EJLLUcQb2p/+oO1mzhYonBxyVN9f3SIpqSD2QODZPMVwq9qMlZhYdzc7r6DQ HFb7NX79kUQzkKM5EoCkE20Ya0V1ce94l73Vi/jD7RcQq+9WUqkScqcCfRpo bNUVt2lycx4XVAIVTDROu+7EoufWr2YuSSQY =BRUg -----END PGP SIGNATURE----- -----------------------385a21a5b4907626114907b7d0e93a30--