Date   

Re: [PATCH 0/3] BaseTools GCC: pass CC flags to linker

Ard Biesheuvel
 

On 3 August 2016 at 10:58, Gao, Liming <liming.gao@intel.com> wrote:
Ard:
I see Steven says it doesn't work, yet. So, I am curious what real issue is resolved by this patch?
For example, when building ArmVirtQemu for ARM, you may get warnings
(or errors when -Werror is enabled) like

lto1: warning: switch -mcpu=cortex-a15 conflicts with -march=armv7-a switch

where cortex-a15 is the target set by the platform .DSC, and armv7-a
is the default target of the compiler.
In this particular example, that does not cause any issues, since
cortex-a15 is compatible with armv7-a. However, if you are building
for ARM11, the code generation performed by the linker will generate
incompatible code unless we pass it the -mcpu=arm11 option as well.

The same applies to things like -mstrict-alignment and -mcmodel=xxx. I
suppose the same issue exists for IA32, where the -march/-mcpu options
in the platform may deviate from the compiler's default.

--
Ard.


Re: [PATCH 0/3] BaseTools GCC: pass CC flags to linker

Liming Gao
 

Ard:
I see Steven says it doesn't work, yet. So, I am curious what real issue is resolved by this patch?

Thanks
Liming

-----Original Message-----
From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
Sent: Wednesday, August 03, 2016 4:23 PM
To: Gao, Liming <liming.gao@intel.com>
Cc: Zhu, Yonghong <yonghong.zhu@intel.com>; Justen, Jordan L
<jordan.l.justen@intel.com>; edk2-devel@lists.01.org;
leif.lindholm@linaro.org; sigmaepsilon92@gmail.com
Subject: Re: [PATCH 0/3] BaseTools GCC: pass CC flags to linker

On 2 August 2016 at 16:51, Ard Biesheuvel <ard.biesheuvel@linaro.org>
wrote:
On 2 August 2016 at 16:50, Gao, Liming <liming.gao@intel.com> wrote:
Ard:
Without this change, GCC5 LTO can pass build. With it, what difference
will be in the generated image? Original way may generate the wrong image,
or new way will generate the smaller image?
This is not about code size but about correctness. Compiler switches
for code model or alignment etc may affect the way code is generated
at link time by the LTO routines.
Note that Steven mentions a similar problem in his CLANG38 series: he
needs to pass -pie to the linker (or -fpie would be sufficient, I
suspect) to prevent the linker from using the wrong code model when
generating code from the LTO bytecode.

Thanks,
Ard.


Re: [PATCH 2/4] BaseTools-Conf:Introduce CLANG38 new toolchain for x86

Shi, Steven <steven.shi@...>
 

Hello Ard,


Hello Steven,

On 3 August 2016 at 08:48, Shi, Steven <steven.shi@intel.com> wrote:
This adds support for LLVM 3.8.x in LTO mode for IA32 and X64.
CLANG38 enable LLVM Link Time Optimization (LTO) and code size
optimization flag (-Oz) by default for aggressive code size
improvement. CLANG38 X64 code is small code model + PIE.

CLANG LTO needs PIE in link flags to generate PIE code correctly,
otherwise the PIE is not really enabled. (e.g. OvmfPkgX64 will
hang in 64bits SEC at high address because of small model code
displacement overflow).
This is probably caused by the same issue I am addressing with the
series I sent out yesterday, to pass the CC flags to the DLINK
command.

The reason is that code is generated by the link pass, so it needs to
see the same -fpie -mcmodel=small options that we passed to the
compiler as wel.

Could you check whether replacing '-Wl,-pie' with -fpie does the trick
as well? As I mentioned before, creating a PIE executable at link time
is not the same as generatic position independent code at compile time
(whether it is via $(CC) or via $(DLINK)). The PIE executable will
contain a .rela section that partially overlaps with other absolute
relocations, so it is best to avoid it.
[Steven]: I just tried it. No, replacing '-Wl,-pie' with -fpie cannot works for clang38. With -fpie in link flags, the OvmfPkgX64 still hang in 64bits SEC at high address.



Some more comments below

+*_CLANG38_IA32_OBJCOPY_PATH = DEF(GCC5_IA32_PREFIX)objcopy
Why are you using the GCC5 prefix here? A clang user may not set GCC5_BIN
[Steven]: OK, I will remove the GCC5 prefix.


+*_CLANG38_IA32_ASLCC_FLAGS = -x c -Os -m32
DEF(CLANG38_IA32_TARGET) -flto

Does LTO make any sense for ACPI tables?
[Steven]: OK, I will follow GCC5 to disable the LTO for ASLCC flags.


Thanks
Steven


Re: [PATCH 0/3] BaseTools GCC: pass CC flags to linker

Ard Biesheuvel
 

On 2 August 2016 at 16:51, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
On 2 August 2016 at 16:50, Gao, Liming <liming.gao@intel.com> wrote:
Ard:
Without this change, GCC5 LTO can pass build. With it, what difference will be in the generated image? Original way may generate the wrong image, or new way will generate the smaller image?
This is not about code size but about correctness. Compiler switches
for code model or alignment etc may affect the way code is generated
at link time by the LTO routines.
Note that Steven mentions a similar problem in his CLANG38 series: he
needs to pass -pie to the linker (or -fpie would be sufficient, I
suspect) to prevent the linker from using the wrong code model when
generating code from the LTO bytecode.

Thanks,
Ard.


[PATCH 2/2] ArmVirtPkg ARM: make relocatable PrePi users build with CLANG35

Ard Biesheuvel
 

