Re: [edk2] [Patch] BaseTools: Add support for $(FAMILY) macro

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Yonghong Zhu
> Sent: Monday, July 04, 2016 5:27 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: [edk2] [Patch] BaseTools: Add support for $(FAMILY) macro
> 
> Build spec mentions $(FAMILY) macro be used in DSC/FDF to specify the tool
> chain family, like GCC, MSFT. This patch add the support for this macro.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Yonghong Zhu 
> ---
>  BaseTools/Source/Python/build/build.py | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/BaseTools/Source/Python/build/build.py
> b/BaseTools/Source/Python/build/build.py
> index 4f859bf..d9afdcc 100644
> --- a/BaseTools/Source/Python/build/build.py
> +++ b/BaseTools/Source/Python/build/build.py
> @@ -784,10 +784,11 @@ class Build():
>  self.Db = WorkspaceDatabase(":memory:")
>  else:
>  self.Db = WorkspaceDatabase(GlobalData.gDatabasePath,
> self.Reparse)
>  self.BuildDatabase = self.Db.BuildObject
>  self.Platform = None
> +self.ToolChainFamily = None
>  self.LoadFixAddress = 0
>  self.UniFlag= BuildOptions.Flag
>  self.BuildModules = []
>  self.Db_Flag = False
>  self.LaunchPrebuildFlag = False
> @@ -876,10 +877,21 @@ class Build():
>  EdkLogger.error("build", RESOURCE_NOT_AVAILABLE,
>  ExtraData="[%s] not defined. No toolchain 
> available for
> build!\n" % ", ".join(self.ToolChainList))
>  else:
>  self.ToolChainList = NewToolChainList
> 
> +ToolChainFamily = []
> +ToolDefinition = self.ToolDef.ToolsDefTxtDatabase
> +for Tool in self.ToolChainList:
> +if TAB_TOD_DEFINES_FAMILY not in ToolDefinition or Tool not in
> ToolDefinition[TAB_TOD_DEFINES_FAMILY] \
> +   or not ToolDefinition[TAB_TOD_DEFINES_FAMILY][Tool]:
> +EdkLogger.warn("No tool chain family found in configuration 
> for %s.
> Default to MSFT." % Tool)
> +ToolChainFamily.append("MSFT")
> +else:
> +
> ToolChainFamily.append(ToolDefinition[TAB_TOD_DEFINES_FAMILY][Tool])
> +self.ToolChainFamily = ToolChainFamily
> +
>  if self.ThreadNumber == None:
>  self.ThreadNumber =
> self.TargetTxt.TargetTxtDictionary[DataType.TAB_TAT_DEFINES_MAX_CONC
> URRENT_THREAD_NUMBER]
>  if self.ThreadNumber == '':
>  self.ThreadNumber = 0
>  else:
> @@ -934,10 +946,12 @@ class Build():
>  if self.ArchList:
>  GlobalData.gGlobalDefines['ARCH'] = self.ArchList[0]
>  if self.ToolChainList:
>  GlobalData.gGlobalDefines['TOOLCHAIN'] = self.ToolChainList[0]
>  GlobalData.gGlobalDefines['TOOL_CHAIN_TAG'] = 
> self.ToolChainList[0]
> +if self.ToolChainFamily:
> +GlobalData.gGlobalDefines['FAMILY'] = self.ToolChainFamily[0]
>  if 'PREBUILD' in GlobalData.gCommandLineDefines.keys():
>  self.Prebuild   = GlobalData.gCommandLineDefines.get('PREBUILD')
>  else:
>  self.Db.InitDatabase()
>  self.Db_Flag = True
> @@ -1597,13 +1611,16 @@ class Build():
>  #
>  def _BuildPlatform(self):
>  SaveFileOnChange(self.PlatformBuildPath, '# DO NOT EDIT \n# FILE
> auto-generated\n', False)
>  for BuildTarget in self.BuildTargetList:
>  GlobalData.gGlobalDefines['TARGET'] = BuildTarget
> +index = 0
>  for ToolChain in self.ToolChainList:
>  GlobalData.gGlobalDefines['TOOLCHAIN'] = ToolChain
>  GlobalData.gGlobalDefines['TOOL_CHAIN_TAG'] = ToolChain
> +GlobalData.gGlobalDefines['FAMILY'] = 
> self.ToolChainFamily[index]
> +index += 1
>  Wa = WorkspaceAutoGen(
>  self.WorkspaceDir,
>  self.PlatformFile,
>  BuildTarget,
>  ToolChain,
> @@ -1677,13 +1694,16 @@ class Build():
>  ## Build active module for different build targets, different tool 
> chains and
> different archs
>  #
>  def _BuildModule(self):
>  for BuildTarget in self.BuildTargetList:
>  GlobalData.gGlobalDefines['TARGET'] = BuildTarget
> +index = 0
>  for ToolChain in self.ToolChainList:
>  GlobalData.gGlobalDefines['TOOLCHAIN'] = ToolChain
>  GlobalData.gGlobalDefines['TOOL_CHAIN_TAG'] = ToolChain
> +GlobalData.gGlobalDefines['FAMILY'] = 
> self.ToolChainFamily[index]
> +index += 1
>  #
>  # module build needs 

[edk2] [patch 0/2]MdeModulePkg: Add error handling codes in function HiiGetFormSetFromHiiHandle

[Dandan Bi]

Patch 1 is to enhance the error handling codes in function 
HiiGetFormSetFromHiiHandle 
Patch 2 is enhance the logic in the caller functions of 
HiiGetFormSetFromHiiHandle.

Cc: Eric Dong 
Cc: Hao Wu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 

Dandan Bi (2):
  MdeModulePkg/UefiHiiLib: Add error handling codes when
AllocateCopyPool fail
  MdeModulePkg/Ui: Add ASSERT before using the pointer "Buffer"

 .../Application/UiApp/FrontPageCustomizedUiSupport.c   |  1 +
 .../BootMaintenanceManagerCustomizedUiSupport.c|  1 +
 MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c|  3 ++-
 MdeModulePkg/Library/UefiHiiLib/HiiLib.c   | 14 --
 4 files changed, 16 insertions(+), 3 deletions(-)

-- 
1.9.5.msysgit.1

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

[edk2] [patch 1/2] MdeModulePkg/UefiHiiLib: Add error handling codes when AllocatePool fail

[Dandan Bi]

Cc: Eric Dong 
Cc: Hao Wu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 MdeModulePkg/Library/UefiHiiLib/HiiLib.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Library/UefiHiiLib/HiiLib.c 
b/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
index 74ccd02..afd9985 100644
--- a/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
+++ b/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
@@ -1,9 +1,9 @@
 /** @file
   HII Library implementation that uses DXE protocols and services.
 
-  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
   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
   http://opensource.org/licenses/bsd-license.php
 
@@ -463,14 +463,23 @@ HiiGetFormSetFromHiiHandle(
 continue;
   }
 
   if (FormSetBuffer != NULL){
 TempBuffer = AllocateCopyPool (TempSize + ((EFI_IFR_OP_HEADER *) 
OpCodeData)->Length, FormSetBuffer);
-CopyMem (TempBuffer + TempSize,  OpCodeData, ((EFI_IFR_OP_HEADER *) 
OpCodeData)->Length);
 FreePool(FormSetBuffer);
+FormSetBuffer = NULL;
+if (TempBuffer == NULL) {
+  Status = EFI_OUT_OF_RESOURCES;
+  goto Done;
+}
+CopyMem (TempBuffer + TempSize,  OpCodeData, ((EFI_IFR_OP_HEADER *) 
OpCodeData)->Length);
   } else {
 TempBuffer = AllocateCopyPool (TempSize + ((EFI_IFR_OP_HEADER *) 
OpCodeData)->Length, OpCodeData);
+if (TempBuffer == NULL) {
+  Status = EFI_OUT_OF_RESOURCES;
+  goto Done;
+}
   }
   TempSize += ((EFI_IFR_OP_HEADER *) OpCodeData)->Length;
   FormSetBuffer = TempBuffer;
 
   Status = EFI_SUCCESS;
@@ -478,10 +487,11 @@ HiiGetFormSetFromHiiHandle(
   //One form package has one formset, exit current form package to search 
other form package in the packagelist.
   //
   break;
 }
   }
+Done:
   FreePool (HiiPackageList);
 
   *BufferSize = TempSize;
   *Buffer = (EFI_IFR_FORM_SET *)FormSetBuffer;
 
-- 
1.9.5.msysgit.1

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

[edk2] [patch 2/2] IntelFrameworkModulePkg/LegacyUi: Get legacy options when open legacy form

[Dandan Bi]

The LegacyBootMaintUiLib depends on the LegacyBootManagerLib to realize its
functionality, the LegacyBootManagerLib may initialize after 
LegacyBootMaintUiLib, so the functionality of LegacyBootMaintUiLib may 
be incorrect. Now we fix this issue by executing the related codes when 
opening the legacy forminstead in its the constructor function. Because 
when opening the legacy form, the LegacyBootManagerLib must have been 
initialized.

Cc: Liming Gao 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 
---
 .../LegacyBootMaintUiLib/LegacyBootMaintUi.c   | 42 ++
 1 file changed, 36 insertions(+), 6 deletions(-)

diff --git 
a/IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUi.c 
b/IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUi.c
index 3a3eeed..5e1ad54 100644
--- a/IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUi.c
+++ b/IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUi.c
@@ -17,10 +17,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 LEGACY_BOOT_OPTION_CALLBACK_DATA  *mLegacyBootOptionPrivate;
 EFI_GUID  mLegacyBootOptionGuid = LEGACY_BOOT_OPTION_FORMSET_GUID;
 CHAR16mLegacyBootStorageName[]  = L"LegacyBootData";
 BBS_TYPE  mBbsType[] = {BBS_FLOPPY, BBS_HARDDISK, BBS_CDROM, 
BBS_EMBED_NETWORK, BBS_BEV_DEVICE, BBS_UNKNOWN};
+BOOLEAN   mFirstEnterLegacyForm = FALSE;
 
 
 ///
 /// Legacy FD Info from LegacyBios.GetBbsInfo()
 ///
@@ -93,10 +94,30 @@ HII_VENDOR_DEVICE_PATH  
mLegacyBootOptionHiiVendorDevicePath = {
   (UINT8) ((END_DEVICE_PATH_LENGTH) >> 8)
 }
   }
 };
 
+/**
+
+  Build the LegacyFDMenu LegacyHDMenu LegacyCDMenu according to 
LegacyBios.GetBbsInfo().
+
+**/
+VOID
+GetLegacyOptions (
+  VOID
+  );
+
+
+/**
+
+  Base on the L"LegacyDevOrder" variable to build the current order data.
+
+**/
+VOID
+GetLegacyOptionsOrder (
+  VOID
+  );
 
 /**
   Re-order the Boot Option according to the DevOrder.
 
   The routine re-orders the Boot Option in BootOption array according to
@@ -1092,21 +1113,34 @@ LegacyBootOptionCallback (
   IN  UINT8  Type,
   IN  EFI_IFR_TYPE_VALUE *Value,
   OUT EFI_BROWSER_ACTION_REQUEST *ActionRequest
   )
 {
-  if (Action != EFI_BROWSER_ACTION_CHANGED && Action != 
EFI_BROWSER_ACTION_CHANGING) {
+  if (Action != EFI_BROWSER_ACTION_CHANGED && Action != 
EFI_BROWSER_ACTION_CHANGING && Action != EFI_BROWSER_ACTION_FORM_OPEN) {
 //
-// Do nothing for other UEFI Action. Only do call back when data is 
changed.
+// Do nothing for other UEFI Action. Only do call back when data is 
changed or the form is open.
 //
 return EFI_UNSUPPORTED;
   }
 
   if ((Value == NULL) || (ActionRequest == NULL)) {
 return EFI_INVALID_PARAMETER;
   }
 
+  if (Action == EFI_BROWSER_ACTION_FORM_OPEN) {
+if (!mFirstEnterLegacyForm) {
+  //
+  // The leagcyBootMaintUiLib depends on the LegacyBootManagerLib to 
realize its functionality.
+  // We need to do the leagcy boot options related actions after the 
LegacyBootManagerLib has been initialized.
+  // Opening the legacy menus is the appropriate time that the 
LegacyBootManagerLib has already been initialized.
+  //
+  mFirstEnterLegacyForm = TRUE;
+  GetLegacyOptions ();
+  GetLegacyOptionsOrder ();
+}
+  }
+
   if (Action == EFI_BROWSER_ACTION_CHANGING) {
 switch (QuestionId) {
 case FORM_FLOPPY_BOOT_ID:
 case FORM_HARDDISK_BOOT_ID:
 case FORM_CDROM_BOOT_ID:
@@ -1424,14 +1458,10 @@ LegacyBootMaintUiLibConstructor (
   NULL
   );
 ASSERT (LegacyBootOptionData->HiiHandle != NULL);
 
 mLegacyBootOptionPrivate = LegacyBootOptionData;
-
-GetLegacyOptions ();
-
-GetLegacyOptionsOrder();
   }
 
   return EFI_SUCCESS;
 }
 
-- 
1.9.5.msysgit.1

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

[edk2] [patch 0/2] MdeModulePkg/Ui: Remove the implicit dependency for libraries

[Dandan Bi]

Patch 1 remove the implicit dependency between BootMaintenanceManagerUiLib 
and LeagcyBootMaintUiLib.
Patch 2 remove the implicit dependency between LegacyBootMaintUiLib 
and LegacyBootManagerLib.

Cc: Liming Gao 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 

Dandan Bi (2):
  MdeModulePkg/BootMaintUiLib: Update menus when open BMM form
  IntelFrameworkModulePkg/LegacyUi: Get legacy options when open legacy
form

 .../LegacyBootMaintUiLib/LegacyBootMaintUi.c   | 42 ++
 .../BootMaintenanceManagerUiLib/BootMaintenance.c  | 37 +++
 .../BootMaintenanceManager.vfr | 12 ++-
 3 files changed, 77 insertions(+), 14 deletions(-)

-- 
1.9.5.msysgit.1

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

Re: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Centralize TlsCaCertificate name and guid

[Samer El Haj Mahmoud]

Reviewed-by: Samer El-Haj-Mahmoud 



-Original Message-
From: Wu, Jiaxin [jiaxin...@intel.com]
Received: Monday, 04 Jul 2016, 9:45PM
To: Palmer, Thomas [thomas.pal...@hpe.com]; Wu, Jiaxin [jiaxin...@intel.com]; 
edk2-devel@lists.01.org [edk2-devel@lists.01.org]
CC: Ye, Ting [ting...@intel.com]; Fu, Siyuan [siyuan...@intel.com]
Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Centralize 
TlsCaCertificate name and guid

It should be "[edk2-staging/HTTPS-TLS][PATCH]".

Sorry for incorrect subject-prefix.

Jiaxin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiaxin Wu
> Sent: Tuesday, July 5, 2016 9:41 AM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan 
> Subject: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Centralize
> TlsCaCertificate name and guid
>
> This patch is used to centralize TlsCaCertificate name and guid to
> TlsAuthentication.h
>
> Cc: Palmer Thomas 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu 
> ---
>  NetworkPkg/HttpDxe/HttpDriver.h  |  2 ++
>  NetworkPkg/HttpDxe/HttpDxe.inf   |  4 
>  NetworkPkg/HttpDxe/HttpsSupport.c|  7 ++
>  NetworkPkg/HttpDxe/HttpsSupport.h| 10 
>  NetworkPkg/Include/Guid/TlsAuthentication.h  | 29
> 
>  NetworkPkg/NetworkPkg.dec|  5 +++-
>  NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf |  1 +
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c  | 14 +---
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h  | 12 ++
>  9 files changed, 50 insertions(+), 34 deletions(-)  create mode 100644
> NetworkPkg/Include/Guid/TlsAuthentication.h
>
> diff --git a/NetworkPkg/HttpDxe/HttpDriver.h
> b/NetworkPkg/HttpDxe/HttpDriver.h index 3c30c12..73c211a 100644
> --- a/NetworkPkg/HttpDxe/HttpDriver.h
> +++ b/NetworkPkg/HttpDxe/HttpDriver.h
> @@ -58,10 +58,12 @@
>  //
>  // Produced Protocols
>  //
>  #include 
>
> +#include 
> +
>  //
>  // Driver Version
>  //
>  #define HTTP_DRIVER_VERSION 0xa
>
> diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf
> b/NetworkPkg/HttpDxe/HttpDxe.inf index a228c3d..1118181 100644
> --- a/NetworkPkg/HttpDxe/HttpDxe.inf
> +++ b/NetworkPkg/HttpDxe/HttpDxe.inf
> @@ -24,10 +24,11 @@
>MODULE_UNI_FILE   = HttpDxe.uni
>
>  [Packages]
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
> +  NetworkPkg/NetworkPkg.dec
>
>  [Sources]
>ComponentName.h
>ComponentName.c
>HttpDns.h
> @@ -69,7 +70,10 @@
>gEfiIp6ConfigProtocolGuid## SOMETIMES_CONSUMES
>gEfiTlsServiceBindingProtocolGuid## SOMETIMES_CONSUMES
>gEfiTlsProtocolGuid  ## SOMETIMES_CONSUMES
>gEfiTlsConfigurationProtocolGuid ## SOMETIMES_CONSUMES
>
> +[Guids]
> +  gEfiTlsCaCertificateGuid ## CONSUMES  ## GUID
> +
>  [UserExtensions.TianoCore."ExtraFiles"]
>HttpDxeExtra.uni
> \ No newline at end of file
> diff --git a/NetworkPkg/HttpDxe/HttpsSupport.c
> b/NetworkPkg/HttpDxe/HttpsSupport.c
> index 09aaa46..36f658c 100644
> --- a/NetworkPkg/HttpDxe/HttpsSupport.c
> +++ b/NetworkPkg/HttpDxe/HttpsSupport.c
> @@ -12,12 +12,10 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
>
>  **/
>
>  #include "HttpDriver.h"
>
> -EFI_GUID mEfiTlsCaCertificateGuid = EFI_TLS_CA_CERTIFICATE_GUID;
> -
>  /**
>Returns the first occurrence of a Null-terminated ASCII sub-string in a 
> Null-
> terminated
>ASCII string and ignore case during the search process.
>
>This function scans the contents of the ASCII string specified by String 
> @@ -
> 395,11 +393,11 @@ TlsConfigCertificate (
>// Try to read the TlsCaCertificate variable.
>//
>CACertSize = 0;
>Status  = gRT->GetVariable (
> EFI_TLS_CA_CERTIFICATE_VARIABLE,
> -   ,
> +   ,
> NULL,
> ,
> NULL
> );
>
> @@ -412,11 +410,11 @@ TlsConfigCertificate (
>return EFI_OUT_OF_RESOURCES;
>  }
>
>  Status = gRT->GetVariable (
>  EFI_TLS_CA_CERTIFICATE_VARIABLE,
> -,
> +,
>  NULL,
>  ,
>  CACert
>  );
>  if (EFI_ERROR (Status)) {
> @@ -453,11 +451,10 @@ TlsConfigCertificate (
>}
>
>Cert = (EFI_SIGNATURE_DATA *) ((UINT8 *) Cert + CertList-
> >SignatureSize);
>  }
>
> -
>  ItemDataSize -= CertList->SignatureListSize;
>  CertList = (EFI_SIGNATURE_LIST *) ((UINT8 *) CertList + CertList-
> >SignatureListSize);
>}
>
>return 

[edk2] [PATCH] Vlv2TbltDevicePkg: Change SEC to new version: 1.0.3.1164.

[Guo, Mang]

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Guo Mang 
---
 Vlv2TbltDevicePkg/Stitch/MNW2_Stitch_Config.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Vlv2TbltDevicePkg/Stitch/MNW2_Stitch_Config.txt 
b/Vlv2TbltDevicePkg/Stitch/MNW2_Stitch_Config.txt
index 5a0a2b4..68f530f 100644
--- a/Vlv2TbltDevicePkg/Stitch/MNW2_Stitch_Config.txt
+++ b/Vlv2TbltDevicePkg/Stitch/MNW2_Stitch_Config.txt
@@ -1,5 +1,5 @@
 #
-# Copyright (c)  1999  - 2014, Intel Corporation. All rights reserved
+# Copyright (c)  1999  - 2016, Intel Corporation. All rights reserved
 #
 # This program and the accompanying materials are licensed and made available 
under
 # the terms and conditions of the BSD License that accompanies this 
distribution.
@@ -12,5 +12,5 @@
 #
 
 HEADER=IFWI_HEADER
-SEC_VERSION=1.0.2.1060v5
+SEC_VERSION=1.0.3.1164
 
-- 
2.8.1.windows.1

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

Re: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Centralize TlsCaCertificate name and guid

[Wu, Jiaxin]

It should be "[edk2-staging/HTTPS-TLS][PATCH]".

Sorry for incorrect subject-prefix.

Jiaxin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiaxin Wu
> Sent: Tuesday, July 5, 2016 9:41 AM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan 
> Subject: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Centralize
> TlsCaCertificate name and guid
> 
> This patch is used to centralize TlsCaCertificate name and guid to
> TlsAuthentication.h
> 
> Cc: Palmer Thomas 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu 
> ---
>  NetworkPkg/HttpDxe/HttpDriver.h  |  2 ++
>  NetworkPkg/HttpDxe/HttpDxe.inf   |  4 
>  NetworkPkg/HttpDxe/HttpsSupport.c|  7 ++
>  NetworkPkg/HttpDxe/HttpsSupport.h| 10 
>  NetworkPkg/Include/Guid/TlsAuthentication.h  | 29
> 
>  NetworkPkg/NetworkPkg.dec|  5 +++-
>  NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf |  1 +
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c  | 14 +---
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h  | 12 ++
>  9 files changed, 50 insertions(+), 34 deletions(-)  create mode 100644
> NetworkPkg/Include/Guid/TlsAuthentication.h
> 
> diff --git a/NetworkPkg/HttpDxe/HttpDriver.h
> b/NetworkPkg/HttpDxe/HttpDriver.h index 3c30c12..73c211a 100644
> --- a/NetworkPkg/HttpDxe/HttpDriver.h
> +++ b/NetworkPkg/HttpDxe/HttpDriver.h
> @@ -58,10 +58,12 @@
>  //
>  // Produced Protocols
>  //
>  #include 
> 
> +#include 
> +
>  //
>  // Driver Version
>  //
>  #define HTTP_DRIVER_VERSION 0xa
> 
> diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf
> b/NetworkPkg/HttpDxe/HttpDxe.inf index a228c3d..1118181 100644
> --- a/NetworkPkg/HttpDxe/HttpDxe.inf
> +++ b/NetworkPkg/HttpDxe/HttpDxe.inf
> @@ -24,10 +24,11 @@
>MODULE_UNI_FILE   = HttpDxe.uni
> 
>  [Packages]
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
> +  NetworkPkg/NetworkPkg.dec
> 
>  [Sources]
>ComponentName.h
>ComponentName.c
>HttpDns.h
> @@ -69,7 +70,10 @@
>gEfiIp6ConfigProtocolGuid## SOMETIMES_CONSUMES
>gEfiTlsServiceBindingProtocolGuid## SOMETIMES_CONSUMES
>gEfiTlsProtocolGuid  ## SOMETIMES_CONSUMES
>gEfiTlsConfigurationProtocolGuid ## SOMETIMES_CONSUMES
> 
> +[Guids]
> +  gEfiTlsCaCertificateGuid ## CONSUMES  ## GUID
> +
>  [UserExtensions.TianoCore."ExtraFiles"]
>HttpDxeExtra.uni
> \ No newline at end of file
> diff --git a/NetworkPkg/HttpDxe/HttpsSupport.c
> b/NetworkPkg/HttpDxe/HttpsSupport.c
> index 09aaa46..36f658c 100644
> --- a/NetworkPkg/HttpDxe/HttpsSupport.c
> +++ b/NetworkPkg/HttpDxe/HttpsSupport.c
> @@ -12,12 +12,10 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
> 
>  **/
> 
>  #include "HttpDriver.h"
> 
> -EFI_GUID mEfiTlsCaCertificateGuid = EFI_TLS_CA_CERTIFICATE_GUID;
> -
>  /**
>Returns the first occurrence of a Null-terminated ASCII sub-string in a 
> Null-
> terminated
>ASCII string and ignore case during the search process.
> 
>This function scans the contents of the ASCII string specified by String 
> @@ -
> 395,11 +393,11 @@ TlsConfigCertificate (
>// Try to read the TlsCaCertificate variable.
>//
>CACertSize = 0;
>Status  = gRT->GetVariable (
> EFI_TLS_CA_CERTIFICATE_VARIABLE,
> -   ,
> +   ,
> NULL,
> ,
> NULL
> );
> 
> @@ -412,11 +410,11 @@ TlsConfigCertificate (
>return EFI_OUT_OF_RESOURCES;
>  }
> 
>  Status = gRT->GetVariable (
>  EFI_TLS_CA_CERTIFICATE_VARIABLE,
> -,
> +,
>  NULL,
>  ,
>  CACert
>  );
>  if (EFI_ERROR (Status)) {
> @@ -453,11 +451,10 @@ TlsConfigCertificate (
>}
> 
>Cert = (EFI_SIGNATURE_DATA *) ((UINT8 *) Cert + CertList-
> >SignatureSize);
>  }
> 
> -
>  ItemDataSize -= CertList->SignatureListSize;
>  CertList = (EFI_SIGNATURE_LIST *) ((UINT8 *) CertList + CertList-
> >SignatureListSize);
>}
> 
>return Status;
> diff --git a/NetworkPkg/HttpDxe/HttpsSupport.h
> b/NetworkPkg/HttpDxe/HttpsSupport.h
> index 682a6b6..05b6e69 100644
> --- a/NetworkPkg/HttpDxe/HttpsSupport.h
> +++ b/NetworkPkg/HttpDxe/HttpsSupport.h
> @@ -20,20 +20,10 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
>  #define HTTPS_DEFAULT_PORT   443
> 
>  #define HTTPS_FLAG   "https"
> 
>  //
> -// Private variable for CA 

[edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Centralize TlsCaCertificate name and guid

[Jiaxin Wu]

This patch is used to centralize TlsCaCertificate name and guid
to TlsAuthentication.h

Cc: Palmer Thomas 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 NetworkPkg/HttpDxe/HttpDriver.h  |  2 ++
 NetworkPkg/HttpDxe/HttpDxe.inf   |  4 
 NetworkPkg/HttpDxe/HttpsSupport.c|  7 ++
 NetworkPkg/HttpDxe/HttpsSupport.h| 10 
 NetworkPkg/Include/Guid/TlsAuthentication.h  | 29 
 NetworkPkg/NetworkPkg.dec|  5 +++-
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf |  1 +
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c  | 14 +---
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h  | 12 ++
 9 files changed, 50 insertions(+), 34 deletions(-)
 create mode 100644 NetworkPkg/Include/Guid/TlsAuthentication.h

diff --git a/NetworkPkg/HttpDxe/HttpDriver.h b/NetworkPkg/HttpDxe/HttpDriver.h
index 3c30c12..73c211a 100644
--- a/NetworkPkg/HttpDxe/HttpDriver.h
+++ b/NetworkPkg/HttpDxe/HttpDriver.h
@@ -58,10 +58,12 @@
 //
 // Produced Protocols
 //
 #include 
 
+#include 
+
 //
 // Driver Version
 //
 #define HTTP_DRIVER_VERSION 0xa
 
diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf b/NetworkPkg/HttpDxe/HttpDxe.inf
index a228c3d..1118181 100644
--- a/NetworkPkg/HttpDxe/HttpDxe.inf
+++ b/NetworkPkg/HttpDxe/HttpDxe.inf
@@ -24,10 +24,11 @@
   MODULE_UNI_FILE   = HttpDxe.uni
 
 [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
+  NetworkPkg/NetworkPkg.dec
 
 [Sources]
   ComponentName.h
   ComponentName.c
   HttpDns.h
@@ -69,7 +70,10 @@
   gEfiIp6ConfigProtocolGuid## SOMETIMES_CONSUMES
   gEfiTlsServiceBindingProtocolGuid## SOMETIMES_CONSUMES
   gEfiTlsProtocolGuid  ## SOMETIMES_CONSUMES
   gEfiTlsConfigurationProtocolGuid ## SOMETIMES_CONSUMES
 
+[Guids]
+  gEfiTlsCaCertificateGuid ## CONSUMES  ## GUID
+
 [UserExtensions.TianoCore."ExtraFiles"]
   HttpDxeExtra.uni
\ No newline at end of file
diff --git a/NetworkPkg/HttpDxe/HttpsSupport.c 
b/NetworkPkg/HttpDxe/HttpsSupport.c
index 09aaa46..36f658c 100644
--- a/NetworkPkg/HttpDxe/HttpsSupport.c
+++ b/NetworkPkg/HttpDxe/HttpsSupport.c
@@ -12,12 +12,10 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 **/
 
 #include "HttpDriver.h"
 
-EFI_GUID mEfiTlsCaCertificateGuid = EFI_TLS_CA_CERTIFICATE_GUID;
-
 /**
   Returns the first occurrence of a Null-terminated ASCII sub-string in a 
Null-terminated 
   ASCII string and ignore case during the search process.
 
   This function scans the contents of the ASCII string specified by String
@@ -395,11 +393,11 @@ TlsConfigCertificate (
   // Try to read the TlsCaCertificate variable.
   //
   CACertSize = 0;
   Status  = gRT->GetVariable (
EFI_TLS_CA_CERTIFICATE_VARIABLE,
-   ,
+   ,
NULL,
,
NULL
);
 
@@ -412,11 +410,11 @@ TlsConfigCertificate (
   return EFI_OUT_OF_RESOURCES;
 }
 
 Status = gRT->GetVariable (
 EFI_TLS_CA_CERTIFICATE_VARIABLE,
-,
+,
 NULL,
 ,
 CACert
 );
 if (EFI_ERROR (Status)) {
@@ -453,11 +451,10 @@ TlsConfigCertificate (
   }
   
   Cert = (EFI_SIGNATURE_DATA *) ((UINT8 *) Cert + CertList->SignatureSize);
 }
 
-
 ItemDataSize -= CertList->SignatureListSize;
 CertList = (EFI_SIGNATURE_LIST *) ((UINT8 *) CertList + 
CertList->SignatureListSize);
   }
   
   return Status;
diff --git a/NetworkPkg/HttpDxe/HttpsSupport.h 
b/NetworkPkg/HttpDxe/HttpsSupport.h
index 682a6b6..05b6e69 100644
--- a/NetworkPkg/HttpDxe/HttpsSupport.h
+++ b/NetworkPkg/HttpDxe/HttpsSupport.h
@@ -20,20 +20,10 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #define HTTPS_DEFAULT_PORT   443
 
 #define HTTPS_FLAG   "https"
 
 //
-// Private variable for CA Certificate configuration
-//
-#define EFI_TLS_CA_CERTIFICATE_GUID \
-  { \
-0xfd2340D0, 0x3dab, 0x4349, { 0xa6, 0xc7, 0x3b, 0x4f, 0x12, 0xb4, 0x8e, 
0xae } \
-  }
-
-#define EFI_TLS_CA_CERTIFICATE_VARIABLE  L"TlsCaCertificate"
-
-//
 // TLS Version
 //
 #define TLS10_PROTOCOL_VERSION_MAJOR  0x03
 #define TLS10_PROTOCOL_VERSION_MINOR  0x01
 #define TLS11_PROTOCOL_VERSION_MAJOR  0x03
diff --git a/NetworkPkg/Include/Guid/TlsAuthentication.h 
b/NetworkPkg/Include/Guid/TlsAuthentication.h
new file mode 100644
index 000..2e800dc
--- /dev/null
+++ b/NetworkPkg/Include/Guid/TlsAuthentication.h
@@ -0,0 +1,29 @@
+/** @file
+  This file defines TlsCaCertificate variable.
+  
+Copyright (c) 2016, Intel 

Re: [edk2] Memory Profile question.

[Yao, Jiewen]

Comment inline:

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
Fish
Sent: Thursday, June 30, 2016 10:17 PM
To: Yao, Jiewen 
Cc: edk2-devel 
Subject: Re: [edk2] Memory Profile question.


> On Jun 30, 2016, at 12:05 AM, Yao, Jiewen 
> > wrote:
>
> Yes, Andrew. You are right.
> We encounter similar problem, but it seems MSVC _ReturnAddress() does not 
> take parameter.
>  #define RETURN_ADDRESS(L) ((L == 0) ? _ReturnAddress() : (VOID *) 0)
>

For GCC family you can potentially get more info.

#define RETURN_ADDRESS(L) __builtin_return_address (L)

> So we enhanced MemoryAllocationLib to support add record from 
> MemoryAllocationLib.
>

Does that mean the logging gets moved to the library? Or does the library log 
just update the log in the DXE Core?
[Jiewen] DxeCore still logs gBS->AllocatePool.
The memory allocation library adds a profile record to DxeCore maintained 
profile database.


> The final log is like this:
>
>  CountSize   RVA  Action
> ==  == == 
> ()
> 0x006B  0x0001D31F <== 0xAE7C (gBS->AllocatePool) 
> (InternalAllocatePool() - 
> c:\home\edk-ii\mdemodulepkg\library\smmmemoryallocationlibprofile\memoryallocationlib.c:567)
> 0x0001  0x0020 <== 0xBCB8 (Lib:AllocatePool) 
> (SmmMemLibConstructor() - 
> c:\home\edk-ii\mdepkg\library\smmmemlib\smmmemlib.c:309)
> 0x0001  0x0070 <== 0x7F2D 
> (Lib:AllocateZeroRuntimePool) (VariableCommonInitialize() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:4055)
> 0x0001  0xC000 <== 0x715A 
> (Lib:AllocateZeroRuntimePool) (InitNonVolatileVariableStore() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:3692)
> 0x0001  0x00010400 <== 0x8121 
> (Lib:AllocateRuntimePool) (VariableCommonInitialize() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:4113)
> 0x0001  0x0404 <== 0x2957 (gBS->AllocatePool) 
> (VariableServiceInitialize() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variablesmm.c:956)
> 0x0007  0x01CE <== 0xC42E 
> (Lib:AllocateZeroRuntimePool) (VarCheckLibVariablePropertySet() - 
> c:\home\edk-ii\mdemodulepkg\library\varchecklib\varchecklib.c:521)
> 0x0001  0x0020 <== 0xC071 
> (Lib:ReallocateRuntimePool) (VarCheckAddTableEntry() - 
> c:\home\edk-ii\mdemodulepkg\library\varchecklib\varchecklib.c:228)
> 0x0001  0x0030 <== 0x2E08 (Lib:AllocateZeroPool) 
> (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:196)
> 0x0001  0x0044 <== 0x2E68 (Lib:AllocateZeroPool) 
> (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:200)
> 0x002C  0x0840 <== 0x2F98 (Lib:AllocateZeroPool) 
> (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:232)
> 0x002C  0x037C <== 0x2FF6 (Lib:AllocateZeroPool) 
> (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:236)
> 0x0001  0x000D <== 0x4DC9 
> (Lib:AllocateCopyRuntimePool) (AutoUpdateLangVariable() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1960)
> 0x0001  0x0012 <== 0x4CC4 
> (Lib:AllocateCopyRuntimePool) (AutoUpdateLangVariable() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1930)
> 0x0001  0x0012 <== 0x4D28 
> (Lib:AllocateRuntimePool) (AutoUpdateLangVariable() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1940)
>
>

Are the address ranges allocated tracked? Is it possible to look up an address 
and figure out where it got allocated?
[Jiewen] I am not clear on the question. "Address" means the memory allocated? 
Or the RIP doing the allocation?
Also I do not understand what "ranges" means here.

Currently, DxeCore records all loaded image - so DxeCore knows the RIP of each 
allocation action.
So DxeCore records the RIP, as well as allocated buffer address.

The above log is summary. For detail, you may also see each allocation action 
in final log, like below:
=
MEMORY_PROFILE_ALLOC_INFO (0x52)
  Signature - 0x4941504D
  Length- 0x0030
  Revision  - 0x0001
  CallerAddress - 0x04B6A41B (Offset: 0x0001141B)
  SequenceId- 0x0033
  Action- 0x0003 (gBS->AllocatePool)
  MemoryType- 0x0004 

Re: [edk2] [PATCH] BaseTools MemoryProfileSymbolGen.py: Handle 64bits rva from "nm -l xxx.dll"

[Yao, Jiewen]

Reviewed by: jiewen@intel.com

> -Original Message-
> From: Zeng, Star
> Sent: Monday, July 4, 2016 6:42 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Yao, Jiewen ;
> Gao, Liming ; Zhu, Yonghong
> 
> Subject: [PATCH] BaseTools MemoryProfileSymbolGen.py: Handle 64bits rva
> from "nm -l xxx.dll"
> 
> Current MemoryProfileSymbolGen.py assumes the rva is 32bits,
> the patch is to remove the restriction to match any lengths
> of rva.
> 
> Cc: Jiewen Yao 
> Cc: Liming Gao 
> Cc: Yonghong Zhu 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
>  BaseTools/Scripts/MemoryProfileSymbolGen.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/BaseTools/Scripts/MemoryProfileSymbolGen.py
> b/BaseTools/Scripts/MemoryProfileSymbolGen.py
> index a9790d8883c8..5709ad4641cb 100644
> --- a/BaseTools/Scripts/MemoryProfileSymbolGen.py
> +++ b/BaseTools/Scripts/MemoryProfileSymbolGen.py
> @@ -19,7 +19,7 @@ import re
>  import sys
>  from optparse import OptionParser
> 
> -versionNumber = "1.0"
> +versionNumber = "1.1"
>  __copyright__ = "Copyright (c) 2016, Intel Corporation. All rights reserved."
> 
>  class Symbols:
> @@ -72,7 +72,7 @@ class Symbols:
>  linefile.close()
> 
>  # 000113ca T AllocatePool
>   c:\home\edk-ii\MdePkg\Library\UefiMemoryAllocationLib\MemoryAllo
> cationLib.c:399
> -patchLineFileMatchString =
> "([0-9a-fA-F]{8})\s+[T|D|t|d]\s+(\w+)\s*((?:[a-zA-Z]:)?[\w+\-./_a-zA-Z0-9\\\
> \]*):?([0-9]*)"
> +patchLineFileMatchString =
> "([0-9a-fA-F]*)\s+[T|D|t|d]\s+(\w+)\s*((?:[a-zA-Z]:)?[\w+\-./_a-zA-Z0-9]
> *):?([0-9]*)"
> 
>  for reportLine in reportLines:
>  #print "check - " + reportLine
> --
> 2.7.0.windows.1

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

Re: [edk2] [PATCH] MdeModulePkg MemoryProfileInfo: Handle "/" character in the PDB path

[Yao, Jiewen]

Reviewed by: jiewen@intel.com

> -Original Message-
> From: Zeng, Star
> Sent: Monday, July 4, 2016 6:42 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Yao, Jiewen 
> Subject: [PATCH] MdeModulePkg MemoryProfileInfo: Handle "/" character in
> the PDB path
> 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
>  MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c | 2
> +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git
> a/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
> b/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
> index 69c6cf166daa..68e7ed7326f0 100644
> --- a/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
> +++ b/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
> @@ -205,7 +205,7 @@ GetShortPdbFileName (
>  StartIndex = 0;
>  for (EndIndex = 0; PdbFileName[EndIndex] != 0; EndIndex++);
>  for (IndexPdb = 0; PdbFileName[IndexPdb] != 0; IndexPdb++) {
> -  if (PdbFileName[IndexPdb] == '\\') {
> +  if ((PdbFileName[IndexPdb] == '\\') || (PdbFileName[IndexPdb] ==
> '/')) {
>  StartIndex = IndexPdb + 1;
>}
> 
> --
> 2.7.0.windows.1

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

Re: [edk2] Memory Profile question.

[Yao, Jiewen]

Yes, FreePool is also handled.
The current algorithm is: We insert a record when AllocatePool happens. We 
search and delete the record when FreePool happens.

So the final memory profile record means: the memory allocated, but not freed.

Thank you
Yao Jiewen

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ramesh R.
Sent: Monday, July 4, 2016 8:07 PM
To: Andrew Fish ; Yao, Jiewen 
Cc: edk2-devel 
Subject: Re: [edk2] Memory Profile question.

Is there any way we can track the FreePool also ? In the end is it possible to 
identify which are all the memory area allocated, but no freed by system BIOS ?

Thanks,
Ramesh

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
Fish
Sent: 30 June 2016 19:47
To: Yao, Jiewen
Cc: edk2-devel
Subject: Re: [edk2] Memory Profile question.


> On Jun 30, 2016, at 12:05 AM, Yao, Jiewen 
> > wrote:
>
> Yes, Andrew. You are right.
> We encounter similar problem, but it seems MSVC _ReturnAddress() does not 
> take parameter.
>  #define RETURN_ADDRESS(L) ((L == 0) ? _ReturnAddress() : (VOID *) 0)
>

For GCC family you can potentially get more info.

#define RETURN_ADDRESS(L) __builtin_return_address (L)

> So we enhanced MemoryAllocationLib to support add record from 
> MemoryAllocationLib.
>

Does that mean the logging gets moved to the library? Or does the library log 
just update the log in the DXE Core?

> The final log is like this:
>
>  CountSize   RVA  Action
> ==  == == 
> ()
> 0x006B  0x0001D31F <== 0xAE7C
> (gBS->AllocatePool) (InternalAllocatePool() -
> c:\home\edk-ii\mdemodulepkg\library\smmmemoryallocationlibprofile\memo
> ryallocationlib.c:567)
> 0x0001  0x0020 <== 0xBCB8
> (Lib:AllocatePool) (SmmMemLibConstructor() -
> c:\home\edk-ii\mdepkg\library\smmmemlib\smmmemlib.c:309)
> 0x0001  0x0070 <== 0x7F2D
> (Lib:AllocateZeroRuntimePool) (VariableCommonInitialize() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:4
> 055)
> 0x0001  0xC000 <== 0x715A
> (Lib:AllocateZeroRuntimePool) (InitNonVolatileVariableStore() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:3
> 692)
> 0x0001  0x00010400 <== 0x8121
> (Lib:AllocateRuntimePool) (VariableCommonInitialize() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:4
> 113)
> 0x0001  0x0404 <== 0x2957
> (gBS->AllocatePool) (VariableServiceInitialize() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variablesmm.
> c:956)
> 0x0007  0x01CE <== 0xC42E
> (Lib:AllocateZeroRuntimePool) (VarCheckLibVariablePropertySet() -
> c:\home\edk-ii\mdemodulepkg\library\varchecklib\varchecklib.c:521)
> 0x0001  0x0020 <== 0xC071
> (Lib:ReallocateRuntimePool) (VarCheckAddTableEntry() -
> c:\home\edk-ii\mdemodulepkg\library\varchecklib\varchecklib.c:228)
> 0x0001  0x0030 <== 0x2E08
> (Lib:AllocateZeroPool) (UpdateVariableInfo() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 96)
> 0x0001  0x0044 <== 0x2E68
> (Lib:AllocateZeroPool) (UpdateVariableInfo() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:2
> 00) 0x002C  0x0840 <== 0x2F98
> (Lib:AllocateZeroPool) (UpdateVariableInfo() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:2
> 32) 0x002C  0x037C <== 0x2FF6
> (Lib:AllocateZeroPool) (UpdateVariableInfo() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:2
> 36)
> 0x0001  0x000D <== 0x4DC9
> (Lib:AllocateCopyRuntimePool) (AutoUpdateLangVariable() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 960)
> 0x0001  0x0012 <== 0x4CC4
> (Lib:AllocateCopyRuntimePool) (AutoUpdateLangVariable() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 930)
> 0x0001  0x0012 <== 0x4D28
> (Lib:AllocateRuntimePool) (AutoUpdateLangVariable() -
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 940)
>
>

Are the address ranges allocated tracked? Is it possible to look up an address 
and figure out where it got allocated?

Any plans to add logging for stalls? You can dump events with a debugger 
script, so that is not as important.

Thanks,

Andrew Fish

>
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
>> Of Andrew Fish
>> Sent: Thursday, June 

Re: [edk2] StdLib usage for drivers?

[Daryl McDaniel]

Marvin,

 

Personally, I would be happy for any contributions you could make for StdLib.

The only remaining Shell dependencies should be:

* File system support.

* One or two functions in PosixLib

 

The next big area is breaking up the MainData structure and moving its members 
into the sub-libraries that they are relevant to.

 

Once that is done, I had planned on trying to break as many of the library’s 
interdependencies as possible.

 

As long as StdLib continues to pass the ISO C95 compliance tests, and gets 
smaller instead of larger, just about anything is fair game.

I had pretty much decided to abandon using the FreeBSD / NetBSD code since it 
is not the best suited for the EDK II environment.

 

As Michael surmised, I’ve been traveling a lot and too busy lately to devote as 
much attention to StdLib as I wish I could.

 

Please remember for your contributions; compatibility with both GCC and 
Microsoft compilers and both IA32 and X64 is required.  If you can also retain 
or provide support for ARM then that would be great.

 

I can’t speak for Jaben, so I will have to wait for his response to determine 
his stance on the issue.

 

I’m willing to answer any questions about AppPkg or StdLib that I can.

 

Thank you for your offer.

Daryl McDaniel

 

 

From: Marvin Häuser [mailto:marvin.haeu...@outlook.com] 
Sent: Monday, July 04, 2016 11:18 AM
To: edk2-devel@lists.01.org
Cc: Michael Zimmermann ; edk2-li...@mc2research.org; 
Carsey, Jaben 
Subject: RE: [edk2] StdLib usage for drivers?

 

Daryl, Jaben,

 

As you are the package maintainers of StdLib, could you please comment on the 
situation?

If modifications to have StdLib working for drivers are welcome, I would offer 
my help in cleaning up the existing stuff and/or write my own patches, though 
of course there is little point if there is no reaction from the reviewers.

If it is of any interest, I want to write a shim library for Capstone and would 
prefer not to have three copies of Std functions in my tree (StdLib, CryptoPkg 
(SSL) and Capstone), but rather an improved StdLib that works for all.

 

Thanks to those who have offered alternative solutions, but I prefer to keep it 
‚clean‘ and have the libraries shipping with EDK2 work. :)

 

Regards,

Marvin.

 

From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com] 
Sent: Thursday, June 23, 2016 5:32 AM
To: Marvin Häuser  >
Cc: edk2-devel@lists.01.org  ; af...@apple.com 
 
Subject: Re: [edk2] StdLib usage for drivers?

 

well for the patch to go upstream it would have to get improved a lot.

I've tried to implement this in a way that doesn't need a different dsc but the 
problem is that ShellLib's constructor ASSERT's if it can't find the shell 
protocol and removing that would probably be against the spec's.

 

Also it appears that the StdLib maintainers are kinda busy because most of the 
StdLib patches I've sent to this mailing list didn't get reviewed.

 

Thanks

Michael

 

On Wed, Jun 22, 2016 at 10:37 PM, Marvin Häuser  > wrote:

Hey Michael,

Thank you for your input! This looks interesting.
Maybe it would be a good idea to provide the libraries that depend on Shell (in 
master) with functions that call ASSERT (FALSE); for drivers? I do not need 
file I/O, so I think your modifications might work out well for me. Would be 
very nice of course if such changes found their way upstream. :)

And thank you very much for your comment as well, Andrew! It makes sense that 
StdLib is primarily targeted at porting console applications to UEFI Shell.

Regards,
Marvin.

From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com 
 ]
Sent: Wednesday, June 22, 2016 10:28 PM
To: Marvin H?user  >
Cc: edk2-devel@lists.01.org  
Subject: Re: [edk2] StdLib usage for drivers?

In my fork of edk2 I've added support for using StdLib without the Shell.
It's quite hacky(setenv/getenv are stubs, no File IO and maybe other things 
hidden by linker GC and me not using all features).

But depending on which StdLib features you need this can work pretty good.

here's the commit that does the magic:
https://github.com/efidroid/edk2/commit/bf7a296718486bafaf774ea8bcf187c162c3c167

and this is how you convert a Shell project to a NonShell one:
https://github.com/efidroid/uefi_apps_EFIDroidUi/commit/23f0fa08108b8f852564fae733c6a7bce62e2070

as you can see it works by using StdLib with different libraries/cflags so you 
have to compile your driver separately if there are other modules which need 
the normal StdLib.

Thanks
Michael

On Wed, Jun 22, 2016 at 9:38 PM, Marvin H?user 

Re: [edk2] StdLib usage for drivers?

[Marvin Häuser]

Daryl, Jaben,

As you are the package maintainers of StdLib, could you please comment on the 
situation?
If modifications to have StdLib working for drivers are welcome, I would offer 
my help in cleaning up the existing stuff and/or write my own patches, though 
of course there is little point if there is no reaction from the reviewers.
If it is of any interest, I want to write a shim library for Capstone and would 
prefer not to have three copies of Std functions in my tree (StdLib, CryptoPkg 
(SSL) and Capstone), but rather an improved StdLib that works for all.

Thanks to those who have offered alternative solutions, but I prefer to keep it 
‚clean‘ and have the libraries shipping with EDK2 work. :)

Regards,
Marvin.

From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com]
Sent: Thursday, June 23, 2016 5:32 AM
To: Marvin Häuser 
Cc: edk2-devel@lists.01.org; af...@apple.com
Subject: Re: [edk2] StdLib usage for drivers?

well for the patch to go upstream it would have to get improved a lot.
I've tried to implement this in a way that doesn't need a different dsc but the 
problem is that ShellLib's constructor ASSERT's if it can't find the shell 
protocol and removing that would probably be against the spec's.

Also it appears that the StdLib maintainers are kinda busy because most of the 
StdLib patches I've sent to this mailing list didn't get reviewed.

Thanks
Michael

On Wed, Jun 22, 2016 at 10:37 PM, Marvin Häuser 
> wrote:
Hey Michael,

Thank you for your input! This looks interesting.
Maybe it would be a good idea to provide the libraries that depend on Shell (in 
master) with functions that call ASSERT (FALSE); for drivers? I do not need 
file I/O, so I think your modifications might work out well for me. Would be 
very nice of course if such changes found their way upstream. :)

And thank you very much for your comment as well, Andrew! It makes sense that 
StdLib is primarily targeted at porting console applications to UEFI Shell.

Regards,
Marvin.

From: Michael Zimmermann 
[mailto:sigmaepsilo...@gmail.com]
Sent: Wednesday, June 22, 2016 10:28 PM
To: Marvin H?user 
>
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] StdLib usage for drivers?

In my fork of edk2 I've added support for using StdLib without the Shell.
It's quite hacky(setenv/getenv are stubs, no File IO and maybe other things 
hidden by linker GC and me not using all features).

But depending on which StdLib features you need this can work pretty good.

here's the commit that does the magic:
https://github.com/efidroid/edk2/commit/bf7a296718486bafaf774ea8bcf187c162c3c167

and this is how you convert a Shell project to a NonShell one:
https://github.com/efidroid/uefi_apps_EFIDroidUi/commit/23f0fa08108b8f852564fae733c6a7bce62e2070

as you can see it works by using StdLib with different libraries/cflags so you 
have to compile your driver separately if there are other modules which need 
the normal StdLib.

Thanks
Michael

On Wed, Jun 22, 2016 at 9:38 PM, Marvin H?user 
>>
 wrote:
Dear EDK2 developers,

For an experimental project, I'm currently attempting to write a library 
wrapper for the disassembler library 'Capstone' in a similar manner to 
CryptoPkg's OpensslLib. As most C libraries, it also depends on the standard 
headers, which are not provided by 'stock' EDK2. My first guess has been to use 
StdLib, though its description states:
'Due to the execution environment built by the StdLib component, execution as a 
UEFI driver can cause system stability issues.'

Inspecting OpensslLib I discovered that CryptoPkg deploys its own include files 
for StdLib. Though, from your experience, what are the issues with using 
StdLibPkg with DXE/UEFI drivers? It might be nice to reduce duplicate code, 
though I honestly don't know anything about StdLibPkg and its implementation 
and would be thankful for some insight on that manner.

Thank you in advance for your time!

Regards,
Marvin.
___
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: [edk2] [PATCH v2 0/4] ArmPkg: refactor MMU handling routines into separate ArmMmuLib

[Leif Lindholm]

On Fri, Jul 01, 2016 at 05:43:52PM +0200, Ard Biesheuvel wrote:
> The MMU routines are only used by a small subset of the users of ArmLib.
> In order to prevent all those users to have to run the library constructor
> to clean some MMU handling routines to the PoC, split off all MMU handling
> into a separate ArmMmuLib.
> 
> NOTE: this change will affect out-of-tree platforms, which will need to add 
> the
>   ArmMmuLib library class resolution to their .DSC descriptions.
> 
> Changes since v1:
> - updated ArmVirtQemuKernel as well as ArmVirtQemu and ArmVirtXen to switch to
>   the new ArmMmuLib (#3)
> - added tags from Laszlo and Star (#3)
> - dropped ArmLib reference from DxeIp l(#3) [*]
> - clarified comment (#4)

For the series:
Reviewed-by: Leif Lindholm 

> [*] I have taken the liberty to keep Star's R-b on patch #3 since the change 
> to
> MdeModulePkg is minimal and only affects ARM/AARCH64
> 
> Ard Biesheuvel (4):
>   ArmPkg: introduce ArmMmuLib library class
>   ArmPkg: introduce base ArmMmuLib implementation
>   ArmPkg ArmVirtPkg MdeModulePkg: switch to separate ArmMmuLib
>   ArmPkg/ArmMmuLib: add PEI specific version of ArmMmuLib
> 
>  ArmPkg/ArmPkg.dec
>  |  1 +
>  ArmPkg/Drivers/CpuDxe/CpuDxe.inf 
>  |  1 +
>  ArmPkg/Include/Library/ArmLib.h  
>  | 38 --
>  ArmPkg/Include/Library/ArmMmuLib.h   
>  | 65 +
>  ArmPkg/Library/ArmLib/AArch64/AArch64BaseLibConstructor.c
>  | 36 --
>  ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf 
>  |  3 -
>  ArmPkg/Library/ArmLib/AArch64/AArch64LibPrePi.inf
>  |  1 -
>  ArmPkg/Library/ArmLib/ArmV7/ArmLibSupportV7.S
>  |  6 --
>  ArmPkg/Library/ArmLib/ArmV7/ArmLibSupportV7.asm  
>  |  6 --
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h   
>  | 12 
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.inf 
>  |  1 -
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7LibPrePi.inf
>  |  1 -
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S   
>  |  5 --
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm 
>  |  4 --
>  ArmPkg/Library/{ArmLib/AArch64/AArch64Mmu.c => 
> ArmMmuLib/AArch64/ArmMmuLibCore.c} | 25 +--
>  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S 
>  | 76 
>  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuPeiLibConstructor.c   
>  | 61 
>  ArmPkg/Library/{ArmLib/ArmV7/ArmV7Mmu.c => ArmMmuLib/Arm/ArmMmuLibCore.c}
>  | 38 +-
>  ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibV7Support.S
>  | 35 +
>  ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibV7Support.asm  
>  | 32 +
>  ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf   
>  | 43 +++
>  ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
>  | 36 ++
>  ArmVirtPkg/ArmVirtQemu.dsc   
>  |  2 +
>  ArmVirtPkg/ArmVirtQemuKernel.dsc 
>  |  2 +
>  ArmVirtPkg/ArmVirtXen.dsc
>  |  2 +
>  ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c 
>  |  1 +
>  ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf   
>  |  1 +
>  MdeModulePkg/Core/DxeIplPeim/Arm/DxeLoadFunc.c   
>  |  2 +-
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  
>  |  2 +-
>  29 files changed, 417 insertions(+), 121 deletions(-)
>  create mode 100644 ArmPkg/Include/Library/ArmMmuLib.h
>  delete mode 100644 ArmPkg/Library/ArmLib/AArch64/AArch64BaseLibConstructor.c
>  rename ArmPkg/Library/{ArmLib/AArch64/AArch64Mmu.c => 
> ArmMmuLib/AArch64/ArmMmuLibCore.c} (94%)
>  create mode 100644 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
>  create mode 100644 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuPeiLibConstructor.c
>  rename ArmPkg/Library/{ArmLib/ArmV7/ArmV7Mmu.c => 
> ArmMmuLib/Arm/ArmMmuLibCore.c} (93%)
>  create mode 100644 ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibV7Support.S
>  create mode 100644 ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibV7Support.asm
>  create mode 100644 ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
>  create mode 100644 ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
> 
> -- 
> 2.7.4
> 
___
edk2-devel mailing list

Re: [edk2] [PATCH 1/7] BaseTools: Enable three new toolchains

[Shi, Steven]

OK. I will separate this patch to 3 commits and post a public branch for them.


Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522


> -Original Message-
> From: Justen, Jordan L
> Sent: Thursday, June 30, 2016 4:55 AM
> To: Shi, Steven ; edk2-devel@lists.01.org; Gao,
> Liming 
> Cc: Kinney, Michael D ; af...@apple.com
> Subject: Re: [edk2] [PATCH 1/7] BaseTools: Enable three new toolchains
> 
> This should be 3 separate commits. It should be obvious in the commit
> subject line what toolchain is being added.
> 
> Can you post a public branch with your commits? Maybe on a personal
> github fork of the edk2 repo.
> 
> On 2016-06-28 08:18:55, Shi, Steven wrote:
> > Enable three new toolchains: CLANG38, CLANGSCAN38 and GCC53.
> > (1)CLANG38 uses Clang3.8.0, 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.
> > (2)CLANGSCAN38 is based on CLANG38 to seamlessly integrate Clang
> > scan-build analyzer infrastructure into edk2 build infrastructure.
> 
> I'm not sure we should add a separate toolchain for this.
> 
> > (3)GCC53 use gcc 5.3, enable GCC Link Time Optimization (LTO) and
> > code size optimization (–Os) for aggressive code size improvement.
> > GCC53 X64 code is also small + PIE.
> 
> As of GCC 5.0, the minor releases have been bumped left. Essentially,
> GCC51, GCC52, etc don't make sense, and GCC5 or GCC6 should be used
> now.
> 
> https://gcc.gnu.org/releases.html
> 
> So, will this work with all versions of GCC 5.*? If not, I suggest we
> consider starting this support at GCC6.
> 
> -Jordan
> 
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Steven Shi 
> > ---
> >  BaseTools/Conf/build_rule.template |  17 ++-
> >  BaseTools/Conf/tools_def.template  | 267
> +
> >  2 files changed, 283 insertions(+), 1 deletion(-)
> >  mode change 100644 => 100755 BaseTools/Conf/build_rule.template
> >  mode change 100644 => 100755 BaseTools/Conf/tools_def.template
> >
> > diff --git a/BaseTools/Conf/build_rule.template
> b/BaseTools/Conf/build_rule.template
> > old mode 100644
> > new mode 100755
> > index 91bcc18..7f21813
> > --- a/BaseTools/Conf/build_rule.template
> > +++ b/BaseTools/Conf/build_rule.template
> > @@ -137,6 +137,9 @@
> >  
> >  "$(CC)" $(CC_FLAGS) -o ${dst} $(INC) ${src}
> >
> > +
> > +"$(SCAN)" $(SCAN_FLAGS) -o $(SCAN_DST) "$(CC)" $(CC_FLAGS) -o
> ${dst} $(INC) ${src}
> > +
> >  [C-Code-File.COMMON.IPF]
> >  
> >  ?.c
> > @@ -267,7 +270,10 @@
> >
> >  
> >  "$(SLINK)" -cr ${dst} $(SLINK_FLAGS) @$(OBJECT_FILES_LIST)
> > -
> > +
> > +
> > +"$(SLINK)" cr ${dst} $(SLINK_FLAGS) @$(OBJECT_FILES_LIST)
> > +
> >  
> >  "$(SLINK)" $(SLINK_FLAGS) ${dst} --via $(OBJECT_FILES_LIST)
> >
> > @@ -295,6 +301,10 @@
> >  "$(DLINK)" -o ${dst} $(DLINK_FLAGS) --start-group $(DLINK_SPATH)
> @$(STATIC_LIBRARY_FILES_LIST) --end-group $(DLINK2_FLAGS)
> >  "$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
> >
> > +
> > +"$(DLINK)" -o ${dst} $(DLINK_FLAGS) -Wl,--start-
> group,$(DLINK_SPATH),@$(STATIC_LIBRARY_FILES_LIST) -Wl,--end-group
> $(DLINK2_FLAGS)
> > +"$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
> > +
> >  
> >  "$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) --via
> $(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
> >
> > @@ -448,6 +458,11 @@
> >  "$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll
> $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
> >  "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll
> $(GENFW_FLAGS)
> >
> > +
> > +"$(ASLCC)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
> $(ASLCC_FLAGS) $(INC) ${src}
> > +"$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll
> $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
> > +"$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll
> $(GENFW_FLAGS)
> > +
> >  
> >  "$(ASLCC)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
> $(ASLCC_FLAGS) $(INC) ${src}
> >  "$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll
> $(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
> > diff --git a/BaseTools/Conf/tools_def.template
> b/BaseTools/Conf/tools_def.template
> > old mode 100644
> > new mode 100755
> > index 2065fa3..d401031
> > --- a/BaseTools/Conf/tools_def.template
> > +++ b/BaseTools/Conf/tools_def.template
> > @@ -366,12 +366,30 @@ DEFINE SOURCERY_CYGWIN_TOOLS =
> /cygdrive/c/Program Files/CodeSourcery/Sourcery G
> >  # Required to build platforms or ACPI tables:
> >  #   

Re: [edk2] [PATCH 4/7] QuarkPlatformPkg-AcpiPlatform: Downgrade the optimization to O1

[Shi, Steven]

OK, I will try to root cause it. And I will separate the Quark build enabling 
work from this serial patches as a new one.


Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522


> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, June 30, 2016 4:56 AM
> To: af...@apple.com; Shi, Steven ; Kinney, Michael D
> 
> Cc: edk2-devel ; Gao, Liming
> ; Zimmer, Vincent ;
> Doran, Mark ; Mudusuru, Giri P
> 
> Subject: RE: [edk2] [PATCH 4/7] QuarkPlatformPkg-AcpiPlatform:
> Downgrade the optimization to O1
> 
> Andrew,
> 
> I agree that we need to root cause and fix this code issue.
> 
> I also like idea of doing RELEASE/DEBUG/NOOPT builds to make sure code
> changes do not introduce build failures.
> 
> Mike
> 
> > -Original Message-
> > From: af...@apple.com [mailto:af...@apple.com]
> > Sent: Wednesday, June 29, 2016 11:31 AM
> > To: Shi, Steven 
> > Cc: edk2-devel ; Gao, Liming
> ; Kinney,
> > Michael D ; Zimmer, Vincent
> ;
> > Doran, Mark ; Mudusuru, Giri P
> 
> > Subject: Re: [edk2] [PATCH 4/7] QuarkPlatformPkg-AcpiPlatform:
> Downgrade the
> > optimization to O1
> >
> >
> > > On Jun 28, 2016, at 8:18 AM, Shi, Steven  wrote:
> > >
> > > Quark AcpiPlatform module cannot link successfully by CLANG38
> > > with Oz optimization level. Add a work around to downgrade the
> > > optimization to O1.
> > >
> >
> > We should fix the code too. These bugs are usually structure assignments in
> the scope
> > of a function that should be global, static, or done via CopyMem.
> >
> > I really think they should get fixed as I see a lot of Si code that fails 
> > to link
> when
> > you compile with optimizations disabled, -O0, with Xcode clang as the
> compiler falls
> > back to memset/memcpy and we were just getting lucky the optimizer
> removed it.
> >
> > Actually it would be nice if packages also got built NOOPT to help catch
> these classes
> > of errors.
> >
> > Thanks,
> >
> > Andrew Fish
> >
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Steven Shi 
> > > ---
> > > QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf | 4 
> > > 1 file changed, 4 insertions(+)
> > > mode change 100644 => 100755
> QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
> > >
> > > diff --git a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
> > b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
> > > old mode 100644
> > > new mode 100755
> > > index dcf2b4a..f1bcfa1
> > > --- a/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
> > > +++ b/QuarkPlatformPkg/Acpi/Dxe/AcpiPlatform/AcpiPlatform.inf
> > > @@ -200,3 +200,7 @@
> > >
> > > [Depex]
> > >   gEfiMpServiceProtocolGuid AND gEfiAcpiTableProtocolGuid
> > > +
> > > +[BuildOptions]
> > > +  GCC:*_CLANG38_IA32_DLINK_FLAGS  = -O1
> > > +  GCC:*_CLANGSCAN38_IA32_DLINK_FLAGS  = -O1
> > > --
> > > 2.7.4
> > >
> > > ___
> > > 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: [edk2] [PATCH 5/7] QuarkSocPkg-MemoryInitPei: Enable compiler builtin and disable CLANG LTO

[Shi, Steven]

I will separate the Quark platform code cleanup work from this serial patches. 
Thanks.


Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522


> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, June 30, 2016 2:10 AM
> To: af...@apple.com; Shi, Steven ; Kinney, Michael D
> 
> Cc: edk2-devel ; Gao, Liming
> ; Zimmer, Vincent ;
> Doran, Mark ; Mudusuru, Giri P
> 
> Subject: RE: [PATCH 5/7] QuarkSocPkg-MemoryInitPei: Enable compiler
> builtin and disable CLANG LTO
> 
> Andrew,
> 
> I agree.  I will work with Steven on this module to improve its compiler
> compatibility.
> 
> Mike
> 
> > -Original Message-
> > From: af...@apple.com [mailto:af...@apple.com]
> > Sent: Wednesday, June 29, 2016 10:57 AM
> > To: Shi, Steven 
> > Cc: edk2-devel ; Gao, Liming
> ; Kinney,
> > Michael D ; Zimmer, Vincent
> ;
> > Doran, Mark ; Mudusuru, Giri P
> 
> > Subject: Re: [PATCH 5/7] QuarkSocPkg-MemoryInitPei: Enable compiler
> builtin and disable
> > CLANG LTO
> >
> >
> > > On Jun 28, 2016, at 8:18 AM, Shi, Steven  wrote:
> > >
> > > The MRC use the memset() in the code and assume the compiler to offer
> > > such builtin fuctions. Add work around to permit compiler add builtin
> > > functions in this module. Also MRC mix some inline assembly,
> > > e.g. asm("rdtsc":"=a"(tscL),"=d"(tscH)),in the C code, and CLANG38
> > > could wrongly remove them if enable LTO with high optimization level.
> > > Add work around to simply disable the LTO in this module.
> > >
> >
> > Steven,
> >
> > If this code is in the edk2 it should follow the edk2 coding rules and we
> should clean
> > it up and not propagate the workarounds to new compilers. Not following
> the rules in
> > the 1st place is what made this code harder to port. Actually if you look at
> the code
> > it started off using VC++ compiler intrinsics and inline assembler syntax,
> and then it
> > had to add some hacky #ifdefs to compile with GCC. If the code just used
> BaseLib and
> > BaseMemoryLib it would not require compiler specific hacks.
> >
> > Why not fix the code to NOT depend on compiler intrinsics and use
> ZeroMem()?
> > /work/src/edk2/QuarkSocPkg/QuarkNorthCluster/MemoryInit(master)>git
> grep memcpy
> > Pei/meminit_utils.h:94:void *memcpy(void *d, const void *s, size_t n);
> >
> ~/work/src/edk2/QuarkSocPkg/QuarkNorthCluster/MemoryInit(master)>git
> grep memset
> > Pei/MemoryInitPei.inf:79:  # /Oi option to use the intrinsic memset
> function in source
> > code.
> > Pei/meminit.c::  memset((void *) (final_delay), 0x00, (size_t)
> > sizeof(final_delay));
> > Pei/meminit.c:1396:  memset((void *) (final_delay), 0x00, (size_t)
> > sizeof(final_delay));
> > Pei/meminit.c:1650:  memset((void *) (final_delay), 0x00, (size_t)
> > sizeof(final_delay));
> > Pei/meminit.c:1972:  memset((void *) (final_delay), 0x00, (size_t)
> > sizeof(final_delay));
> > Pei/meminit_utils.h:93:void *memset(void *d, int c, size_t n);
> >
> > All the inline assembly code is duplicating BaseLib functionality so why not
> fix it?
> >
> ~/work/src/edk2/QuarkSocPkg/QuarkNorthCluster/MemoryInit(master)>git
> grep -W  asm
> > Pei/meminit.c:2240:static void asm_wbinvd(void)
> > Pei/meminit.c-2241-{
> > Pei/meminit.c-2242-#if defined (SIM) || defined (GCC)
> > Pei/meminit.c:2243:  asm(
> > Pei/meminit.c-2244-"wbinvd;"
> > Pei/meminit.c-2245-  );
> > Pei/meminit.c-2246-#else
> > Pei/meminit.c:2247:  __asm wbinvd;
> > Pei/meminit.c-2248-#endif
> > Pei/meminit.c-2249-}
> > Pei/meminit.c-2250-
> > Pei/meminit.c-2251-// cache invalidate
> > Pei/meminit.c:2252:static void asm_invd(void)
> > Pei/meminit.c-2253-{
> > Pei/meminit.c-2254-#if defined (SIM) || defined (GCC)
> > Pei/meminit.c:2255:  asm(
> > Pei/meminit.c-2256-  "invd;"
> > Pei/meminit.c-2257-  );
> > Pei/meminit.c-2258-#else
> > Pei/meminit.c:2259:  __asm invd;
> > Pei/meminit.c-2260-#endif
> > Pei/meminit.c-2261-}
> > Pei/meminit.c-2262-
> > Pei/meminit.c-2263-
> > Pei/meminit.c=2264=static void cpu_read(void)
> > Pei/meminit.c-2265-{
> > Pei/meminit.c-2266-  uint32_t adr, dat, limit;
> > Pei/meminit.c-2267-
> > Pei/meminit.c:2268:  asm_invd();
> > Pei/meminit.c-2269-
> > Pei/meminit.c-2270-  limit = 8 * 1024;
> > Pei/meminit.c-2271-  for (adr = 0; adr < limit; adr += 4)
> > Pei/meminit.c-2272-  {
> > Pei/meminit.c-2273-dat = *(uint32_t*) adr;
> > Pei/meminit.c-2274-if ((adr & 0x0F) == 0)
> > Pei/meminit.c-2275-{
> > Pei/meminit.c-2276-  DPF(D_INFO, "\n%x : ", adr);
> > Pei/meminit.c-2277-}
> > Pei/meminit.c-2278-DPF(D_INFO, "%x ", dat);
> > Pei/meminit.c-2279-  }
> > Pei/meminit.c-2280-  DPF(D_INFO, 

Re: [edk2] [PATCH 3/7] MdePkg: Enable new MS VA intrinsics for GNUC 64bits build

[Shi, Steven]

Yes. MS VA intrinsic (__builtin_ms_va_*) can work on GCC44, and in fact, GCC44 
should have to use them for Uefi 64bits build. The current GCC44 wrongly use 
UNIX  VA intrinsics (__builtin_va_*) as default which cause generate wrong VA 
code if enable -O2 or higher optimization (e.g. -Os). I could fix them on GCC44 
as well in a separate patch later.


Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522

> -Original Message-
> From: Justen, Jordan L
> Sent: Thursday, June 30, 2016 5:47 AM
> To: Andrew Fish 
> Cc: Shi, Steven ; edk2-devel@lists.01.org; Gao,
> Liming ; Kinney, Michael D
> 
> Subject: Re: [edk2] [PATCH 3/7] MdePkg: Enable new MS VA intrinsics for
> GNUC 64bits build
> 
> On 2016-06-29 14:31:49, Andrew Fish wrote:
> >
> > > On Jun 29, 2016, at 2:02 PM, Jordan Justen 
> wrote:
> > >
> > > On 2016-06-28 08:18:57, Shi, Steven wrote:
> > >> Both GCC and LLVM 3.8 64bits support new variable argument (VA)
> > >
> > > Which versions of GCC? Maybe we should define MS_VA_LIST on the
> > > command line for toolchains that can support this?
> > >
> >
> > Maybe I'm backwards but VA_LIST is by definition MS_VA_LIST. What
> > you lose access to is UNIX_VA_LIST?
> >
> > Thus for a compiler that uses the EFIAPI __builtin_va_arg is EFIABI.
> > For a compiler that produces Sys V ABI __builtin_va_arg is the Unix
> > ABI. I verified this assertion with the clang maintainers.
> >
> > VA_LIST always points to EFIAPI and that is why you have to decorate
> > var arg functions with EFIAPI to match VA_LIST.
> >
> > We could add a NATIVE_VA_LIST but for an compiler that natively does
> > EFIAPI it would be the same a VA_LIST. Thus it would be hard to
> > enforce, but it would let some one that knew what they are doing get
> > access to __builtin_va_arg. The problem is if you know what you are
> > doing you can decorate with EFIAPI so is adding NATIVE_VA_LIST
> > really solving any problem?
> >
> 
> My concern was more about if this patch would work on GCC44. I think
> Steven has been testing with GCC5+, so I thought it might be better to
> selectively enable usage of __builtin_ms_va_list for each toolchain.
> 
> -Jordan
> 
> > >
> > >> intrinsics for Microsoft ABI, enable these new VA intrinsics for
> > >> GNUC family 64bits code build. These VA intrinsics are only
> > >> permitted use in 64bits code, so not use them in 32bits code build.
> > >> The original 32bits GNU VA intrinsics has the same calling conversion
> > >> as MS, so we don’t need change them.
> > >>
> > >> Contributed-under: TianoCore Contribution Agreement 1.0
> > >> Signed-off-by: Steven Shi 
> > >> ---
> > >> MdePkg/Include/Base.h | 27 +--
> > >> 1 file changed, 25 insertions(+), 2 deletions(-)
> > >> mode change 100644 => 100755 MdePkg/Include/Base.h
> > >>
> > >> diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
> > >> old mode 100644
> > >> new mode 100755
> > >> index cbd9e55..05fccf3
> > >> --- a/MdePkg/Include/Base.h
> > >> +++ b/MdePkg/Include/Base.h
> > >> @@ -588,9 +588,32 @@ struct _LIST_ENTRY {
> > >>
> > >> #define VA_COPY(Dest, Start)  __va_copy (Dest, Start)
> > >>
> > >> -#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS)
> > >> +
> > >> +#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS)
> && !defined (EFI32)
> > >> +//
> > >> +// 64bits build only. Use GCC built-in macros for variable argument 
> > >> lists.
> > >> +//
> > >> +///
> > >> +/// Both GCC and LLVM 3.8 64bits support new variable argument
> intrinsics for Microsoft ABI
> > >> +///
> > >> +
> > >> +///
> > >> +/// Variable used to traverse the list of arguments. This type can vary
> by
> > >> +/// implementation and could be an array or structure.
> > >> +///
> > >> +typedef __builtin_ms_va_list VA_LIST;
> > >> +
> > >> +#define VA_START(Marker, Parameter)  __builtin_ms_va_start (Marker,
> Parameter)
> > >> +
> > >> +#define VA_ARG(Marker, TYPE) ((sizeof (TYPE) < sizeof (UINTN)) ?
> (TYPE)(__builtin_va_arg (Marker, UINTN)) : (TYPE)(__builtin_va_arg (Marker,
> TYPE)))
> > >> +
> > >> +#define VA_END(Marker)   __builtin_ms_va_end (Marker)
> > >> +
> > >> +#define VA_COPY(Dest, Start) __builtin_ms_va_copy (Dest, Start)
> > >> +
> > >> +#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS) &&
> defined (EFI32)
> > >> //
> > >> -// Use GCC built-in macros for variable argument lists.
> > >> +// 32bits build only. Use GCC built-in macros for variable argument 
> > >> lists.
> > >> //
> > >>
> > >> ///
> > >> --
> > >> 2.7.4
> > >>
> > >> ___
> > >> 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
> > > 

Re: [edk2] Memory Profile question.

[Ramesh R .]

Is there any way we can track the FreePool also ? In the end is it possible to 
identify which are all the memory area allocated, but no freed by system BIOS ?

Thanks,
Ramesh

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
Fish
Sent: 30 June 2016 19:47
To: Yao, Jiewen
Cc: edk2-devel
Subject: Re: [edk2] Memory Profile question.


> On Jun 30, 2016, at 12:05 AM, Yao, Jiewen  wrote:
> 
> Yes, Andrew. You are right.
> We encounter similar problem, but it seems MSVC _ReturnAddress() does not 
> take parameter.
>  #define RETURN_ADDRESS(L) ((L == 0) ? _ReturnAddress() : (VOID *) 0)
> 

For GCC family you can potentially get more info. 

#define RETURN_ADDRESS(L) __builtin_return_address (L)

> So we enhanced MemoryAllocationLib to support add record from 
> MemoryAllocationLib.
> 

Does that mean the logging gets moved to the library? Or does the library log 
just update the log in the DXE Core?

> The final log is like this:
> 
>  CountSize   RVA  Action
> ==  == == 
> ()
> 0x006B  0x0001D31F <== 0xAE7C 
> (gBS->AllocatePool) (InternalAllocatePool() - 
> c:\home\edk-ii\mdemodulepkg\library\smmmemoryallocationlibprofile\memo
> ryallocationlib.c:567)
> 0x0001  0x0020 <== 0xBCB8 
> (Lib:AllocatePool) (SmmMemLibConstructor() - 
> c:\home\edk-ii\mdepkg\library\smmmemlib\smmmemlib.c:309)
> 0x0001  0x0070 <== 0x7F2D 
> (Lib:AllocateZeroRuntimePool) (VariableCommonInitialize() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:4
> 055)
> 0x0001  0xC000 <== 0x715A 
> (Lib:AllocateZeroRuntimePool) (InitNonVolatileVariableStore() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:3
> 692)
> 0x0001  0x00010400 <== 0x8121 
> (Lib:AllocateRuntimePool) (VariableCommonInitialize() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:4
> 113)
> 0x0001  0x0404 <== 0x2957 
> (gBS->AllocatePool) (VariableServiceInitialize() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variablesmm.
> c:956)
> 0x0007  0x01CE <== 0xC42E 
> (Lib:AllocateZeroRuntimePool) (VarCheckLibVariablePropertySet() - 
> c:\home\edk-ii\mdemodulepkg\library\varchecklib\varchecklib.c:521)
> 0x0001  0x0020 <== 0xC071 
> (Lib:ReallocateRuntimePool) (VarCheckAddTableEntry() - 
> c:\home\edk-ii\mdemodulepkg\library\varchecklib\varchecklib.c:228)
> 0x0001  0x0030 <== 0x2E08 
> (Lib:AllocateZeroPool) (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 96)
> 0x0001  0x0044 <== 0x2E68 
> (Lib:AllocateZeroPool) (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:2
> 00) 0x002C  0x0840 <== 0x2F98 
> (Lib:AllocateZeroPool) (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:2
> 32) 0x002C  0x037C <== 0x2FF6 
> (Lib:AllocateZeroPool) (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:2
> 36)
> 0x0001  0x000D <== 0x4DC9 
> (Lib:AllocateCopyRuntimePool) (AutoUpdateLangVariable() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 960)
> 0x0001  0x0012 <== 0x4CC4 
> (Lib:AllocateCopyRuntimePool) (AutoUpdateLangVariable() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 930)
> 0x0001  0x0012 <== 0x4D28 
> (Lib:AllocateRuntimePool) (AutoUpdateLangVariable() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 940)
> 
> 

Are the address ranges allocated tracked? Is it possible to look up an address 
and figure out where it got allocated? 

Any plans to add logging for stalls? You can dump events with a debugger 
script, so that is not as important. 

Thanks,

Andrew Fish

> 
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
>> Of Andrew Fish
>> Sent: Thursday, June 30, 2016 2:38 PM
>> To: edk2-devel 
>> Subject: [edk2] Memory Profile question.
>> 
>> I've done some experimentation on the memory logging and if possible 
>> it is very useful to have 4 stack frames (non-LTO)  as it is common 
>> for the MemoryAllocationLib to to call a sequence of Internal 
>> functions, so to find the calling spot in the driver you need 4 entries.
>> For example:
>> FunctionThatAllocatePool()
>> AllocateZeroPool()
>> InternalAllocateZeroPool()
>> InternalAllocatePool()
>> 
>> 

[edk2] [PATCH] BaseTools MemoryProfileSymbolGen.py: Handle 64bits rva from "nm -l xxx.dll"

[Star Zeng]

Current MemoryProfileSymbolGen.py assumes the rva is 32bits,
the patch is to remove the restriction to match any lengths
of rva.

Cc: Jiewen Yao 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 BaseTools/Scripts/MemoryProfileSymbolGen.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Scripts/MemoryProfileSymbolGen.py 
b/BaseTools/Scripts/MemoryProfileSymbolGen.py
index a9790d8883c8..5709ad4641cb 100644
--- a/BaseTools/Scripts/MemoryProfileSymbolGen.py
+++ b/BaseTools/Scripts/MemoryProfileSymbolGen.py
@@ -19,7 +19,7 @@ import re
 import sys
 from optparse import OptionParser
 
-versionNumber = "1.0"
+versionNumber = "1.1"
 __copyright__ = "Copyright (c) 2016, Intel Corporation. All rights reserved."
 
 class Symbols:
@@ -72,7 +72,7 @@ class Symbols:
 linefile.close()
 
 # 000113ca T AllocatePool  
c:\home\edk-ii\MdePkg\Library\UefiMemoryAllocationLib\MemoryAllocationLib.c:399
-patchLineFileMatchString = 
"([0-9a-fA-F]{8})\s+[T|D|t|d]\s+(\w+)\s*((?:[a-zA-Z]:)?[\w+\-./_a-zA-Z0-9]*):?([0-9]*)"
+patchLineFileMatchString = 
"([0-9a-fA-F]*)\s+[T|D|t|d]\s+(\w+)\s*((?:[a-zA-Z]:)?[\w+\-./_a-zA-Z0-9]*):?([0-9]*)"
 
 for reportLine in reportLines:
 #print "check - " + reportLine
-- 
2.7.0.windows.1

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

[edk2] [PATCH] MdeModulePkg MemoryProfileInfo: Handle "/" character in the PDB path

[Star Zeng]

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c 
b/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
index 69c6cf166daa..68e7ed7326f0 100644
--- a/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
+++ b/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
@@ -205,7 +205,7 @@ GetShortPdbFileName (
 StartIndex = 0;
 for (EndIndex = 0; PdbFileName[EndIndex] != 0; EndIndex++);
 for (IndexPdb = 0; PdbFileName[IndexPdb] != 0; IndexPdb++) {
-  if (PdbFileName[IndexPdb] == '\\') {
+  if ((PdbFileName[IndexPdb] == '\\') || (PdbFileName[IndexPdb] == '/')) {
 StartIndex = IndexPdb + 1;
   }
 
-- 
2.7.0.windows.1

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

[edk2] [Patch] BaseTools: Add support for $(FAMILY) macro

[Yonghong Zhu]

Build spec mentions $(FAMILY) macro be used in DSC/FDF to specify the tool
chain family, like GCC, MSFT. This patch add the support for this macro.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/build/build.py | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/BaseTools/Source/Python/build/build.py 
b/BaseTools/Source/Python/build/build.py
index 4f859bf..d9afdcc 100644
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -784,10 +784,11 @@ class Build():
 self.Db = WorkspaceDatabase(":memory:")
 else:
 self.Db = WorkspaceDatabase(GlobalData.gDatabasePath, self.Reparse)
 self.BuildDatabase = self.Db.BuildObject
 self.Platform = None
+self.ToolChainFamily = None
 self.LoadFixAddress = 0
 self.UniFlag= BuildOptions.Flag
 self.BuildModules = []
 self.Db_Flag = False
 self.LaunchPrebuildFlag = False
@@ -876,10 +877,21 @@ class Build():
 EdkLogger.error("build", RESOURCE_NOT_AVAILABLE,
 ExtraData="[%s] not defined. No toolchain 
available for build!\n" % ", ".join(self.ToolChainList))
 else:
 self.ToolChainList = NewToolChainList
 
+ToolChainFamily = []
+ToolDefinition = self.ToolDef.ToolsDefTxtDatabase
+for Tool in self.ToolChainList:
+if TAB_TOD_DEFINES_FAMILY not in ToolDefinition or Tool not in 
ToolDefinition[TAB_TOD_DEFINES_FAMILY] \
+   or not ToolDefinition[TAB_TOD_DEFINES_FAMILY][Tool]:
+EdkLogger.warn("No tool chain family found in configuration 
for %s. Default to MSFT." % Tool)
+ToolChainFamily.append("MSFT")
+else:
+
ToolChainFamily.append(ToolDefinition[TAB_TOD_DEFINES_FAMILY][Tool])
+self.ToolChainFamily = ToolChainFamily
+
 if self.ThreadNumber == None:
 self.ThreadNumber = 
self.TargetTxt.TargetTxtDictionary[DataType.TAB_TAT_DEFINES_MAX_CONCURRENT_THREAD_NUMBER]
 if self.ThreadNumber == '':
 self.ThreadNumber = 0
 else:
@@ -934,10 +946,12 @@ class Build():
 if self.ArchList:
 GlobalData.gGlobalDefines['ARCH'] = self.ArchList[0]
 if self.ToolChainList:
 GlobalData.gGlobalDefines['TOOLCHAIN'] = self.ToolChainList[0]
 GlobalData.gGlobalDefines['TOOL_CHAIN_TAG'] = self.ToolChainList[0]
+if self.ToolChainFamily:
+GlobalData.gGlobalDefines['FAMILY'] = self.ToolChainFamily[0]
 if 'PREBUILD' in GlobalData.gCommandLineDefines.keys():
 self.Prebuild   = GlobalData.gCommandLineDefines.get('PREBUILD')
 else:
 self.Db.InitDatabase()
 self.Db_Flag = True
@@ -1597,13 +1611,16 @@ class Build():
 #
 def _BuildPlatform(self):
 SaveFileOnChange(self.PlatformBuildPath, '# DO NOT EDIT \n# FILE 
auto-generated\n', False)
 for BuildTarget in self.BuildTargetList:
 GlobalData.gGlobalDefines['TARGET'] = BuildTarget
+index = 0
 for ToolChain in self.ToolChainList:
 GlobalData.gGlobalDefines['TOOLCHAIN'] = ToolChain
 GlobalData.gGlobalDefines['TOOL_CHAIN_TAG'] = ToolChain
+GlobalData.gGlobalDefines['FAMILY'] = 
self.ToolChainFamily[index]
+index += 1
 Wa = WorkspaceAutoGen(
 self.WorkspaceDir,
 self.PlatformFile,
 BuildTarget,
 ToolChain,
@@ -1677,13 +1694,16 @@ class Build():
 ## Build active module for different build targets, different tool chains 
and different archs
 #
 def _BuildModule(self):
 for BuildTarget in self.BuildTargetList:
 GlobalData.gGlobalDefines['TARGET'] = BuildTarget
+index = 0
 for ToolChain in self.ToolChainList:
 GlobalData.gGlobalDefines['TOOLCHAIN'] = ToolChain
 GlobalData.gGlobalDefines['TOOL_CHAIN_TAG'] = ToolChain
+GlobalData.gGlobalDefines['FAMILY'] = 
self.ToolChainFamily[index]
+index += 1
 #
 # module build needs platform build information, so get 
platform
 # AutoGen first
 #
 Wa = WorkspaceAutoGen(
@@ -1771,13 +1791,16 @@ class Build():
 #
 def _MultiThreadBuildPlatform(self):
 SaveFileOnChange(self.PlatformBuildPath, '# DO NOT EDIT \n# FILE 
auto-generated\n', False)
 for BuildTarget in self.BuildTargetList:
 GlobalData.gGlobalDefines['TARGET'] = BuildTarget
+index = 0
 for ToolChain in self.ToolChainList:
 

Re: [edk2] [PATCH] MdeModulePkg/UsbBusDxe: Fixed potential NULL pointer dereference UsbSelectConfig

[Evgeny Yakovlev]

ping?

2016-06-29 14:54 GMT+03:00 Evgeny Yakovlev :

> Consider the following course of action When enumerating new USB device:
>
> 1. UsbParseConfigDesc is called during new device enumeration process.
> It allocates an array of USB_INTERFACE_DESC pointers in Config->Interfaces.
> Each of those structures have an array of pointers to USB_INTERFACE_SETTING
> which are currently set to NULL.
>
> 2. Then UsbParseConfigDesc calls UsbParseInterfaceDesc as long as there is
> data left in buffer. Each call parses an interface setting and sets
> appropriate pointer in Interface->Settings for related interface desc.
>
> 3. Later UsbSelectConfig traverses Config->Interfaces[NumIf]->Settings
> to pick appropriate interface configuration.
>
> However if during step 2 UsbParseInterfaceDesc returns NULL (i.e.
> because UsbCreateDesc returned NULL, see f89f1db) then config will be
> not fully initialized by the time it is returned to caller. Some pointers
> in
> Config->Interfaces->Settings are still set to NULL and will be possibly
> dereferenced in UsbSelectConfig.
>
> This patch treats this situation as an error and returns NULL
> instead if incompletely initialized config descriptor.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Evgeny Yakovlev 
> CC: Feng Tian 
> ---
>  MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c   | 4 ++--
>  MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c | 3 +++
>  2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
> b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
> index fba60da..20e6ca3 100644
> --- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
> +++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.c
> @@ -368,8 +368,8 @@ UsbParseConfigDesc (
>  Setting = UsbParseInterfaceDesc (DescBuf, Len, );
>
>  if (Setting == NULL) {
> -  DEBUG (( EFI_D_ERROR, "UsbParseConfigDesc: warning: failed to get
> interface setting, stop parsing now.\n"));
> -  break;
> +  DEBUG (( EFI_D_ERROR, "UsbParseConfigDesc: failed to get interface
> setting, stop parsing now.\n"));
> +  goto ON_ERROR;
>
>  } else if (Setting->Desc.InterfaceNumber >= NumIf) {
>DEBUG (( EFI_D_ERROR, "UsbParseConfigDesc: mal-formated interface
> descriptor\n"));
> diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> index 79453fe..57199a0 100644
> --- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> +++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> @@ -412,6 +412,9 @@ UsbSelectConfig (
>  // the endpoint toggles to zero for its endpoints.
>  //
>  IfDesc = ConfigDesc->Interfaces[Index];
> +ASSERT (IfDesc != NULL);
> +ASSERT (IfDesc->Settings[0] != NULL);
> +
>  UsbSelectSetting (IfDesc, IfDesc->Settings[0]->Desc.AlternateSetting);
>
>  //
> --
> 2.7.4 (Apple Git-66)
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/4] MdePkg/IndustryStandard: introduce EFI_PCI_CAPABILITY_ID_SHPC

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni 

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, July 1, 2016 9:11 AM
> To: edk2-devel-01 
> Cc: Johnson, Brian J. ; Alex Williamson
> ; Andrew Fish ; Tian, Feng
> ; Justen, Jordan L ; Gao,
> Liming ; Marcel Apfelbaum ;
> Kinney, Michael D ; Ni, Ruiyu
> ; Zeng, Star 
> Subject: [PATCH 1/4] MdePkg/IndustryStandard: introduce
> EFI_PCI_CAPABILITY_ID_SHPC
> 
> The "Pci22.h" header file defines the macro
> EFI_PCI_CAPABILITY_ID_HOTPLUG with value 0x06. According to all of:
> - later parts of the same header file,
> - Appendix H ("Capability IDs") of the PCI Local Bus Specification
>   Revision 2.3,
> - and Chapter 2 ("Capability IDs") of the PCI Code and ID Assignment
>   Specification Revision 0.9,
> 
> 0x06 means "CompactPCI Hot Swap". It does not mean "PCI Hot-Plug": that
> capability is described by ID 0x0C:
> 
>   0Ch  PCI Hot-Plug -- This Capability ID indicates that the associated
>device conforms to the Standard Hot-Plug Controller model.
> 
> Therefore EFI_PCI_CAPABILITY_ID_HOTPLUG is arguably a misnomer.
> PciBusDxe (mis-)uses EFI_PCI_CAPABILITY_ID_HOTPLUG in the IsSHPC()
> helper function to identify PCI Hot-Plug capability.
> 
> In order to preserve compatibility with existent code, leave
> EFI_PCI_CAPABILITY_ID_HOTPLUG alone, and introduce
> EFI_PCI_CAPABILITY_ID_SHPC with the right ID value.
> 
> Cc: "Johnson, Brian J." 
> Cc: Alex Williamson 
> Cc: Andrew Fish 
> Cc: Feng Tian 
> Cc: Jordan Justen 
> Cc: Liming Gao 
> Cc: Marcel Apfelbaum 
> Cc: Michael D Kinney 
> Cc: Ruiyu Ni 
> Cc: Star Zeng 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  MdePkg/Include/IndustryStandard/Pci22.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MdePkg/Include/IndustryStandard/Pci22.h
> b/MdePkg/Include/IndustryStandard/Pci22.h
> index db24a153e15e..4cf8389c699b 100644
> --- a/MdePkg/Include/IndustryStandard/Pci22.h
> +++ b/MdePkg/Include/IndustryStandard/Pci22.h
> @@ -635,6 +635,7 @@ typedef union {
>  #define EFI_PCI_CAPABILITY_ID_SLOTID  0x04
>  #define EFI_PCI_CAPABILITY_ID_MSI 0x05
>  #define EFI_PCI_CAPABILITY_ID_HOTPLUG 0x06
> +#define EFI_PCI_CAPABILITY_ID_SHPC0x0C
> 
>  ///
>  /// Capabilities List Header
> --
> 1.8.3.1
> 

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

Re: [edk2] Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required and not found

[Ye, Ting]

Hi Aravindh,

I see following difference between your working and non-working logs.

29 000A B N N   1   1 ASIX AX88772B Ethernet Driver 2.4.0 
Fv(A881D567-6CB0-4EEE-8435-2E72D33E45B5)/FvFile(25DC8C52-544B-43BF-A58D-995F96DEB726)
2B 000A ? N N   0   0 ASIX AX88772B Ethernet Driver 2.4.0 
Fv(A881D567-6CB0-4EEE-8435-2E72D33E45B5)/FvFile(25DC8C52-544B-43BF-A58D-995F96DEB726)

Is this the particular NIC driver for your network card? I see the NIC card is 
managed by this driver in your working environment.

Thanks,
Ting


-Original Message-
From: Aravindhlal G.S.S [mailto:aravindhlal...@embedur.com] 
Sent: Monday, July 04, 2016 1:06 PM
To: Ye, Ting ; edk2-devel@lists.01.org
Subject: RE: Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required and 
not found

Hi Ting, 

I think it should be fine, because we have a similar setup and that is working 
fine. In the working setup, I could see many of the drivers whose type is not 
yet recognised.
But in case of the working setup, almost many of the drivers are classified and 
they are being used by devices (entries under #D & #C).

I have attached the output of drivers command of both working & non-working 
setups to differentiate it. Could you please take a look at these attached 
files ?

Both of them are running the same version of EFI firmware. Am I missing 
anything big ? 

Thanks
-Aravindh

-Original Message-
From: Ye, Ting [mailto:ting...@intel.com] 
Sent: Monday, July 04, 2016 10:20 AM
To: Aravindhlal G.S.S; edk2-devel@lists.01.org
Subject: RE: Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required and 
not found

Hi Aravindh,

It looks the problem is irrelevant to upper layer drivers including SNP, MNP, 
and others, but your UNDI driver does not manage your NIC card:
F7 000A ? N N   0   0 UNDI32 Driver   
Fv(A881D567-6CB0-4EEE-8435-2E72D33E45B5)/FvFile(A1F436EA-A127-4EF8-957C-8048606FF670)

Is the UNDI driver the correct NIC device driver in UEFI?

Best Regards,
Ting

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Aravindhlal G.S.S
Sent: Monday, July 04, 2016 12:39 PM
To: Aravindhlal G.S.S ; Ye, Ting 
; edk2-devel@lists.01.org
Subject: Re: [edk2] Error. The protocol 'gEfiIp4ConfigProtocolGuid' was 
required and not found

Sorry, Forgot to attach file in previous email. Attached in this email. 

Hi Ting,

The chipset being used is Puma 7 DOCSIS 3.1 chip. I could also see the UNDI 
driver installed. Please see below.

F7 000A ? N N   0   0 UNDI32 Driver   
Fv(A881D567-6CB0-4EEE-8435-2E72D33E45B5)/FvFile(A1F436EA-A127-4EF8-957C-8048606FF670)

Please see the attached text file the output of drivers command. I tried 
following, but none of them worked. 
*   I reset all the parameters/values to defaults
*   I tried reconnecting all the drivers 
*   I tried to unload and then again load the driver using the 
handle
*   I tried to bind all drivers to a specific devices and start the 
driver
*   I tried to force defaults on all devices using "drvcfg -f 0" 
command

Could you please take a look in the attached text file ? Still am I missing any 
drivers to be installed ? is there any way to reinstall the drivers (SNP, MNP & 
other network drivers) ? Appreciate your help !

Thanks
-Aravindh
-Original Message-
From: Ye, Ting [mailto:ting...@intel.com] 
Sent: Monday, July 04, 2016 7:12 AM
To: Aravindhlal G.S.S; edk2-devel@lists.01.org
Subject: RE: Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required and 
not found

Hi Aravindh,

Which platform are you using for running the network stack? You probably need a 
particular UNDI driver for your Ethernet card if you are not using simulator 
like NT32 platform.

Best Regards,
Ting
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Aravindhlal G.S.S
Sent: Friday, July 01, 2016 6:42 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required 
and not found

Hi Experts,

I am not able to config the Ethernet interface in UEFI shell. I am running

Shell> teractive Shell v2.1
EDK II
UEFI v2.40 (EDK II, 0x0001)

The drivers commands list the required driver, but #D is 0 and Type is "?". Am 
I missing any drivers to be installed ? If so could you please help in sharing 
the pointers ?

 T
 Y C  I
 P F  A
DRV VERSION  E G G #D  #C  DRIVER NAME IMAGE PATH
===  = = = === === === ==
97 000A ? N N   0   0 Simple Network Protocol Driver  
Fv(A881D567-6CB0-4EEE-8435-2E72D33E45B5)/FvFile(A2F436EA-A127-4EF8-957C-8048606FF670)
9C 000A ? N N   0   0 IP4 CONFIG Network Service Driver   

Re: [edk2] [PATCH 3/4] MdeModulePkg/PciBusDxe: recognize hotplug-capable PCIe ports

[Ni, Ruiyu]

Adding Kinney.

Laszlo,
Your patch assumes all PCIE slot are hot plug capable.
But why PCIE spec 3.0 chapter 7.8.9 Slot Capabilities Register (Offset 14h)
contains a BIT called Hot-Plug Capable?
Does your patch also need to check the Hot-Plug Capable bit as well?


BTW, though I am the owner of PciBus driver in EDKII, I am really a newbie to
this area.
Before your patch, I always thought PciHotPlugInit.GetRootHpcList() should
return all hot plug PCIE ports. But after seeing your patch, I went back to
re-read the PI spec and found some words like "root HPCs", "may not be
able to detect these HPCs", which let me agree with your understanding
that GetRootHpcList() only returns these HPCs that cannot be detected by
PciBus.

Thanks,
Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Friday, July 1, 2016 9:11 AM
> To: edk2-devel-01 
> Cc: Ni, Ruiyu ; Tian, Feng ;
> Johnson, Brian J. ; Andrew Fish ;
> Justen, Jordan L ; Marcel Apfelbaum
> ; Zeng, Star 
> Subject: [edk2] [PATCH 3/4] MdeModulePkg/PciBusDxe: recognize hotplug-
> capable PCIe ports
> 
> Section 7.8.2 of the PCI Express specification (r4.0 v0.3), entitled "PCI 
> Express
> Capabilities Register (Offset 02h)", describes the conditions when a PCIe port
> should be considered "supporting hotplug":
> - it should be a root complex port or a switch downstream port, and
> - it should have the "Slot Implemented" bit set.
> 
> This logic is already implemented in at least two open source projects I could
> find:
> 
> - in SeaBIOS by Marcel Apfelbaum: "hw/pci: reserve IO and mem for pci
>   express downstream ports with no devices attached"
>   ,
> 
> - in edk2 itself, in the implementation of the "PCI" UEFI Shell command:
>   see the "PcieExplainTypeSlot" case label in function
>   PciExplainPciExpress(), file
>   "ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c".
> 
> PciBusDxe recognizes such PCIe ports as bridges, but it doesn't realize they
> support hotplug. In turn PciBusDxe omits getting any resource padding
> information from the platform's EFI_PCI_HOT_PLUG_INIT_PROTOCOL for
> these
> bridges:
> 
>   GatherPpbInfo()[PciEnumeratorSupport.c]
> GetResourcePaddingPpb()  [PciResourceSupport.c]
>   GetResourcePaddingForHpb() [PciHotPlugSupport.c]
> IsPciHotPlugBus()[PciHotPlugSupport.c]
>   //
>   // returns FALSE
>   //
> //
> // the following is not reached:
> //
> gPciHotPlugInit->GetResourcePadding()
> 
> Implement a function called SupportsPcieHotplug() for identifying such ports,
> and call it from IsPciHotPlugBus() (after the call to IsSHPC()).
> 
> Cc: "Johnson, Brian J." 
> Cc: Alex Williamson 
> Cc: Andrew Fish 
> Cc: Feng Tian 
> Cc: Jordan Justen 
> Cc: Marcel Apfelbaum 
> Cc: Ruiyu Ni 
> Cc: Star Zeng 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.h | 19 ++
> MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.c | 71
> 
>  2 files changed, 90 insertions(+)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.h
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.h
> index 1fb9ba972091..6e02b8b98bf0 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.h
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.h
> @@ -177,6 +177,25 @@ IsSHPC (
>);
> 
>  /**
> +  Check whether PciIoDevice supports PCIe hotplug.
> +
> +  This is equivalent to the following condition:
> +  - the device is either a PCIe switch downstream port or a root port,
> +  - and the device has the SlotImplemented bit set in its PCIe capability
> +register.
> +
> +  @param[in] PciIoDevice  The device being checked.
> +
> +  @retval TRUE   PciIoDevice is a PCIe port that accepts a hotplugged device.
> +  @retval FALSE  Otherwise.
> +
> +**/
> +BOOLEAN
> +SupportsPcieHotplug (
> +  IN PCI_IO_DEVICE  *PciIoDevice
> +  );
> +
> +/**
>Get resource padding if the specified PCI bridge is a hot plug bus.
> 
>@param PciIoDevicePCI bridge instance.
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.c
> index ca8766869ae7..19dd97a4528d 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciHotPlugSupport.c
> @@ -317,6 +317,69 @@ IsSHPC (
>  }
> 
>  /**
> +  Check whether PciIoDevice supports PCIe 

Re: [edk2] [PATCH] MdeModulePkg MemoryProfile: Add ASSERTs to make sure pointers are not NULL

[Zeng, Star]

Reviewed-by: Star Zeng 

-Original Message-
From: Wu, Hao A 
Sent: Monday, July 4, 2016 12:54 PM
To: edk2-devel@lists.01.org
Cc: Wu, Hao A ; Zeng, Star 
Subject: [PATCH] MdeModulePkg MemoryProfile: Add ASSERTs to make sure pointers 
are not NULL

Code logic ensures that both pointers 'DriverInfoData' and 'AllocInfoData'
will not be NULL when they are used.

Add ASSERTs as warning for cases that will not happen.

Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c  | 3 +++  
MdeModulePkg/Core/PiSmmCore/SmramProfileRecord.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c 
b/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
index 14c4959..30c0df4 100644
--- a/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
+++ b/MdeModulePkg/Core/Dxe/Mem/MemoryProfileRecord.c
@@ -1283,6 +1283,9 @@ CoreUpdateProfileFree (
   }
 }
 
+ASSERT (DriverInfoData != NULL);
+ASSERT (AllocInfoData != NULL);
+
 Found = TRUE;
 
 Context = >Context;
diff --git a/MdeModulePkg/Core/PiSmmCore/SmramProfileRecord.c 
b/MdeModulePkg/Core/PiSmmCore/SmramProfileRecord.c
index 281e382..ac832ce 100644
--- a/MdeModulePkg/Core/PiSmmCore/SmramProfileRecord.c
+++ b/MdeModulePkg/Core/PiSmmCore/SmramProfileRecord.c
@@ -1403,6 +1403,9 @@ SmmCoreUpdateProfileFree (
   }
 }
 
+ASSERT (DriverInfoData != NULL);
+ASSERT (AllocInfoData != NULL);
+
 Found = TRUE;
 
 Context = >Context;
--
1.9.5.msysgit.0

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

Re: [edk2] [PATCH] MdeModulePkg DxeIplPeim: Add ASSERTs for unexpected AllocatePages failure

[Zeng, Star]

Reviewed-by: Star Zeng 

-Original Message-
From: Wu, Hao A 
Sent: Monday, July 4, 2016 2:01 PM
To: edk2-devel@lists.01.org
Cc: Wu, Hao A ; Zeng, Star ; Yao, 
Jiewen 
Subject: [PATCH] MdeModulePkg DxeIplPeim: Add ASSERTs for unexpected 
AllocatePages failure

Cc: Star Zeng 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c 
b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
index ab1e914..fbce93c 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
@@ -67,6 +67,7 @@ Split2MPageTo4K (
   PAGE_TABLE_4K_ENTRY   *PageTableEntry;
 
   PageTableEntry = AllocatePages (1);
+  ASSERT (PageTableEntry != NULL);
   //
   // Fill in 2M page entry.
   //
@@ -111,6 +112,7 @@ Split1GPageTo2M (
   PAGE_TABLE_ENTRY  *PageDirectoryEntry;
 
   PageDirectoryEntry = AllocatePages (1);
+  ASSERT (PageDirectoryEntry != NULL);
   //
   // Fill in 1G page entry.
   //
-- 
1.9.5.msysgit.0

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

Re: [edk2] [PATCH 6/6] Vlv2TbltDevicePkg: fix ASSERT_EFI_ERROR() typos

[Gao, Liming]

Ard:
  There is no rule change. This is the wrong operation.

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Friday, July 01, 2016 8:27 PM
> To: Ard Biesheuvel ; Wei, David
> ; Justen, Jordan L 
> Cc: He, Tim ; edk2-devel-01 
> Subject: Re: [edk2] [PATCH 6/6] Vlv2TbltDevicePkg: fix ASSERT_EFI_ERROR()
> typos
> 
> On 07/01/16 13:36, Ard Biesheuvel wrote:
> > On 29 June 2016 at 09:49, Wei, David  wrote:
> >> Reviewed-by: David Wei 
> >>
> >> Thanks,
> >> David  Wei
> >>
> >
> > Hi David,
> >
> > It seems like Laszlo and you both pushed this patch, and you merged it
> > rather than rebasing first.
> >
> > This means we now have two copies of the same patch, which needlessly
> > obfuscates the GIT history.
> > Question to the crowd: what is the latest policy regarding merges vs
> > linear history? It was discussed at great length but IIRC the standing
> > policy is still 'no merges' ?
> 
> The rule I've been tacitly following is: rebase unless a contributor
> specifically requests a PULL. (On the list, not on github.)
> 
> Thanks
> Laszlo
> ___
> 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: [edk2] [PATCH v2] MdeModulePkg/MemoryStatusCode: Expose the DXE memory status code table.

[Gao, Liming]

Laszlo:
  MdeModulePkg ones follows PI spec to implement StatusCode Router/Handler and 
provide StatusCode service. It allows the different status code handlers to be 
registered. IntelFrameworkModulePkg one just provides StatusCode service. It 
has no Router services. 

  StatusCode service is used to report the boot status. It is also used to 
print debug message. For example, PeiDxeDebugLibReportStatusCode library 
instance bases on StatusCode to print DEBUG message. 

Thanks
Liming
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, June 30, 2016 6:18 PM
> To: Gao, Liming ; Bruce Cran ;
> Cinnamon Shia ; edk2-de...@ml01.01.org
> Cc: Tian, Feng ; Zeng, Star 
> Subject: Re: [edk2] [PATCH v2] MdeModulePkg/MemoryStatusCode: Expose
> the DXE memory status code table.
> 
> On 06/30/16 04:40, Gao, Liming wrote:
> > Laszlo:
> > I have sent the patch to fix it.
> 
> Thanks!
> 
> > Besides, I suggest to update Ovmf
> > DSC/FDF to use StatusCode Router and Handler from MdeModulePkg
> > instead of IntelFrameworkModulePkg.
> 
> What's the difference between them?
> 
> Actually, what do these drivers do? (I don't know why we include them in
> OVMF.)
> 
> Thanks!
> Laszlo
> 
> >
> > Thanks
> > Liming
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >> Gao, Liming
> >> Sent: Thursday, June 30, 2016 9:02 AM
> >> To: Laszlo Ersek ; Bruce Cran ;
> >> Cinnamon Shia ; edk2-de...@ml01.01.org
> >> Cc: Tian, Feng ; Zeng, Star 
> >> Subject: Re: [edk2] [PATCH v2] MdeModulePkg/MemoryStatusCode:
> Expose
> >> the DXE memory status code table.
> >>
> >> Yes. I will make one patch to fix it. Thanks for your report.
> >>
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Thursday, June 30, 2016 1:40 AM
> >> To: Bruce Cran ; Cinnamon Shia
> >> ; edk2-de...@ml01.01.org
> >> Cc: Tian, Feng ; Gao, Liming
> ;
> >> Zeng, Star 
> >> Subject: Re: [edk2] [PATCH v2] MdeModulePkg/MemoryStatusCode:
> Expose
> >> the DXE memory status code table.
> >>
> >> On 06/29/16 16:47, Bruce Cran wrote:
> >>> On 6/27/2016 1:25 AM, Cinnamon Shia wrote:
>  Let data of DXE memory status code can be used by other modules.
>  1. Save the address of DXE memory status code table to
>  DxeConfigurationTable.
>  2. Save the address of SMM memory status code table to
>  SmmConfigurationTable.
>  3. Move RUNTIME_MEMORY_STATUSCODE_HEADER to its public
> header
> >> file.
> >>>
> >>> I'm getting an error building OVMF today, which appears related:
> >>>
> >>> In file included from
> >>>
> >>
> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/Statu
> >> sCode/RuntimeDxe/SerialStatusCodeWorker.c:15:0:
> >>>
> >>>
> >>
> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/Statu
> >> sCode/RuntimeDxe/StatusCodeRuntimeDxe.h:63:3:
> >>> error: conflicting types for 'RUNTIME_MEMORY_STATUSCODE_HEADER'
> >>> } RUNTIME_MEMORY_STATUSCODE_HEADER;
> >>> ^~~~
> >>> In file included from
> >>>
> >>
> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/Statu
> >> sCode/RuntimeDxe/StatusCodeRuntimeDxe.h:22:0,
> >>>
> >>> from
> >>>
> >>
> /home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/Statu
> >> sCode/RuntimeDxe/SerialStatusCodeWorker.c:15:
> >>>
> >>>
> >>
> /home/bcran/workspace/edk2/MdeModulePkg/Include/Guid/MemoryStat
> >> usCodeRecord.h:76:3:
> >>> note: previous declaration of
> 'RUNTIME_MEMORY_STATUSCODE_HEADER'
> >> was here
> >>> } RUNTIME_MEMORY_STATUSCODE_HEADER;
> >>> ^~~~
> >>>
> >>
> >> Yes, the file
> >>
> >>
> IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCode
> >> RuntimeDxe.h
> >>
> >> includes
> >>
> >> MdeModulePkg/Include/Guid/MemoryStatusCodeRecord.h
> >>
> >> but also defines the RUNTIME_MEMORY_STATUSCODE_HEADER type,
> which
> >> has
> >> now become redundant.
> >>
> >> As far as I can see, it should be fixable by removing the
> >> RUNTIME_MEMORY_STATUSCODE_HEADER typedef from
> >>
> "IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCod
> >> eRuntimeDxe.h".
> >>
> >> Thanks
> >> Laszlo
> >> ___
> >> 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] [PATCH] MdeModulePkg DxeIplPeim: Add ASSERTs for unexpected AllocatePages failure

[Hao Wu]

Cc: Star Zeng 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c 
b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
index ab1e914..fbce93c 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
@@ -67,6 +67,7 @@ Split2MPageTo4K (
   PAGE_TABLE_4K_ENTRY   *PageTableEntry;
 
   PageTableEntry = AllocatePages (1);
+  ASSERT (PageTableEntry != NULL);
   //
   // Fill in 2M page entry.
   //
@@ -111,6 +112,7 @@ Split1GPageTo2M (
   PAGE_TABLE_ENTRY  *PageDirectoryEntry;
 
   PageDirectoryEntry = AllocatePages (1);
+  ASSERT (PageDirectoryEntry != NULL);
   //
   // Fill in 1G page entry.
   //
-- 
1.9.5.msysgit.0

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