The clang developers have made a backward incompatible change to the
command line arguments, and have replaced '-mllvm -arm-use-movt=0'
with '-mno-movt'. This does not matter for most ARM platforms, and
therefore it has been removed from the default CLANG35/ARM CC flags
in patch 1c63516075b3 ("BaseTools CLANG35: drop problematic use-movt
and save-temps options"), but as it turns out, the relocatable PrePi
implementation used by ArmVirtQemuKernel and ArmVirtXen will fail to
build if it contains MOVT/MOVW pairs, due to the fact that these are
not runtime relocatable under ELF.

Since they are runtime relocatable under PE/COFF, and GenFw does the
right thing when encountering them, selectively controlling their
use is more appropriate than disabling them altogether. Therefore,
this patch adds the -mno-movt argument only for the platforms that
use the relocatable PrePi, and only for the module types that may
be pulled into its build.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
ArmVirtPkg/ArmVirtQemuKernel.dsc | 8 ++++++++
ArmVirtPkg/ArmVirtXen.dsc | 9 +++++++++
2 files changed, 17 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index 01a1d9b4613b..6c536d9bbd2d 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -45,6 +45,9 @@ [LibraryClasses.ARM]
ArmLib|ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.inf
ArmCpuLib|ArmPkg/Drivers/ArmCpuLib/ArmCortexA15Lib/ArmCortexA15Lib.inf

+[LibraryClasses.ARM.SEC]
+ ArmLib|ArmPkg/Library/ArmLib/ArmV7/ArmV7LibSec.inf
+
[LibraryClasses.common]
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf

@@ -77,6 +80,11 @@ [BuildOptions]
GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 -I$(WORKSPACE)/ArmVirtPkg/Include
*_*_AARCH64_PLATFORM_FLAGS == -I$(WORKSPACE)/ArmVirtPkg/Include

+[BuildOptions.ARM.EDKII.SEC, BuildOptions.ARM.EDKII.BASE]
+ # Avoid MOVT/MOVW instruction pairs in code that may end up in the PIE
+ # executable we build for the relocatable PrePi. They are not runtime
+ # relocatable in ELF.
+ *_CLANG35_*_CC_FLAGS = -mno-movt

################################################################################
#
diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
index 5ad1bf630bda..4ebead5ba6e6 100644
--- a/ArmVirtPkg/ArmVirtXen.dsc
+++ b/ArmVirtPkg/ArmVirtXen.dsc
@@ -44,6 +44,9 @@ [LibraryClasses.ARM]
ArmLib|ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.inf
ArmCpuLib|ArmPkg/Drivers/ArmCpuLib/ArmCortexA15Lib/ArmCortexA15Lib.inf

+[LibraryClasses.ARM.SEC]
+ ArmLib|ArmPkg/Library/ArmLib/ArmV7/ArmV7LibSec.inf
+
[LibraryClasses.common]
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf

@@ -77,6 +80,12 @@ [BuildOptions]
GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 -I$(WORKSPACE)/ArmVirtPkg/Include
GCC:*_*_AARCH64_PLATFORM_FLAGS == -I$(WORKSPACE)/ArmVirtPkg/Include

+[BuildOptions.ARM.EDKII.SEC, BuildOptions.ARM.EDKII.BASE]
+ # Avoid MOVT/MOVW instruction pairs in code that may end up in the PIE
+ # executable we build for the relocatable PrePi. They are not runtime
+ # relocatable in ELF.
+ *_CLANG35_*_CC_FLAGS = -mno-movt
+
################################################################################
#
# Pcd Section - list of all EDK II PCD Entries defined by this Platform
--
2.7.4


[PATCH 1/2] EmbeddedPkg: make PrePiMemoryAllocationLib a SEC type library

Ard Biesheuvel
 

This library is only used by the various PrePi implementations, all of
which are of type SEC. So make this library SEC as well. This may affect
the build options used by the platform.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
EmbeddedPkg/Library/PrePiMemoryAllocationLib/PrePiMemoryAllocationLib.inf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmbeddedPkg/Library/PrePiMemoryAllocationLib/PrePiMemoryAllocationLib.inf b/EmbeddedPkg/Library/PrePiMemoryAllocationLib/PrePiMemoryAllocationLib.inf
index 21f6eb1e14bc..ea3d0f5da9c2 100644
--- a/EmbeddedPkg/Library/PrePiMemoryAllocationLib/PrePiMemoryAllocationLib.inf
+++ b/EmbeddedPkg/Library/PrePiMemoryAllocationLib/PrePiMemoryAllocationLib.inf
@@ -15,7 +15,7 @@ [Defines]
INF_VERSION = 0x00010005
BASE_NAME = PrePiMemoryAllocationLib
FILE_GUID = 4f14c900-51a9-11e0-afbf-0002a5d5c51b
- MODULE_TYPE = PEIM
+ MODULE_TYPE = SEC
VERSION_STRING = 1.0
LIBRARY_CLASS = MemoryAllocationLib

--
2.7.4


[PATCH 0/2] ArmVirtPkg EmbeddedPkg: fix build for CLANG35/ARM

Ard Biesheuvel
 

Currently, the ArmVirtQemuKernel and ArmVirtXen platforms will not build
for ARM when using CLANG35, due to the fact that the compiler emits
MOVT/MOVW pairs into objects that are used by the relocatable PrePi, and
such instruction pairs are not runtime relocatable in ELF (i.e., there are
no dynamic relocation types to describe them)

So fix this by selectively inhibiting the use of these pairs when building
these platforms for ARM using CLANG35

Ard Biesheuvel (2):
EmbeddedPkg: make PrePiMemoryAllocationLib a SEC type library
ArmVirtPkg ARM: make relocatable PrePi users build with CLANG35

ArmVirtPkg/ArmVirtQemuKernel.dsc | 8 ++++++++
ArmVirtPkg/ArmVirtXen.dsc | 9 +++++++++
EmbeddedPkg/Library/PrePiMemoryAllocationLib/PrePiMemoryAllocationLib.inf | 2 +-
3 files changed, 18 insertions(+), 1 deletion(-)

--
2.7.4


[edk2-platforms/branch]: pentium-celeron-n-udk2015

Guo, Mang <mang.guo@...>
 

Restructured BraswellPlatformPkg on pentium-celeron-n-udk2015 branch of edk2-platforms to follow Cover Creek requirement.



URL fork of edk2-platforms with the restructured code for review:
https://github.com/mangguo321/edk2-platforms/tree/Braswell


[Patch][Vlv2TbltDevicePkg] Enable Spread Spectrum of on-chip devices

Wei, David <david.wei@...>
 

From bf33c2b16e718f9b241889d2f3e863719731f340 Mon Sep 17 00:00:00 2001
From: david wei <david.wei@intel.com>
Date: Wed, 3 Aug 2016 16:02:34 +0800
Subject: [PATCH] Enable Spread Spectrum of on-chip devices.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Wei <david.wei@intel.com>
---
Vlv2TbltDevicePkg/Stitch/IFWIHeader/IFWI_HEADER.bin | Bin 4096 -> 4096 bytes
.../Stitch/IFWIHeader/IFWI_HEADER_SPILOCK.bin | Bin 4096 -> 4096 bytes
2 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/Vlv2TbltDevicePkg/Stitch/IFWIHeader/IFWI_HEADER.bin b/Vlv2TbltDevicePkg/Stitch/IFWIHeader/IFWI_HEADER.bin
index ca10f7af61b91e1daf79e374c6c837ee06e6ea4c..aa551cbc189290a6e1cc29a75ccd3b058e326e45 100644
GIT binary patch
delta 15
WcmZorXi(U|!^o7tyqS;j6CVH}&IBa@

delta 15
WcmZorXi(U|!^p(Iu$hnX6CVH{90S4t

diff --git a/Vlv2TbltDevicePkg/Stitch/IFWIHeader/IFWI_HEADER_SPILOCK.bin b/Vlv2TbltDevicePkg/Stitch/IFWIHeader/IFWI_HEADER_SPILOCK.bin
index f2dcb0067d1a48f08b4c4048362443b5c7095aa9..defc55461161943c6a62dda3f9c4315e30f05d61 100644
GIT binary patch
delta 15
WcmZorXi(U|!^o7tyqS;j6CVH}&IBa@

delta 15
WcmZorXi(U|!^p(Iu$hnX6CVH{90S4t

--
2.7.1.windows.2


Re: [PATCH 2/4] BaseTools-Conf:Introduce CLANG38 new toolchain for x86

Ard Biesheuvel
 

Hello Steven,

On 3 August 2016 at 08:48, Shi, Steven <steven.shi@intel.com> wrote:
This adds support for LLVM 3.8.x in LTO mode for IA32 and X64.
CLANG38 enable LLVM Link Time Optimization (LTO) and code size
optimization flag (-Oz) by default for aggressive code size
improvement. CLANG38 X64 code is small code model + PIE.

CLANG LTO needs PIE in link flags to generate PIE code correctly,
otherwise the PIE is not really enabled. (e.g. OvmfPkgX64 will
hang in 64bits SEC at high address because of small model code
displacement overflow).
This is probably caused by the same issue I am addressing with the
series I sent out yesterday, to pass the CC flags to the DLINK
command.

The reason is that code is generated by the link pass, so it needs to
see the same -fpie -mcmodel=small options that we passed to the
compiler as wel.

Could you check whether replacing '-Wl,-pie' with -fpie does the trick
as well? As I mentioned before, creating a PIE executable at link time
is not the same as generatic position independent code at compile time
(whether it is via $(CC) or via $(DLINK)). The PIE executable will
contain a .rela section that partially overlaps with other absolute
relocations, so it is best to avoid it.

Some more comments below

Test pass platforms: OVMF (OvmfPkgIa32.dsc, OvmfPkgX64.dsc and
OvmfPkgIa32X64.dsc).
Test compiler and linker version: LLVM 3.8, GNU ld 2.26.

Example steps to use the CLANG38 tool chain to build OVMF platform:
1. Download and extract the llvm 3.8.0 Pre-Built Binaries from
http://www.llvm.org/releases/ (e.g. http://www.llvm.org/releases/
3.8.0/clang+llvm-3.8.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz and
extract it as ~/clang38).
2. Copy LLVMgold.so from https://github.com/shijunjing/edk2/blob/
llvm/BaseTools/Bin/LLVMgold.so to above clang lib folder (e.g.
~/clang38/lib/LLVMgold.so)
3. Install new version linker with plugin support (e.g. ld 2.26 in
GNU Binutils 2.26 or Ubuntu16.04)
$ cd edk2
$ git checkout llvm
$ export CLANG38_BIN=path/to/your/clang38/
(e.g. export CLANG38_BIN=~/clang38/bin/)
$ source edksetup.sh
$ make -C BaseTools/Source/C
$ build -t CLANG38 -a X64 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -b DEBUG
-DDEBUG_ON_SERIAL_PORT
$ cd edk2/Build/OvmfX64/DEBUG_CLANG38/FV
$ qemu-system-x86_64.exe -bios OVMF.fd -serial file:serial.log -m 4096
-hda fat:.

If you want, you can build and install GNU Binutils 2.26 as below steps
in Ubuntu:
Download binutils-2.26 source code from http://ftp.gnu.org/gnu/binutils/
and extract it to ~/binutils-2.26
$sudo apt-get install bison
$sudo apt-get install flex
Install other necessary binutils build tools if missing
$ mkdir build
$ cd build
$ ../binutils-2.26/configure --enable-gold --enable-plugins
--disable-werror --prefix=/usr
$ make -j 5
$ sudo make install

If you want, you can build LLVMgold.so as below steps
Download llvm-3.8.0 source code from http://www.llvm.org/releases/
3.8.0/llvm-3.8.0.src.tar.xz and extract it to ~/llvm-3.8.0.src
Download clang3.8.0 source code from http://www.llvm.org/releases/
3.8.0/cfe-3.8.0.src.tar.xz and extract it to ~/llvm-3.8.0.src/tools/clang
Refer http://clang.llvm.org/get_started.html to Install other necessary
clang build tools if missing
$ mkdir llvm38build
$ cd llvm38build
If your GNU Binutils 2.26 is in /home/jshi19/binutils-2.26,
$ cmake ../llvm-3.8.0.src -G "Unix Makefiles" -DCMAKE_BUILD_TYPE="Release"
-DLLVM_TARGETS_TO_BUILD="X86" -DCMAKE_VERBOSE_MAKEFILE=ON
-DCMAKE_CXX_COMPILER="/usr/bin/g++" -DCMAKE_C_COMPILER="/usr/bin/gcc"
-DLLVM_BINUTILS_INCDIR=/home/jshi19/binutils-2.26/include
$ make -j 5 LLVMgold The LLVMgold.so is in ~/llvm38build/lib/LLVMgold.so

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi <steven.shi@intel.com>
---
BaseTools/Conf/tools_def.template | 81 +++++++++++++++++++++++++++++++++++++++
1 file changed, 81 insertions(+)
mode change 100644 => 100755 BaseTools/Conf/tools_def.template

diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template
old mode 100644
new mode 100755
index fd9eccb..6d964f1
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -5428,6 +5428,87 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)

####################################################################################
#
+# Clang 3.8 - This configuration is used to compile under Linux to produce
+# PE/COFF binaries using LLVM/Clang 3.8 with Link Time Optimization enabled
+#
+####################################################################################
+*_CLANG38_*_*_FAMILY = GCC
+*_CLANG38_*_MAKE_PATH = DEF(GCC5_IA32_PREFIX)make
+*_CLANG38_*_*_DLL = ENV(CLANG38_DLL)
+*_CLANG38_*_ASL_PATH = DEF(UNIX_IASL_BIN)
+
+*_CLANG38_*_APP_FLAGS =
+*_CLANG38_*_ASL_FLAGS = DEF(IASL_FLAGS)
+*_CLANG38_*_ASL_OUTFLAGS = DEF(IASL_OUTFLAGS)
+
+DEFINE CLANG38_IA32_PREFIX = ENV(CLANG38_BIN)
+DEFINE CLANG38_X64_PREFIX = ENV(CLANG38_BIN)
+
+DEFINE CLANG38_IA32_TARGET = -target i686-pc-linux-gnu
+DEFINE CLANG38_X64_TARGET = -target x86_64-pc-linux-gnu
+
+DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -Wno-empty-body -fno-stack-protector -fno-builtin -mms-bitfields -Wno-address -Wno-shift-negative-value -Wno-parentheses-equality -Wno-unknown-pragmas -Wno-tautological-constant-out-of-range-compare -Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -msoft-float -mno-implicit-float -ftrap-function=undefined_behavior_has_been_optimized_away_by_clang -funsigned-char -fno-ms-extensions -Wno-null-dereference -Wno-tautological-compare
+
+###########################
+# CLANG38 IA32 definitions
+###########################
+*_CLANG38_IA32_OBJCOPY_PATH = DEF(GCC5_IA32_PREFIX)objcopy
Why are you using the GCC5 prefix here? A clang user may not set GCC5_BIN

+*_CLANG38_IA32_CC_PATH = DEF(CLANG38_IA32_PREFIX)clang
+*_CLANG38_IA32_SLINK_PATH = DEF(CLANG38_IA32_PREFIX)llvm-ar
+*_CLANG38_IA32_DLINK_PATH = DEF(CLANG38_IA32_PREFIX)clang
+*_CLANG38_IA32_ASLDLINK_PATH = DEF(CLANG38_IA32_PREFIX)clang
+*_CLANG38_IA32_ASM_PATH = DEF(CLANG38_IA32_PREFIX)clang
+*_CLANG38_IA32_PP_PATH = DEF(CLANG38_IA32_PREFIX)clang
+*_CLANG38_IA32_VFRPP_PATH = DEF(CLANG38_IA32_PREFIX)clang
+*_CLANG38_IA32_ASLCC_PATH = DEF(CLANG38_IA32_PREFIX)clang
+*_CLANG38_IA32_ASLPP_PATH = DEF(CLANG38_IA32_PREFIX)clang
+*_CLANG38_IA32_RC_PATH = DEF(GCC5_IA32_PREFIX)objcopy
+
+*_CLANG38_IA32_ASLCC_FLAGS = -x c -Os -m32 DEF(CLANG38_IA32_TARGET) -flto
Does LTO make any sense for ACPI tables?

+*_CLANG38_IA32_ASLDLINK_FLAGS = DEF(GCC5_IA32_X64_DLINK_FLAGS) -Wl,-Oz -Wl,-melf_i386 -Wl,--entry,ReferenceAcpiTable -Wl,-u,ReferenceAcpiTable
+*_CLANG38_IA32_ASM_FLAGS = DEF(GCC5_ASM_FLAGS) -m32 -march=i386 DEF(CLANG38_IA32_TARGET)
+DEBUG_CLANG38_IA32_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m32 -Oz -flto -march=i586 DEF(CLANG38_IA32_TARGET) -g
+RELEASE_CLANG38_IA32_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m32 -Oz -flto -march=i586 DEF(CLANG38_IA32_TARGET)
+*_CLANG38_IA32_DLINK_FLAGS = DEF(GCC5_IA32_X64_DLINK_FLAGS) -Wl,-Oz -Wl,-melf_i386 -Wl,--oformat=elf32-i386
+*_CLANG38_IA32_DLINK2_FLAGS = DEF(GCC5_IA32_DLINK2_FLAGS)
+*_CLANG38_IA32_RC_FLAGS = DEF(GCC_IA32_RC_FLAGS)
+*_CLANG38_IA32_OBJCOPY_FLAGS =
+*_CLANG38_IA32_NASM_FLAGS = -f elf32
+*_CLANG38_IA32_PP_FLAGS = DEF(GCC_PP_FLAGS) DEF(CLANG38_IA32_TARGET)
+*_CLANG38_IA32_ASLPP_FLAGS = DEF(GCC_ASLPP_FLAGS) DEF(CLANG38_IA32_TARGET)
+*_CLANG38_IA32_VFRPP_FLAGS = DEF(GCC_VFRPP_FLAGS) DEF(CLANG38_IA32_TARGET)
+
+##########################
+# CLANG38 X64 definitions
+##########################
+*_CLANG38_X64_OBJCOPY_PATH = DEF(GCC5_X64_PREFIX)objcopy
+*_CLANG38_X64_CC_PATH = DEF(CLANG38_X64_PREFIX)clang
+*_CLANG38_X64_SLINK_PATH = DEF(CLANG38_X64_PREFIX)llvm-ar
+*_CLANG38_X64_DLINK_PATH = DEF(CLANG38_X64_PREFIX)clang
+*_CLANG38_X64_ASLDLINK_PATH = DEF(CLANG38_X64_PREFIX)clang
+*_CLANG38_X64_ASM_PATH = DEF(CLANG38_X64_PREFIX)clang
+*_CLANG38_X64_PP_PATH = DEF(CLANG38_X64_PREFIX)clang
+*_CLANG38_X64_VFRPP_PATH = DEF(CLANG38_X64_PREFIX)clang
+*_CLANG38_X64_ASLCC_PATH = DEF(CLANG38_X64_PREFIX)clang
+*_CLANG38_X64_ASLPP_PATH = DEF(CLANG38_X64_PREFIX)clang
+*_CLANG38_X64_RC_PATH = DEF(GCC5_X64_PREFIX)objcopy
+
+*_CLANG38_X64_ASLCC_FLAGS = -x c -Os -m64 -flto DEF(CLANG38_X64_TARGET)
+*_CLANG38_X64_ASLDLINK_FLAGS = DEF(GCC5_IA32_X64_DLINK_FLAGS) -Wl,-Oz -Wl,-melf_x86_64 -Wl,--entry,ReferenceAcpiTable -Wl,-u,ReferenceAcpiTable -Wl,-pie -mcmodel=small
+*_CLANG38_X64_ASM_FLAGS = DEF(GCC5_ASM_FLAGS) -m64 DEF(CLANG38_X64_TARGET)
+DEBUG_CLANG38_X64_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -fpie -Oz -flto DEF(CLANG38_X64_TARGET) -g
+RELEASE_CLANG38_X64_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -fpie -Oz -flto DEF(CLANG38_X64_TARGET)
+*_CLANG38_X64_DLINK_FLAGS = DEF(GCC5_IA32_X64_DLINK_FLAGS) -Wl,-Oz -Wl,-melf_x86_64 -Wl,--oformat=elf64-x86-64 -Wl,-pie -mcmodel=small
+*_CLANG38_X64_DLINK2_FLAGS = DEF(GCC5_X64_DLINK2_FLAGS)
+*_CLANG38_X64_RC_FLAGS = DEF(GCC_X64_RC_FLAGS)
+*_CLANG38_X64_OBJCOPY_FLAGS =
+*_CLANG38_X64_NASM_FLAGS = -f elf64
+*_CLANG38_X64_PP_FLAGS = DEF(GCC_PP_FLAGS) DEF(CLANG38_X64_TARGET)
+*_CLANG38_X64_ASLPP_FLAGS = DEF(GCC_ASLPP_FLAGS) DEF(CLANG38_X64_TARGET)
+*_CLANG38_X64_VFRPP_FLAGS = DEF(GCC_VFRPP_FLAGS) DEF(CLANG38_X64_TARGET)
+
+####################################################################################
+#
# Cygwin GCC And Intel ACPI Compiler
#
####################################################################################
--
2.7.4

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [PATCH 1/4] BaseTools-Conf:Remove short dash in ar flag for LLVM

Ard Biesheuvel
 

On 3 August 2016 at 08:48, Shi, Steven <steven.shi@intel.com> wrote:
Both binutils ar and LLVM ar support "cr", but LLVM ar doens't
support add "-" in the flags, and llvm-ar cannot accept "-cr".
So remove the short dash "-" to make llvm archives work.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi <steven.shi@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

---
BaseTools/Conf/build_rule.template | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
mode change 100644 => 100755 BaseTools/Conf/build_rule.template

diff --git a/BaseTools/Conf/build_rule.template b/BaseTools/Conf/build_rule.template
old mode 100644
new mode 100755
index 9adf391..6e7b7d4
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -266,7 +266,7 @@
"$(SLINK)" $(SLINK_FLAGS) /OUT:${dst} @$(OBJECT_FILES_LIST)

<Command.GCC, Command.GCCLD>
- "$(SLINK)" -cr ${dst} $(SLINK_FLAGS) @$(OBJECT_FILES_LIST)
+ "$(SLINK)" cr ${dst} $(SLINK_FLAGS) @$(OBJECT_FILES_LIST)

<Command.RVCT>
"$(SLINK)" $(SLINK_FLAGS) ${dst} --via $(OBJECT_FILES_LIST)
--
2.7.4

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[PATCH 4/4] ShellPkg-UefiShellCommandLib: Add EFIAPI in VA_List library function

Shi, Steven <steven.shi@...>
 

Add EFIAPI in CatPrint library function. Every function which uses
variable list need explicit use EFIAPI to force use MS ABI. This change
is needed to pass CLANG38 build.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi <steven.shi@intel.com>
---
ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c | 1 +
1 file changed, 1 insertion(+)
mode change 100644 => 100755 ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c

diff --git a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
old mode 100644
new mode 100755
index d157ebb..979693a
--- a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
+++ b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
@@ -85,6 +85,7 @@ typedef struct {

**/
EFI_STATUS
+EFIAPI
CatPrint (
IN OUT POOL_PRINT *Str,
IN CHAR16 *Fmt,
--
2.7.4


[PATCH 3/4] ShellPkg-UefiShellTftpCommandLib: Replace compiler builtin

Shi, Steven <steven.shi@...>
 

Use explicit CopyMem to replace compiler builtin to do the structure
values assignment. This change is needed to pass CLANG38 build.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi <steven.shi@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
---
ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
mode change 100644 => 100755 ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c

diff --git a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
old mode 100644
new mode 100755
index 666ee9d..5c50797
--- a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
+++ b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
@@ -342,7 +342,7 @@ ShellCommandRunTftp (
goto Error;
}

- Mtftp4ConfigData = DefaultMtftp4ConfigData;
+ CopyMem (&Mtftp4ConfigData, &DefaultMtftp4ConfigData, sizeof (EFI_MTFTP4_CONFIG_DATA));

//
// Check the host IPv4 address
--
2.7.4


[PATCH 2/4] BaseTools-Conf:Introduce CLANG38 new toolchain for x86

Shi, Steven <steven.shi@...>
 

This adds support for LLVM 3.8.x in LTO mode for IA32 and X64.
CLANG38 enable LLVM Link Time Optimization (LTO) and code size
optimization flag (-Oz) by default for aggressive code size
improvement. CLANG38 X64 code is small code model + PIE.

CLANG LTO needs PIE in link flags to generate PIE code correctly,
otherwise the PIE is not really enabled. (e.g. OvmfPkgX64 will
hang in 64bits SEC at high address because of small model code
displacement overflow).

Test pass platforms: OVMF (OvmfPkgIa32.dsc, OvmfPkgX64.dsc and
OvmfPkgIa32X64.dsc).
Test compiler and linker version: LLVM 3.8, GNU ld 2.26.

Example steps to use the CLANG38 tool chain to build OVMF platform:
1. Download and extract the llvm 3.8.0 Pre-Built Binaries from
http://www.llvm.org/releases/ (e.g. http://www.llvm.org/releases/
3.8.0/clang+llvm-3.8.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz and
extract it as ~/clang38).
2. Copy LLVMgold.so from https://github.com/shijunjing/edk2/blob/
llvm/BaseTools/Bin/LLVMgold.so to above clang lib folder (e.g.
~/clang38/lib/LLVMgold.so)
3. Install new version linker with plugin support (e.g. ld 2.26 in
GNU Binutils 2.26 or Ubuntu16.04)
$ cd edk2
$ git checkout llvm
$ export CLANG38_BIN=path/to/your/clang38/
(e.g. export CLANG38_BIN=~/clang38/bin/)
$ source edksetup.sh
$ make -C BaseTools/Source/C
$ build -t CLANG38 -a X64 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -b DEBUG
-DDEBUG_ON_SERIAL_PORT
$ cd edk2/Build/OvmfX64/DEBUG_CLANG38/FV
$ qemu-system-x86_64.exe -bios OVMF.fd -serial file:serial.log -m 4096
-hda fat:.

If you want, you can build and install GNU Binutils 2.26 as below steps
in Ubuntu:
Download binutils-2.26 source code from http://ftp.gnu.org/gnu/binutils/
and extract it to ~/binutils-2.26
$sudo apt-get install bison
$sudo apt-get install flex
Install other necessary binutils build tools if missing
$ mkdir build
$ cd build
$ ../binutils-2.26/configure --enable-gold --enable-plugins
--disable-werror --prefix=/usr
$ make -j 5
$ sudo make install

If you want, you can build LLVMgold.so as below steps
Download llvm-3.8.0 source code from http://www.llvm.org/releases/
3.8.0/llvm-3.8.0.src.tar.xz and extract it to ~/llvm-3.8.0.src
Download clang3.8.0 source code from http://www.llvm.org/releases/
3.8.0/cfe-3.8.0.src.tar.xz and extract it to ~/llvm-3.8.0.src/tools/clang
Refer http://clang.llvm.org/get_started.html to Install other necessary
clang build tools if missing
$ mkdir llvm38build
$ cd llvm38build
If your GNU Binutils 2.26 is in /home/jshi19/binutils-2.26,
$ cmake ../llvm-3.8.0.src -G "Unix Makefiles" -DCMAKE_BUILD_TYPE="Release"
-DLLVM_TARGETS_TO_BUILD="X86" -DCMAKE_VERBOSE_MAKEFILE=ON
-DCMAKE_CXX_COMPILER="/usr/bin/g++" -DCMAKE_C_COMPILER="/usr/bin/gcc"
-DLLVM_BINUTILS_INCDIR=/home/jshi19/binutils-2.26/include
$ make -j 5 LLVMgold The LLVMgold.so is in ~/llvm38build/lib/LLVMgold.so

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi <steven.shi@intel.com>
---
BaseTools/Conf/tools_def.template | 81 +++++++++++++++++++++++++++++++++++++++
1 file changed, 81 insertions(+)
mode change 100644 => 100755 BaseTools/Conf/tools_def.template

diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template
old mode 100644
new mode 100755
index fd9eccb..6d964f1
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -5428,6 +5428,87 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)

####################################################################################
#
+# Clang 3.8 - This configuration is used to compile under Linux to produce
+# PE/COFF binaries using LLVM/Clang 3.8 with Link Time Optimization enabled
+#
+####################################################################################
+*_CLANG38_*_*_FAMILY = GCC
+*_CLANG38_*_MAKE_PATH = DEF(GCC5_IA32_PREFIX)make
+*_CLANG38_*_*_DLL = ENV(CLANG38_DLL)
+*_CLANG38_*_ASL_PATH = DEF(UNIX_IASL_BIN)
+
+*_CLANG38_*_APP_FLAGS =
+*_CLANG38_*_ASL_FLAGS = DEF(IASL_FLAGS)
+*_CLANG38_*_ASL_OUTFLAGS = DEF(IASL_OUTFLAGS)
+
+DEFINE CLANG38_IA32_PREFIX = ENV(CLANG38_BIN)
+DEFINE CLANG38_X64_PREFIX = ENV(CLANG38_BIN)
+
+DEFINE CLANG38_IA32_TARGET = -target i686-pc-linux-gnu
+DEFINE CLANG38_X64_TARGET = -target x86_64-pc-linux-gnu
+
+DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -Wno-empty-body -fno-stack-protector -fno-builtin -mms-bitfields -Wno-address -Wno-shift-negative-value -Wno-parentheses-equality -Wno-unknown-pragmas -Wno-tautological-constant-out-of-range-compare -Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -msoft-float -mno-implicit-float -ftrap-function=undefined_behavior_has_been_optimized_away_by_clang -funsigned-char -fno-ms-extensions -Wno-null-dereference -Wno-tautological-compare
+
+###########################
+# CLANG38 IA32 definitions
+###########################
+*_CLANG38_IA32_OBJCOPY_PATH = DEF(GCC5_IA32_PREFIX)objcopy
+*_CLANG38_IA32_CC_PATH = DEF(CLANG38_IA32_PREFIX)clang
+*_CLANG38_IA32_SLINK_PATH = DEF(CLANG38_IA32_PREFIX)llvm-ar
+*_CLANG38_IA32_DLINK_PATH = DEF(CLANG38_IA32_PREFIX)clang
+*_CLANG38_IA32_ASLDLINK_PATH = DEF(CLANG38_IA32_PREFIX)clang
+*_CLANG38_IA32_ASM_PATH = DEF(CLANG38_IA32_PREFIX)clang
+*_CLANG38_IA32_PP_PATH = DEF(CLANG38_IA32_PREFIX)clang
+*_CLANG38_IA32_VFRPP_PATH = DEF(CLANG38_IA32_PREFIX)clang
+*_CLANG38_IA32_ASLCC_PATH = DEF(CLANG38_IA32_PREFIX)clang
+*_CLANG38_IA32_ASLPP_PATH = DEF(CLANG38_IA32_PREFIX)clang
+*_CLANG38_IA32_RC_PATH = DEF(GCC5_IA32_PREFIX)objcopy
+
+*_CLANG38_IA32_ASLCC_FLAGS = -x c -Os -m32 DEF(CLANG38_IA32_TARGET) -flto
+*_CLANG38_IA32_ASLDLINK_FLAGS = DEF(GCC5_IA32_X64_DLINK_FLAGS) -Wl,-Oz -Wl,-melf_i386 -Wl,--entry,ReferenceAcpiTable -Wl,-u,ReferenceAcpiTable
+*_CLANG38_IA32_ASM_FLAGS = DEF(GCC5_ASM_FLAGS) -m32 -march=i386 DEF(CLANG38_IA32_TARGET)
+DEBUG_CLANG38_IA32_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m32 -Oz -flto -march=i586 DEF(CLANG38_IA32_TARGET) -g
+RELEASE_CLANG38_IA32_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m32 -Oz -flto -march=i586 DEF(CLANG38_IA32_TARGET)
+*_CLANG38_IA32_DLINK_FLAGS = DEF(GCC5_IA32_X64_DLINK_FLAGS) -Wl,-Oz -Wl,-melf_i386 -Wl,--oformat=elf32-i386
+*_CLANG38_IA32_DLINK2_FLAGS = DEF(GCC5_IA32_DLINK2_FLAGS)
+*_CLANG38_IA32_RC_FLAGS = DEF(GCC_IA32_RC_FLAGS)
+*_CLANG38_IA32_OBJCOPY_FLAGS =
+*_CLANG38_IA32_NASM_FLAGS = -f elf32
+*_CLANG38_IA32_PP_FLAGS = DEF(GCC_PP_FLAGS) DEF(CLANG38_IA32_TARGET)
+*_CLANG38_IA32_ASLPP_FLAGS = DEF(GCC_ASLPP_FLAGS) DEF(CLANG38_IA32_TARGET)
+*_CLANG38_IA32_VFRPP_FLAGS = DEF(GCC_VFRPP_FLAGS) DEF(CLANG38_IA32_TARGET)
+
+##########################
+# CLANG38 X64 definitions
+##########################
+*_CLANG38_X64_OBJCOPY_PATH = DEF(GCC5_X64_PREFIX)objcopy
+*_CLANG38_X64_CC_PATH = DEF(CLANG38_X64_PREFIX)clang
+*_CLANG38_X64_SLINK_PATH = DEF(CLANG38_X64_PREFIX)llvm-ar
+*_CLANG38_X64_DLINK_PATH = DEF(CLANG38_X64_PREFIX)clang
+*_CLANG38_X64_ASLDLINK_PATH = DEF(CLANG38_X64_PREFIX)clang
+*_CLANG38_X64_ASM_PATH = DEF(CLANG38_X64_PREFIX)clang
+*_CLANG38_X64_PP_PATH = DEF(CLANG38_X64_PREFIX)clang
+*_CLANG38_X64_VFRPP_PATH = DEF(CLANG38_X64_PREFIX)clang
+*_CLANG38_X64_ASLCC_PATH = DEF(CLANG38_X64_PREFIX)clang
+*_CLANG38_X64_ASLPP_PATH = DEF(CLANG38_X64_PREFIX)clang
+*_CLANG38_X64_RC_PATH = DEF(GCC5_X64_PREFIX)objcopy
+
+*_CLANG38_X64_ASLCC_FLAGS = -x c -Os -m64 -flto DEF(CLANG38_X64_TARGET)
+*_CLANG38_X64_ASLDLINK_FLAGS = DEF(GCC5_IA32_X64_DLINK_FLAGS) -Wl,-Oz -Wl,-melf_x86_64 -Wl,--entry,ReferenceAcpiTable -Wl,-u,ReferenceAcpiTable -Wl,-pie -mcmodel=small
+*_CLANG38_X64_ASM_FLAGS = DEF(GCC5_ASM_FLAGS) -m64 DEF(CLANG38_X64_TARGET)
+DEBUG_CLANG38_X64_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -fpie -Oz -flto DEF(CLANG38_X64_TARGET) -g
+RELEASE_CLANG38_X64_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m64 "-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -fpie -Oz -flto DEF(CLANG38_X64_TARGET)
+*_CLANG38_X64_DLINK_FLAGS = DEF(GCC5_IA32_X64_DLINK_FLAGS) -Wl,-Oz -Wl,-melf_x86_64 -Wl,--oformat=elf64-x86-64 -Wl,-pie -mcmodel=small
+*_CLANG38_X64_DLINK2_FLAGS = DEF(GCC5_X64_DLINK2_FLAGS)
+*_CLANG38_X64_RC_FLAGS = DEF(GCC_X64_RC_FLAGS)
+*_CLANG38_X64_OBJCOPY_FLAGS =
+*_CLANG38_X64_NASM_FLAGS = -f elf64
+*_CLANG38_X64_PP_FLAGS = DEF(GCC_PP_FLAGS) DEF(CLANG38_X64_TARGET)
+*_CLANG38_X64_ASLPP_FLAGS = DEF(GCC_ASLPP_FLAGS) DEF(CLANG38_X64_TARGET)
+*_CLANG38_X64_VFRPP_FLAGS = DEF(GCC_VFRPP_FLAGS) DEF(CLANG38_X64_TARGET)
+
+####################################################################################
+#
# Cygwin GCC And Intel ACPI Compiler
#
####################################################################################
--
2.7.4


[PATCH 1/4] BaseTools-Conf:Remove short dash in ar flag for LLVM

Shi, Steven <steven.shi@...>
 

Both binutils ar and LLVM ar support "cr", but LLVM ar doens't
support add "-" in the flags, and llvm-ar cannot accept "-cr".
So remove the short dash "-" to make llvm archives work.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi <steven.shi@intel.com>
---
BaseTools/Conf/build_rule.template | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
mode change 100644 => 100755 BaseTools/Conf/build_rule.template

diff --git a/BaseTools/Conf/build_rule.template b/BaseTools/Conf/build_rule.template
old mode 100644
new mode 100755
index 9adf391..6e7b7d4
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -266,7 +266,7 @@
"$(SLINK)" $(SLINK_FLAGS) /OUT:${dst} @$(OBJECT_FILES_LIST)

<Command.GCC, Command.GCCLD>
- "$(SLINK)" -cr ${dst} $(SLINK_FLAGS) @$(OBJECT_FILES_LIST)
+ "$(SLINK)" cr ${dst} $(SLINK_FLAGS) @$(OBJECT_FILES_LIST)

<Command.RVCT>
"$(SLINK)" $(SLINK_FLAGS) ${dst} --via $(OBJECT_FILES_LIST)
--
2.7.4


[PATCH 0/4] Introduce CLANG38 toolchain in edk2

Shi, Steven <steven.shi@...>
 

Please review my new commits in public branch:
https://github.com/shijunjing/edk2/commits/llvm_v4

The difference from last V2(https://github.com/shijunjing/edk2/commits/llvm_v2):
1. Seperate the CLANG38 from the other two toolchains (GCC5, CLANGSCAN38), and only focus on CLANG38 in this serial.
2. Base on current GCC5 in edk2 to enhance the CLANG38.
3. Seperate the GenFW new relocation types support patch from this serial, and I will send it later in new serial.
4. Add EFIAPI for UefiShellCommandLib function.

Test pass platforms: OVMF (OvmfPkgIa32.dsc, OvmfPkgX64.dsc and
OvmfPkgIa32X64.dsc).
Test compiler and linker version: LLVM 3.8, GNU ld 2.26.

Example steps to use the CLANG38 tool chain to build OVMF platform:
1. Download and extract the llvm 3.8.0 Pre-Built Binaries from
http://www.llvm.org/releases/ (e.g. http://www.llvm.org/releases/
3.8.0/clang+llvm-3.8.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz and
extract it as ~/clang38).
2. Copy LLVMgold.so from https://github.com/shijunjing/edk2/blob/
llvm/BaseTools/Bin/LLVMgold.so to above clang lib folder (e.g.
~/clang38/lib/LLVMgold.so)
3. Install new version linker with plugin support (e.g. ld 2.26 in
GNU Binutils 2.26 or Ubuntu16.04)
$ cd edk2
$ git checkout llvm
$ export CLANG38_BIN=path/to/your/clang38/
(e.g. export CLANG38_BIN=~/clang38/bin/)
$ source edksetup.sh
$ make -C BaseTools/Source/C
$ build -t CLANG38 -a X64 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -b DEBUG
-DDEBUG_ON_SERIAL_PORT
$ cd edk2/Build/OvmfX64/DEBUG_CLANG38/FV
$ qemu-system-x86_64.exe -bios OVMF.fd -serial file:serial.log -m 4096
-hda fat:.


Shi, Steven (4):
BaseTools-Conf:Remove short dash in ar flag for LLVM
BaseTools-Conf:Introduce CLANG38 new toolchain for x86
ShellPkg-UefiShellTftpCommandLib: Replace compiler builtin
ShellPkg-UefiShellCommandLib: Add EFIAPI in VA_List library function

BaseTools/Conf/build_rule.template | 2 +-
BaseTools/Conf/tools_def.template | 81 ++++++++++++++++++++++
.../Library/UefiShellCommandLib/ConsistMapping.c | 1 +
ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c | 2 +-
4 files changed, 84 insertions(+), 2 deletions(-)
mode change 100644 => 100755 BaseTools/Conf/build_rule.template
mode change 100644 => 100755 BaseTools/Conf/tools_def.template
mode change 100644 => 100755 ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
mode change 100644 => 100755 ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c

--
2.7.4


Re: [PATCH] [staging/HTTPS-TLS] Delete extra TlsCipherMappingTable entries

Wu, Jiaxin <jiaxin.wu@...>
 

Reviewed-By: Wu Jiaxin <jiaxin.wu@intel.com>

Best Regards!
Jiaxin

-----Original Message-----
From: Thomas Palmer [mailto:thomas.palmer@hpe.com]
Sent: Wednesday, August 3, 2016 5:34 AM
To: edk2-devel@lists.01.org
Cc: Wu, Jiaxin <jiaxin.wu@intel.com>; Long, Qin <qin.long@intel.com>;
joseph.shifflett@hpe.com; Thomas Palmer <thomas.palmer@hpe.com>
Subject: [PATCH] [staging/HTTPS-TLS] Delete extra TlsCipherMappingTable
entries

The TlsCipherMappingTable will be used to control which ciphers UEFI
officially supports. When a user configures the ciphers, each cipher is
checked against this table and if not found is sent the EFI_UNSUPPORTED
error.

However, when an entry is present in TlsCipherMappingTable, but our library
does not have support for it, the user will not see any error if other ciphers
are being set at the same time.

This patch will remove entries from TlsLib's TlsCipherMappingTable that our
OpenSSL library is not configured to support. This restores behavior of
immediate feedback to user.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Palmer <thomas.palmer@hpe.com>
---
CryptoPkg/Library/TlsLib/TlsLib.c | 7 -------
1 file changed, 7 deletions(-)

diff --git a/CryptoPkg/Library/TlsLib/TlsLib.c
b/CryptoPkg/Library/TlsLib/TlsLib.c
index 1f3554a..aa08595 100644
--- a/CryptoPkg/Library/TlsLib/TlsLib.c
+++ b/CryptoPkg/Library/TlsLib/TlsLib.c
@@ -57,31 +57,24 @@ STATIC CONST TLS_CIPHER_PAIR
TlsCipherMappingTable[] = {
{ 0x0002, "NULL-SHA" }, /// TLS_RSA_WITH_NULL_SHA
{ 0x0004, "RC4-MD5" }, /// TLS_RSA_WITH_RC4_128_MD5
{ 0x0005, "RC4-SHA" }, /// TLS_RSA_WITH_RC4_128_SHA
- { 0x0007, "IDEA-CBC-SHA" }, /// TLS_RSA_WITH_IDEA_CBC_SHA
- { 0x0009, "DES-CBC-SHA" }, /// TLS_RSA_WITH_DES_CBC_SHA
{ 0x000A, "DES-CBC3-SHA" }, /// TLS_RSA_WITH_3DES_EDE_CBC_SHA,
mandatory TLS 1.1
- { 0x0013, "DHE-DSS-DES-CBC3-SHA" }, ///
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, mandatory TLS 1.0
{ 0x0016, "DHE-RSA-DES-CBC3-SHA" }, ///
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
{ 0x002F, "AES128-SHA" }, /// TLS_RSA_WITH_AES_128_CBC_SHA,
mandatory TLS 1.2
{ 0x0030, "DH-DSS-AES128-SHA" }, ///
TLS_DH_DSS_WITH_AES_128_CBC_SHA
{ 0x0031, "DH-RSA-AES128-SHA" }, ///
TLS_DH_RSA_WITH_AES_128_CBC_SHA
- { 0x0032, "DHE-DSS-AES128-SHA" }, ///
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
{ 0x0033, "DHE-RSA-AES128-SHA" }, ///
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
{ 0x0035, "AES256-SHA" }, /// TLS_RSA_WITH_AES_256_CBC_SHA
{ 0x0036, "DH-DSS-AES256-SHA" }, ///
TLS_DH_DSS_WITH_AES_256_CBC_SHA
{ 0x0037, "DH-RSA-AES256-SHA" }, ///
TLS_DH_RSA_WITH_AES_256_CBC_SHA
- { 0x0038, "DHE-DSS-AES256-SHA" }, ///
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
{ 0x0039, "DHE-RSA-AES256-SHA" }, ///
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
{ 0x003B, "NULL-SHA256" }, /// TLS_RSA_WITH_NULL_SHA256
{ 0x003C, "AES128-SHA256" }, ///
TLS_RSA_WITH_AES_128_CBC_SHA256
{ 0x003D, "AES256-SHA256" }, ///
TLS_RSA_WITH_AES_256_CBC_SHA256
{ 0x003E, "DH-DSS-AES128-SHA256" }, ///
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
{ 0x003F, "DH-RSA-AES128-SHA256" }, ///
TLS_DH_RSA_WITH_AES_128_CBC_SHA256
- { 0x0040, "DHE-DSS-AES128-SHA256" }, ///
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
{ 0x0067, "DHE-RSA-AES128-SHA256" }, ///
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
{ 0x0068, "DH-DSS-AES256-SHA256" }, ///
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
{ 0x0069, "DH-RSA-AES256-SHA256" }, ///
TLS_DH_RSA_WITH_AES_256_CBC_SHA256
- { 0x006A, "DHE-DSS-AES256-SHA256" }, ///
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
{ 0x006B, "DHE-RSA-AES256-SHA256" } ///
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
};

--
1.9.1


Re: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with the standardized one

Wu, Jiaxin <jiaxin.wu@...>
 

Agree to remove the below cipher sets to make it consistent with current openssl configuration.

IDEA-CBC-SHA
DHE-DSS-AES256-SHA
DHE-DSS-AES256-SHA256
DHE-DSS-AES128-SHA
DHE-DSS-AES128-SHA256
EDH-DSS-DES-CBC3-SHA
DES-CBC-SHA

Thanks,
Jiaxin

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Palmer, Thomas
Sent: Wednesday, August 3, 2016 5:14 AM
To: Wu, Jiaxin <jiaxin.wu@intel.com>; Long, Qin <qin.long@intel.com>;
edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Gao,
Liming <liming.gao@intel.com>
Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

I have two sets of lists, one for the ciphers the OpenSSL by default
configures in a new CTX and the other after setting all ciphers available in the
mapping table. For both sets I show the affect of removing no-idea/no-dsa
and adding enable-weak-ciphers

These are the ciphers that are supported by TLS immediately after a
TLS_CTX_new operation with current OpenSSL config (34):
AES128-GCM-SHA256
AES128-SHA
AES128-SHA256
AES256-GCM-SHA384
AES256-SHA
AES256-SHA256
DES-CBC3-SHA
DH-DSS-AES128-GCM-SHA256
DH-DSS-AES128-SHA
DH-DSS-AES128-SHA256
DH-DSS-AES256-GCM-SHA384
DH-DSS-AES256-SHA
DH-DSS-AES256-SHA256
DH-DSS-DES-CBC3-SHA
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA
DHE-RSA-AES256-SHA256
DH-RSA-AES128-GCM-SHA256
DH-RSA-AES128-SHA
DH-RSA-AES128-SHA256
DH-RSA-AES256-GCM-SHA384
DH-RSA-AES256-SHA
DH-RSA-AES256-SHA256
DH-RSA-DES-CBC3-SHA
EDH-RSA-DES-CBC3-SHA
PSK-3DES-EDE-CBC-SHA
PSK-AES128-CBC-SHA
PSK-AES256-CBC-SHA
PSK-RC4-SHA
RC4-MD5
RC4-SHA

By removing "no-idea" in process_files we gain (1):
IDEA-CBC-SHA

By removing "no-dsa" in process_files we gain (7):
DHE-DSS-AES128-GCM-SHA256
DHE-DSS-AES128-SHA
DHE-DSS-AES128-SHA256
DHE-DSS-AES256-GCM-SHA384
DHE-DSS-AES256-SHA
DHE-DSS-AES256-SHA256
EDH-DSS-DES-CBC3-SHA

We do not gain any more ciphers with enable-weak-ssl-ciphers at this point.


Now here are the ciphers after TlsSetCipherList has been run with setting all
ciphers currently in TlsCipherMappingTable.
With original OpenSSL configuration (23):
AES128-SHA
AES128-SHA256
AES256-SHA
AES256-SHA256
DES-CBC3-SHA
DH-DSS-AES128-SHA
DH-DSS-AES128-SHA256
DH-DSS-AES256-SHA
DH-DSS-AES256-SHA256
DHE-RSA-AES128-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA
DHE-RSA-AES256-SHA256
DH-RSA-AES128-SHA
DH-RSA-AES128-SHA256
DH-RSA-AES256-SHA
DH-RSA-AES256-SHA256
EDH-RSA-DES-CBC3-SHA
NULL-MD5
NULL-SHA
NULL-SHA256
RC4-MD5
RC4-SHA

By removing "no-idea" in process_files we gain (1):
IDEA-CBC-SHA

By removing "no-dsa" in process_files we gain (5):
DHE-DSS-AES256-SHA
DHE-DSS-AES256-SHA256
DHE-DSS-AES128-SHA
DHE-DSS-AES128-SHA256
EDH-DSS-DES-CBC3-SHA

Be adding enable-weak-ssl-ciphers we gain (1):
DES-CBC-SHA


Thomas

-----Original Message-----
From: Wu, Jiaxin [mailto:jiaxin.wu@intel.com]
Sent: Monday, August 1, 2016 9:03 PM
To: Palmer, Thomas <thomas.palmer@hpe.com>; Long, Qin
<qin.long@intel.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Gao,
Liming <liming.gao@intel.com>
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with
the standardized one

Thomas,

Thanks your effort to test the new ciphers, can you provide the info which
one is unsupported currently?

As Qin's comments, "we'd better to keep the current supported cipher suite
for our UEFI- TLS enabling". If so, I agree to remove the unsupported one in
TlsCipherMappingTable instead of changing the current openssl configuration.
If dsa /idea is required in future, then we can consider how to enable the
configuration.

So, can you provide the patch to remove the unsupported one in
TlsCipherMappingTable?


Thanks,
Jiaxin



-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Palmer, Thomas
Sent: Tuesday, August 2, 2016 9:51 AM
To: Wu, Jiaxin <jiaxin.wu@intel.com>; Long, Qin <qin.long@intel.com>;
edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>;
Gao, Liming <liming.gao@intel.com>
Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one


Hi Jiaxin,

It sounds like we both agree that TlsCipherMappingTable is the list
of what UEFI officially supports. If it is advertised in
TlsCipherMappingTable then OpenSSL needs to support it.

My proposal of removing no-dsa / no-idea and adding weak-ciphers
is
specifically aimed to syncing how OpenSSL is configured/built to what
is in TlsCipherMappingTable. I was busy last week testing out the new
ciphers and realized a few were not even getting configured in OpenSSL.

Thomas

-----Original Message-----
From: Wu, Jiaxin [mailto:jiaxin.wu@intel.com]
Sent: Monday, August 1, 2016 8:34 PM
To: Palmer, Thomas <thomas.palmer@hpe.com>; Long, Qin
<qin.long@intel.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>;
Gao, Liming <liming.gao@intel.com>
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

Hi Thomas,

Since the Tls1.h is used to hold the standardized definitions, openssl
part is not taken into consideration. The Cipher Suites added in
Tls1.h only refers to
A.5 of rfc-2246, rfc-4346 and rfc-5246. The criteria is removing all
the limited/insecurity/deprecated ones that specified in RFC -- "Note
that this mode is vulnerable to man-in-the middle attacks and is
therefore deprecated." I know the IDEA and DES cipher suites are also
deprecated in TLS1.2, but it does means to TLS1.1. So, some of them are
still kept in Tls1.h.

As for the TlsCipherMappingTable, it takes on the link between Tls1.h
defined cipher suites and openssl supported cipher suites. If we
eliminate the factors of configuration, I believe the cipher suites in
TlsCipherMappingTable should be implemented in OpenSSL lib. I haven't
check them one by one but openssl official document is referred @
https://www.openssl.org/docs/manmaster/apps/ciphers.html, which
gives
the lists of TLS cipher suites names from the relevant specification
and their OpenSSL equivalents.

If the cipher suites in Tls1.h is not found in TlsCipherMappingTable,
EFI_UNSUPPORTED will be returned. I think it's reasonable.

Thanks,
Jiaxin

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf
Of Palmer, Thomas
Sent: Tuesday, August 2, 2016 5:46 AM
To: Long, Qin <qin.long@intel.com>; Wu, Jiaxin
<jiaxin.wu@intel.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>;
Gao, Liming <liming.gao@intel.com>
Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

Jiaxin / Qin,


I'm unaware of what criteria is required for a cipher to be in this
TlsCipherMappingTable. I had presumed that it would be b/c UEFI
supported the cipher for TLS operation. If unsupported ciphers are
allowed ... then logically wouldn't we need to add all ciphers?
What advantage do we gain by having an entry in this table but not
actually use
the cipher in communication?

Currently TlsGetCipherString is the only means we have to validate
the cipher string. If a cipher is in the table but not in OpenSSL
lib, then we will provide imperfect feedback if the unsupported
cipher is buried in a list of supported ciphers. OpenSSL will
simply use only the ciphers it supports and quietly drop the unsupported
cipher.
A user that inspects the list of set ciphers would be curious why a
certain
cipher was being "dropped" /
"filtered". However, if TlsGetCipherString sees that the cipher is not in
our
mapping table the TlsSetCipherList function will return immediate
feedback.

I'm not enthralled with supporting weak/idea ciphers either. I
would vouch for us removing those ciphers from
TlsCipherMappingTable. It is not our responsibility to document the
IANA/Description string description in code.

This document
(http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52
r1
.pdf) would be a good list for initial cipher support. We have some
of the ciphers on the list already. Here is the sorted list:

TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS_DH_DSS_WITH_AES_128_GCM_SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS_DH_DSS_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CCM17
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CCM
TLS_RSA_WITH_AES_256_GCM_SHA384

Thomas

-----Original Message-----
From: Long, Qin [mailto:qin.long@intel.com]
Sent: Sunday, July 31, 2016 8:48 PM
To: Wu, Jiaxin <jiaxin.wu@intel.com>; Palmer, Thomas
<thomas.palmer@hpe.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>;
Gao, Liming <liming.gao@intel.com>
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

I personally prefer to keep the current supported cipher suite for
our
UEFI- TLS enabling. We can have the full RFC definitions, and
platform specific cipher sets for validation now. It's better to
maintain one minimal scope in this phase.

"enable-weak-ssl-ciphers" looks odd. Disabling weak ciphers is the
recommendation for hardening SSL communications.
For other ciphers (idea, dsa, etc), we can enable them step-by-step
depending on the real requirements.


Best Regards & Thanks,
LONG, Qin

-----Original Message-----
From: Wu, Jiaxin
Sent: Monday, August 01, 2016 9:23 AM
To: Palmer, Thomas; Long, Qin; edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Gao, Liming
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

Thomas,
I agree some of them are not supported due to the UEFI OpenSSL
configuration, but it doesn't affect those mapping relationship
added in the patch. So, I have no strong opinion whether to
support it by modifying the current OpenSSL configuration. Since
Qin is the OpenSSL expert, I'd like to hear his views.

Qin,
What's your opinion?

Thanks.
Jiaxin

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On
Behalf Of Palmer, Thomas
Sent: Saturday, July 30, 2016 6:03 AM
To: Wu, Jiaxin <jiaxin.wu@intel.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan
<siyuan.fu@intel.com>; Gao, Liming <liming.gao@intel.com>; Long,
Qin <qin.long@intel.com>
Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the
TLS definitions with the standardized one

Jiaxin,

UEFI's OpenSSL library does not support all the ciphers that
were added in your patch due to the UEFI configuration. We need
to remove
"no- idea" and "no-dsa" from the process_files.sh and add
"enable-weak-ssl- ciphers"

While we are modifying process_files.sh, we can remove "no-
pqueue"
from process_files.sh so that OpensslLib.inf is in sync.

I can send out a patch to do so if you wish.

Thomas

-----Original Message-----
From: Jiaxin Wu [mailto:jiaxin.wu@intel.com]
Sent: Thursday, July 14, 2016 12:51 AM
To: edk2-devel@lists.01.org
Cc: Liming Gao <liming.gao@intel.com>; Palmer, Thomas
<thomas.palmer@hpe.com>; Long Qin <qin.long@intel.com>; Ye Ting
<ting.ye@intel.com>; Fu Siyuan <siyuan.fu@intel.com>; Wu Jiaxin
<jiaxin.wu@intel.com>
Subject: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

The series patches are used to replace the TLS definitions with
the standardized one. In addition, more TLS cipher suite mapping
between Cipher Suite definitions and OpenSSL-used Cipher Suite
name
are added.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Palmer Thomas <thomas.palmer@hpe.com>
Cc: Long Qin <qin.long@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>

Jiaxin Wu (4):
MdePkg: Add a header to standardize TLS definitions
CryptoPkg: Add more TLS cipher suite mapping
NetworkPkg/TlsDxe: Replace the definitions with the
standardized
one
NetworkPkg/HttpDxe: Replace the definitions with the
standardized one

CryptoPkg/Library/TlsLib/TlsLib.c | 3585 ++++++++++++++++-------
--
---
--
--
MdePkg/Include/IndustryStandard/Tls1.h | 93 +
NetworkPkg/HttpDxe/HttpDriver.h | 2 +
NetworkPkg/HttpDxe/HttpProto.c | 12 +-
NetworkPkg/HttpDxe/HttpsSupport.c | 22 +-
NetworkPkg/HttpDxe/HttpsSupport.h | 44 -
NetworkPkg/TlsDxe/TlsImpl.c | 56 +-
NetworkPkg/TlsDxe/TlsImpl.h | 30 +-
NetworkPkg/TlsDxe/TlsProtocol.c | 2 +-
9 files changed, 1945 insertions(+), 1901 deletions(-) create
mode
100644 MdePkg/Include/IndustryStandard/Tls1.h

--
1.9.5.msysgit.1

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [patch] MdeModulePkg/UsbMass: Not retry if usb bot transfer execution fail

Zeng, Star <star.zeng@...>
 

Reviewed-by: Star Zeng <star.zeng@intel.com>

-----Original Message-----
From: Tian, Feng
Sent: Wednesday, August 3, 2016 10:08 AM
To: Zeng, Star <star.zeng@intel.com>
Cc: edk2-devel@lists.01.org
Subject: [patch] MdeModulePkg/UsbMass: Not retry if usb bot transfer execution fail

[Sorry, this patch was pushed into EDKII trunk by wrong operation.

If the review mail could pass review, I would prefer to not do a roll-back.
Sorry again for that.

If there is other opinions, please let me know.]

The retry mechanism will bring issue if the usb device is unplugged from XHCI HC but s/w is trying to access it through BlockIo. The current cmd will get device error return status, but the sequential cmds will be timeout. This behavior will cause system unresponsive for a long while and bring bad user experience.

So we break the retry loop if found device error.

Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian <feng.tian@intel.com>
---
MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c | 9 +++++++-- MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c | 8 ++++++--
2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
index 9f99650..96c3622 100644
--- a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
+++ b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
@@ -2,7 +2,7 @@
Implementation of the command set of USB Mass Storage Specification
for Bootability, Revision 1.0.

-Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.<BR>
This program and the accompanying materials are licensed and made available under the terms and conditions of the BSD License which accompanies this distribution. The full text of the license may be found at @@ -189,6 +189,11 @@ UsbBootExecCmd (
return EFI_TIMEOUT;
}

+ if (Status == EFI_DEVICE_ERROR) {
+ DEBUG ((EFI_D_ERROR, "UsbBootExecCmd: Device Error to Exec 0x%x Cmd\n", *(UINT8 *)Cmd));
+ return EFI_DEVICE_ERROR;
+ }
+
//
// If ExecCommand() returns no error and CmdResult is success,
// then the commnad transfer is successful.
@@ -271,7 +276,7 @@ UsbBootExecCmdWithRetry (
DataLen,
Timeout
);
- if (Status == EFI_SUCCESS || Status == EFI_MEDIA_CHANGED || Status == EFI_NO_MEDIA) {
+ if (Status == EFI_SUCCESS || Status == EFI_MEDIA_CHANGED || Status
+ == EFI_NO_MEDIA || Status == EFI_DEVICE_ERROR) {
break;
}
//
diff --git a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c
index dd83540..0767ff0 100644
--- a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c
+++ b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c
@@ -2,7 +2,7 @@
Implementation of the USB mass storage Bulk-Only Transport protocol,
according to USB Mass Storage Class Bulk-Only Transport, Revision 1.0.

-Copyright (c) 2007 - 2011, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.<BR>
This program and the accompanying materials are licensed and made available under the terms and conditions of the BSD License which accompanies this distribution. The full text of the license may be found at @@ -432,7 +432,11 @@ UsbBotExecCommand (
// whether it succeeds or fails.
//
TransLen = (UINTN) DataLen;
- UsbBotDataTransfer (UsbBot, DataDir, Data, &TransLen, Timeout);
+ Status = UsbBotDataTransfer (UsbBot, DataDir, Data, &TransLen, Timeout);
+ if (Status == EFI_DEVICE_ERROR) {
+ DEBUG ((EFI_D_ERROR, "UsbBotExecCommand: UsbBotDataTransfer (%r)\n", Status));
+ return Status;
+ }

//
// Get the status, if that succeeds, interpret the result
--
2.7.1.windows.2


[patch] MdeModulePkg/UsbMass: Not retry if usb bot transfer execution fail

Feng Tian <feng.tian@...>
 

[Sorry, this patch was pushed into EDKII trunk by wrong operation.

If the review mail could pass review, I would prefer to not do a roll-back.
Sorry again for that.

If there is other opinions, please let me know.]

The retry mechanism will bring issue if the usb device is unplugged
from XHCI HC but s/w is trying to access it through BlockIo. The
current cmd will get device error return status, but the sequential
cmds will be timeout. This behavior will cause system unresponsive
for a long while and bring bad user experience.

So we break the retry loop if found device error.

Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian <feng.tian@intel.com>
---
MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c | 9 +++++++--
MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c | 8 ++++++--
2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
index 9f99650..96c3622 100644
--- a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
+++ b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
@@ -2,7 +2,7 @@
Implementation of the command set of USB Mass Storage Specification
for Bootability, Revision 1.0.

-Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.<BR>
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -189,6 +189,11 @@ UsbBootExecCmd (
return EFI_TIMEOUT;
}

+ if (Status == EFI_DEVICE_ERROR) {
+ DEBUG ((EFI_D_ERROR, "UsbBootExecCmd: Device Error to Exec 0x%x Cmd\n", *(UINT8 *)Cmd));
+ return EFI_DEVICE_ERROR;
+ }
+
//
// If ExecCommand() returns no error and CmdResult is success,
// then the commnad transfer is successful.
@@ -271,7 +276,7 @@ UsbBootExecCmdWithRetry (
DataLen,
Timeout
);
- if (Status == EFI_SUCCESS || Status == EFI_MEDIA_CHANGED || Status == EFI_NO_MEDIA) {
+ if (Status == EFI_SUCCESS || Status == EFI_MEDIA_CHANGED || Status == EFI_NO_MEDIA || Status == EFI_DEVICE_ERROR) {
break;
}
//
diff --git a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c
index dd83540..0767ff0 100644
--- a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c
+++ b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c
@@ -2,7 +2,7 @@
Implementation of the USB mass storage Bulk-Only Transport protocol,
according to USB Mass Storage Class Bulk-Only Transport, Revision 1.0.

-Copyright (c) 2007 - 2011, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.<BR>
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -432,7 +432,11 @@ UsbBotExecCommand (
// whether it succeeds or fails.
//
TransLen = (UINTN) DataLen;
- UsbBotDataTransfer (UsbBot, DataDir, Data, &TransLen, Timeout);
+ Status = UsbBotDataTransfer (UsbBot, DataDir, Data, &TransLen, Timeout);
+ if (Status == EFI_DEVICE_ERROR) {
+ DEBUG ((EFI_D_ERROR, "UsbBotExecCommand: UsbBotDataTransfer (%r)\n", Status));
+ return Status;
+ }

//
// Get the status, if that succeeds, interpret the result
--
2.7.1.windows.2