Date   

Re: [PATCH] BaseTools X64: fold PLT relocations into simple relative references

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

Hi Ard,
I don't see you add below code for case R_X86_64_PLT32. Is it right?

*(UINT32 *)Targ = (UINT32) (*(UINT32 *)Targ
+ (mCoffSectionsOffset[Sym->st_shndx] - SymShdr->sh_addr)
- (SecOffset - SecShdr->sh_addr));


Steven Shi
Intel\SSG\STO\UEFI Firmware

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

-----Original Message-----
From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
Sent: Thursday, August 04, 2016 4:46 PM
To: Shi, Steven <steven.shi@intel.com>; Zhu, Yonghong
<yonghong.zhu@intel.com>; Gao, Liming <liming.gao@intel.com>; Justen,
Jordan L <jordan.l.justen@intel.com>; edk2-devel@lists.01.org
Cc: mischief@offblast.org; Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: [PATCH] BaseTools X64: fold PLT relocations into simple relative
references

For X64/GCC, we use position independent code with hidden visibility
to inform the compiler that symbols references are never resolved at
runtime, which removes the need for PLTs and GOTs. However, in some
cases GCC has been reported to still emit PLT based relocations, which
we need to handle in the ELF to PE/COFF perform by GenFw.

Unlike GOT based relocations, which are non-trivial to handle since the
indirections in the code can not be fixed up easily (although relocation
types exist for X64 that annotate relocation targets as suitable for
relaxation), PLT relocations simply point to jump targets, and we can
relax such relocations by resolving them using the symbol directly rather
than via a PLT entry that does nothing more than tail call the function
we already know it is going to call (since all symbol references are
resolved in the same module).

So handle R_X86_64_PLT32 as a R_X86_64_PC32 relocation.

Suggested-by: Steven Shi <steven.shi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
BaseTools/Source/C/GenFw/Elf64Convert.c | 11 +++++++++++
1 file changed, 11 insertions(+)

diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c
b/BaseTools/Source/C/GenFw/Elf64Convert.c
index 944c94b8f8b4..7cbff0df0996 100644
--- a/BaseTools/Source/C/GenFw/Elf64Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
@@ -785,6 +785,17 @@ WriteSections64 (
*(INT32 *)Targ = (INT32)((INT64)(*(INT32 *)Targ) - SymShdr->sh_addr
+ mCoffSectionsOffset[Sym->st_shndx]);
VerboseMsg ("Relocation: 0x%08X", *(UINT32*)Targ);
break;
+
+ case R_X86_64_PLT32:
+ //
+ // Treat R_X86_64_PLT32 relocations as R_X86_64_PC32: this is
+ // possible since we know all code symbol references resolve to
+ // definitions in the same module (UEFI has no shared libraries),
+ // and so there is never a reason to jump via a PLT entry,
+ // allowing us to resolve the reference using the symbol directly.
+ //
+ VerboseMsg ("Treating R_X86_64_PLT32 as R_X86_64_PC32 ...");
+ /* fall through */
case R_X86_64_PC32:
//
// Relative relocation: Symbol - Ip + Addend
--
2.7.4


[PATCH] BaseTools X64: fold PLT relocations into simple relative references

Ard Biesheuvel
 

For X64/GCC, we use position independent code with hidden visibility
to inform the compiler that symbols references are never resolved at
runtime, which removes the need for PLTs and GOTs. However, in some
cases GCC has been reported to still emit PLT based relocations, which
we need to handle in the ELF to PE/COFF perform by GenFw.

Unlike GOT based relocations, which are non-trivial to handle since the
indirections in the code can not be fixed up easily (although relocation
types exist for X64 that annotate relocation targets as suitable for
relaxation), PLT relocations simply point to jump targets, and we can
relax such relocations by resolving them using the symbol directly rather
than via a PLT entry that does nothing more than tail call the function
we already know it is going to call (since all symbol references are
resolved in the same module).

So handle R_X86_64_PLT32 as a R_X86_64_PC32 relocation.

Suggested-by: Steven Shi <steven.shi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
BaseTools/Source/C/GenFw/Elf64Convert.c | 11 +++++++++++
1 file changed, 11 insertions(+)

diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c b/BaseTools/Source/C/GenFw/Elf64Convert.c
index 944c94b8f8b4..7cbff0df0996 100644
--- a/BaseTools/Source/C/GenFw/Elf64Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
@@ -785,6 +785,17 @@ WriteSections64 (
*(INT32 *)Targ = (INT32)((INT64)(*(INT32 *)Targ) - SymShdr->sh_addr + mCoffSectionsOffset[Sym->st_shndx]);
VerboseMsg ("Relocation: 0x%08X", *(UINT32*)Targ);
break;
+
+ case R_X86_64_PLT32:
+ //
+ // Treat R_X86_64_PLT32 relocations as R_X86_64_PC32: this is
+ // possible since we know all code symbol references resolve to
+ // definitions in the same module (UEFI has no shared libraries),
+ // and so there is never a reason to jump via a PLT entry,
+ // allowing us to resolve the reference using the symbol directly.
+ //
+ VerboseMsg ("Treating R_X86_64_PLT32 as R_X86_64_PC32 ...");
+ /* fall through */
case R_X86_64_PC32:
//
// Relative relocation: Symbol - Ip + Addend
--
2.7.4


Re: [PATCH 0/3] Add APIs IsZeroBuffer and IsZeroGuid in BaseMemoryLib

Wu, Hao A
 

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo
Ersek
Sent: Thursday, August 04, 2016 4:07 PM
To: Wu, Hao A
Cc: edk2-devel@ml01.01.org; Leif Lindholm (Linaro address); Ard Biesheuvel
Subject: Re: [edk2] [PATCH 0/3] Add APIs IsZeroBuffer and IsZeroGuid in
BaseMemoryLib

Hello Hao,

On 08/04/16 03:24, Hao Wu wrote:
The patch series will add two APIs in BaseMemoryLib:
1. IsZeroBuffer()
The API is used to check if the contents of a buffer are all zeros.

2. IsZeroGuid()
The API is used to check if the given GUID is a zero GUID.

In order to resolve build issues in SecurityPkg, the series will also
remove the internal implementation of IsZeroBuffer() in modules within
SecurityPkg\Tcg and use the one in BaseMemoryLib instead.
(1) Do you plan to add optimized implementations of IsZeroBuffer() later
on?

For example, in QEMU, the buffer_is_zero() function has optimized
implementations for:
- AVX2
- SSE2
- AArch64

I see one of the library instances is called BaseMemoryLibSse2, so an
SSE2 optimized implementation could be possible.

Also, as far as I understand the example in the QEMU code, for AArch64,
the optimized implementation could go in all of the library instances
that build on AArch64. (QEMU calls the vgetq_lane_u64() function -- I'm
unsure how it would be available in edk2. Perhaps AArch64 assembly would
be necessary.)

Just an idea, of course.
I will hold this patch series and do more research on the optimized
implementations of IsZeroBuffer() for SSE2 and other library instances.


(2) The edk2 tree contains a number of zero GUID comparisons:

$ git grep -i -e zeroguid --and -e compareguid

BaseTools/Source/C/GenFfs/GenFfs.c:749: if (CompareGuid (&FileGuid,
&mZeroGuid) == 0) {
BaseTools/Source/C/GenFv/GenFvInternalLib.c:4134: if (CompareGuid
(&mCapDataInfo.CapGuid, &mZeroGuid) == 0) {
BaseTools/Source/C/GenSec/GenSec.c:854: if (CompareGuid (VendorGuid,
&mZeroGuid) == 0) {
BaseTools/Source/C/GenSec/GenSec.c:900: if (CompareGuid (VendorGuid,
&mZeroGuid) == 0) {
BaseTools/Source/C/GenSec/GenSec.c:1368: if ((SectType !=
EFI_SECTION_GUID_DEFINED) && (CompareGuid (&VendorGuid,
&mZeroGuid) != 0)) {
BaseTools/Source/C/GenSec/GenSec.c:1421: if (InputFileAlign != NULL &&
(CompareGuid (&VendorGuid, &mZeroGuid) != 0)) {
EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/Utility.c:717:
if (FormSetGuid == NULL || CompareGuid (FormSetGuid, &gZeroGuid)) {
EdkCompatibilityPkg/Compatibility/PiSmbiosRecordOnDataHubSmbiosRecordT
hunk/Translate.c:85: for (; !CompareGuid
(&(mConversionTable[Index].SubClass), &gZeroGuid); Index++) {
EdkCompatibilityPkg/Compatibility/PiSmbiosRecordOnDataHubSmbiosRecordT
hunk/Translate.c:96: if (CompareGuid (&(mConversionTable[Index].SubClass),
&gZeroGuid)) {
EdkCompatibilityPkg/Sample/Tools/Source/GenAprioriFile/GenAprioriFile.c:196:
if (CompareGuid (&GuidIn, &ZeroGuid) != 0) {
EdkCompatibilityPkg/Sample/Tools/Source/GenFfsFile/GenFfsFile.c:1328:
if (CompareGuid (&SignGuid, &mZeroGuid) != 0) {
EmbeddedPkg/Library/EfiFileLib/EfiFileLib.c:1348: if (CompareGuid (&File-
FvNameGuid, &gZeroGuid)) {
IntelFrameworkModulePkg/Universal/DataHubDxe/DataHub.c:142:
(CompareGuid (&FilterEntry->FilterDataRecordGuid, &gZeroGuid) ||
MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c:258: if
(!CompareGuid (&DriverInfo->FileName, &gZeroGuid)) {
MdeModulePkg/Library/UefiBootManagerLib/BmDriverHealth.c:449: if
(CompareGuid (PcdGetPtr (PcdDriverHealthConfigureForm), &gZeroGuid)) {
MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiGenFromFv.c:375: for
(Index = 0; !CompareGuid (&DriverGuidArray[Index], &gZeroGuid); Index++) {
MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiGenFromFv.c:424: if
(CompareGuid (&DriverGuidArray[0], &gZeroGuid)) {
MdeModulePkg/Universal/SetupBrowserDxe/Expression.c:2832: } else if
(CompareGuid (&OpCode->Guid, &gZeroGuid) != 0) {
MdeModulePkg/Universal/SetupBrowserDxe/Presentation.c:361: if
(!CompareGuid (&Statement->RefreshGuid, &gZeroGuid)) {
MdeModulePkg/Universal/SetupBrowserDxe/Presentation.c:376: if
((!CompareGuid (&Statement->RefreshGuid, &gZeroGuid)) || (Statement-
RefreshInterval != 0)) {
MdeModulePkg/Universal/SetupBrowserDxe/Presentation.c:631: if
(!CompareGuid (&gCurrentSelection->Form->RefreshGuid, &gZeroGuid)) {
MdeModulePkg/Universal/SetupBrowserDxe/Presentation.c:1413: } else if
(!CompareGuid (&Statement->HiiValue.Value.ref.FormSetGuid, &gZeroGuid)) {
MdeModulePkg/Universal/SetupBrowserDxe/Setup.c:184: if
(CompareGuid (&MenuList->FormSetGuid, &gZeroGuid)) {
MdeModulePkg/Universal/SetupBrowserDxe/Setup.c:5659: if
(CompareGuid (FormSetGuid, &gZeroGuid) ||
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c:376: if
(CompareGuid (&VendorGuid, &gZeroGuid)) {
SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c:205:
if (!CompareGuid (&PartitionEntry->PartitionTypeGUID, &gZeroGuid)) {
SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c:241:
if (!CompareGuid (&PartitionEntry->PartitionTypeGUID, &gZeroGuid)) {
SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLib.c:205:
if (!CompareGuid (&PartitionEntry->PartitionTypeGUID, &gZeroGuid)) {
SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLib.c:239:
if (!CompareGuid (&PartitionEntry->PartitionTypeGUID, &gZeroGuid)) {

Do you plan to migrate these source files to the new IsZeroGuid()
function?

(There might be more -- "zeroguid" and "compareguid" could be on
different lines, so perhaps it's better to search for just "zeroguid",
and audit each location separately.)
Yes, we plan to replace the usages of "compareguid with zeroguid" with
the new API. It will be done independently by another patch later.

For the above-listed results, I think we won't handle the cases used in
tools. Since these codes won't be able to use the BaseMemoryLib.


(3) I think patch #3 should be implemented differently -- I believe the
current series can break bisection between patch #2 and patch #3.

I suggest to first rename the IsZeroBuffer() functions in
SecurityPkg/Tcg to IsZeroBufferInternal(), as patch #1.

Then add IsZeroBuffer() and IsZeroGuid() to the BaseMemoryLib instances,
as patch #2 and patch #3.

Finally, switch SecurityPkg/Tcg from IsZeroBufferInternal() to
IsZeroBuffer() in patch #4.

What do you think?
Yes, I will follow this approach when sending out the next version of patch.

Best Regards,
Hao Wu


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


Re: [PATCH 0/3] Add APIs IsZeroBuffer and IsZeroGuid in BaseMemoryLib

Laszlo Ersek
 

Hello Hao,

On 08/04/16 03:24, Hao Wu wrote:
The patch series will add two APIs in BaseMemoryLib:
1. IsZeroBuffer()
The API is used to check if the contents of a buffer are all zeros.

2. IsZeroGuid()
The API is used to check if the given GUID is a zero GUID.

In order to resolve build issues in SecurityPkg, the series will also
remove the internal implementation of IsZeroBuffer() in modules within
SecurityPkg\Tcg and use the one in BaseMemoryLib instead.
(1) Do you plan to add optimized implementations of IsZeroBuffer() later
on?

For example, in QEMU, the buffer_is_zero() function has optimized
implementations for:
- AVX2
- SSE2
- AArch64

I see one of the library instances is called BaseMemoryLibSse2, so an
SSE2 optimized implementation could be possible.

Also, as far as I understand the example in the QEMU code, for AArch64,
the optimized implementation could go in all of the library instances
that build on AArch64. (QEMU calls the vgetq_lane_u64() function -- I'm
unsure how it would be available in edk2. Perhaps AArch64 assembly would
be necessary.)

Just an idea, of course.

(2) The edk2 tree contains a number of zero GUID comparisons:

$ git grep -i -e zeroguid --and -e compareguid

BaseTools/Source/C/GenFfs/GenFfs.c:749: if (CompareGuid (&FileGuid, &mZeroGuid) == 0) {
BaseTools/Source/C/GenFv/GenFvInternalLib.c:4134: if (CompareGuid (&mCapDataInfo.CapGuid, &mZeroGuid) == 0) {
BaseTools/Source/C/GenSec/GenSec.c:854: if (CompareGuid (VendorGuid, &mZeroGuid) == 0) {
BaseTools/Source/C/GenSec/GenSec.c:900: if (CompareGuid (VendorGuid, &mZeroGuid) == 0) {
BaseTools/Source/C/GenSec/GenSec.c:1368: if ((SectType != EFI_SECTION_GUID_DEFINED) && (CompareGuid (&VendorGuid, &mZeroGuid) != 0)) {
BaseTools/Source/C/GenSec/GenSec.c:1421: if (InputFileAlign != NULL && (CompareGuid (&VendorGuid, &mZeroGuid) != 0)) {
EdkCompatibilityPkg/Compatibility/FrameworkHiiOnUefiHiiThunk/Utility.c:717: if (FormSetGuid == NULL || CompareGuid (FormSetGuid, &gZeroGuid)) {
EdkCompatibilityPkg/Compatibility/PiSmbiosRecordOnDataHubSmbiosRecordThunk/Translate.c:85: for (; !CompareGuid (&(mConversionTable[Index].SubClass), &gZeroGuid); Index++) {
EdkCompatibilityPkg/Compatibility/PiSmbiosRecordOnDataHubSmbiosRecordThunk/Translate.c:96: if (CompareGuid (&(mConversionTable[Index].SubClass), &gZeroGuid)) {
EdkCompatibilityPkg/Sample/Tools/Source/GenAprioriFile/GenAprioriFile.c:196: if (CompareGuid (&GuidIn, &ZeroGuid) != 0) {
EdkCompatibilityPkg/Sample/Tools/Source/GenFfsFile/GenFfsFile.c:1328: if (CompareGuid (&SignGuid, &mZeroGuid) != 0) {
EmbeddedPkg/Library/EfiFileLib/EfiFileLib.c:1348: if (CompareGuid (&File->FvNameGuid, &gZeroGuid)) {
IntelFrameworkModulePkg/Universal/DataHubDxe/DataHub.c:142: (CompareGuid (&FilterEntry->FilterDataRecordGuid, &gZeroGuid) ||
MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c:258: if (!CompareGuid (&DriverInfo->FileName, &gZeroGuid)) {
MdeModulePkg/Library/UefiBootManagerLib/BmDriverHealth.c:449: if (CompareGuid (PcdGetPtr (PcdDriverHealthConfigureForm), &gZeroGuid)) {
MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiGenFromFv.c:375: for (Index = 0; !CompareGuid (&DriverGuidArray[Index], &gZeroGuid); Index++) {
MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiGenFromFv.c:424: if (CompareGuid (&DriverGuidArray[0], &gZeroGuid)) {
MdeModulePkg/Universal/SetupBrowserDxe/Expression.c:2832: } else if (CompareGuid (&OpCode->Guid, &gZeroGuid) != 0) {
MdeModulePkg/Universal/SetupBrowserDxe/Presentation.c:361: if (!CompareGuid (&Statement->RefreshGuid, &gZeroGuid)) {
MdeModulePkg/Universal/SetupBrowserDxe/Presentation.c:376: if ((!CompareGuid (&Statement->RefreshGuid, &gZeroGuid)) || (Statement->RefreshInterval != 0)) {
MdeModulePkg/Universal/SetupBrowserDxe/Presentation.c:631: if (!CompareGuid (&gCurrentSelection->Form->RefreshGuid, &gZeroGuid)) {
MdeModulePkg/Universal/SetupBrowserDxe/Presentation.c:1413: } else if (!CompareGuid (&Statement->HiiValue.Value.ref.FormSetGuid, &gZeroGuid)) {
MdeModulePkg/Universal/SetupBrowserDxe/Setup.c:184: if (CompareGuid (&MenuList->FormSetGuid, &gZeroGuid)) {
MdeModulePkg/Universal/SetupBrowserDxe/Setup.c:5659: if (CompareGuid (FormSetGuid, &gZeroGuid) ||
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c:376: if (CompareGuid (&VendorGuid, &gZeroGuid)) {
SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c:205: if (!CompareGuid (&PartitionEntry->PartitionTypeGUID, &gZeroGuid)) {
SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c:241: if (!CompareGuid (&PartitionEntry->PartitionTypeGUID, &gZeroGuid)) {
SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLib.c:205: if (!CompareGuid (&PartitionEntry->PartitionTypeGUID, &gZeroGuid)) {
SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLib.c:239: if (!CompareGuid (&PartitionEntry->PartitionTypeGUID, &gZeroGuid)) {
Do you plan to migrate these source files to the new IsZeroGuid()
function?

(There might be more -- "zeroguid" and "compareguid" could be on
different lines, so perhaps it's better to search for just "zeroguid",
and audit each location separately.)

(3) I think patch #3 should be implemented differently -- I believe the
current series can break bisection between patch #2 and patch #3.

I suggest to first rename the IsZeroBuffer() functions in
SecurityPkg/Tcg to IsZeroBufferInternal(), as patch #1.

Then add IsZeroBuffer() and IsZeroGuid() to the BaseMemoryLib instances,
as patch #2 and patch #3.

Finally, switch SecurityPkg/Tcg from IsZeroBufferInternal() to
IsZeroBuffer() in patch #4.

What do you think?

Thanks
Laszlo


[PATCH 3/3] SecurityPkg Tcg2: Remove internal implementation of IsZeroBuffer()

Wu, Hao A
 

This commit removes the internal implementation of the function
IsZeroBuffer(). Instead, it will use the one from BaseMemoryLib.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
---
SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c | 27 ---------------------------
SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c | 27 ---------------------------
SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c | 27 ---------------------------
3 files changed, 81 deletions(-)

diff --git a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c
index db38bd4..5f4420c 100644
--- a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c
+++ b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c
@@ -617,33 +617,6 @@ FillBufferWithTCG2EventLogFormat (
}

/**
- Check if buffer is all zero.
-
- @param[in] Buffer Buffer to be checked.
- @param[in] BufferSize Size of buffer to be checked.
-
- @retval TRUE Buffer is all zero.
- @retval FALSE Buffer is not all zero.
-**/
-BOOLEAN
-IsZeroBuffer (
- IN VOID *Buffer,
- IN UINTN BufferSize
- )
-{
- UINT8 *BufferData;
- UINTN Index;
-
- BufferData = Buffer;
- for (Index = 0; Index < BufferSize; Index++) {
- if (BufferData[Index] != 0) {
- return FALSE;
- }
- }
- return TRUE;
-}
-
-/**
This function publish the TCG2 configuration Form for TPM device.

@param[in, out] PrivateData Points to TCG2 configuration private data.
diff --git a/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c b/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c
index 95219c0..319f245 100644
--- a/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c
+++ b/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c
@@ -202,33 +202,6 @@ InternalDumpHex (
}

/**
- Check if buffer is all zero.
-
- @param[in] Buffer Buffer to be checked.
- @param[in] BufferSize Size of buffer to be checked.
-
- @retval TRUE Buffer is all zero.
- @retval FALSE Buffer is not all zero.
-**/
-BOOLEAN
-IsZeroBuffer (
- IN VOID *Buffer,
- IN UINTN BufferSize
- )
-{
- UINT8 *BufferData;
- UINTN Index;
-
- BufferData = Buffer;
- for (Index = 0; Index < BufferSize; Index++) {
- if (BufferData[Index] != 0) {
- return FALSE;
- }
- }
- return TRUE;
-}
-
-/**
Get All processors EFI_CPU_LOCATION in system. LocationBuf is allocated inside the function
Caller is responsible to free LocationBuf.

diff --git a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
index a830ba8..0d779f1 100644
--- a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
+++ b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
@@ -225,33 +225,6 @@ EndofPeiSignalNotifyCallBack (
}

/**
- Check if buffer is all zero.
-
- @param[in] Buffer Buffer to be checked.
- @param[in] BufferSize Size of buffer to be checked.
-
- @retval TRUE Buffer is all zero.
- @retval FALSE Buffer is not all zero.
-**/
-BOOLEAN
-IsZeroBuffer (
- IN VOID *Buffer,
- IN UINTN BufferSize
- )
-{
- UINT8 *BufferData;
- UINTN Index;
-
- BufferData = Buffer;
- for (Index = 0; Index < BufferSize; Index++) {
- if (BufferData[Index] != 0) {
- return FALSE;
- }
- }
- return TRUE;
-}
-
-/**
Get TPML_DIGEST_VALUES data size.

@param[in] DigestList TPML_DIGEST_VALUES data.
--
1.9.5.msysgit.0


[PATCH 2/3] MdePkg BaseMemoryLib: Add implementation of API IsZeroBuffer()

Wu, Hao A
 

Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
---
MdePkg/Include/Library/BaseMemoryLib.h | 23 ++++++++
MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf | 1 +
MdePkg/Library/BaseMemoryLib/IsZeroBuffer.c | 65 ++++++++++++++++++++++
.../Library/BaseMemoryLibMmx/BaseMemoryLibMmx.inf | 1 +
MdePkg/Library/BaseMemoryLibMmx/IsZeroBuffer.c | 65 ++++++++++++++++++++++
.../BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf | 2 +
MdePkg/Library/BaseMemoryLibOptDxe/IsZeroBuffer.c | 65 ++++++++++++++++++++++
.../BaseMemoryLibOptPei/BaseMemoryLibOptPei.inf | 2 +
MdePkg/Library/BaseMemoryLibOptPei/IsZeroBuffer.c | 65 ++++++++++++++++++++++
.../BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf | 1 +
MdePkg/Library/BaseMemoryLibRepStr/IsZeroBuffer.c | 65 ++++++++++++++++++++++
.../BaseMemoryLibSse2/BaseMemoryLibSse2.inf | 1 +
MdePkg/Library/BaseMemoryLibSse2/IsZeroBuffer.c | 65 ++++++++++++++++++++++
MdePkg/Library/PeiMemoryLib/IsZeroBuffer.c | 65 ++++++++++++++++++++++
MdePkg/Library/PeiMemoryLib/PeiMemoryLib.inf | 1 +
MdePkg/Library/UefiMemoryLib/IsZeroBuffer.c | 65 ++++++++++++++++++++++
MdePkg/Library/UefiMemoryLib/UefiMemoryLib.inf | 1 +
17 files changed, 553 insertions(+)
create mode 100644 MdePkg/Library/BaseMemoryLib/IsZeroBuffer.c
create mode 100644 MdePkg/Library/BaseMemoryLibMmx/IsZeroBuffer.c
create mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/IsZeroBuffer.c
create mode 100644 MdePkg/Library/BaseMemoryLibOptPei/IsZeroBuffer.c
create mode 100644 MdePkg/Library/BaseMemoryLibRepStr/IsZeroBuffer.c
create mode 100644 MdePkg/Library/BaseMemoryLibSse2/IsZeroBuffer.c
create mode 100644 MdePkg/Library/PeiMemoryLib/IsZeroBuffer.c
create mode 100644 MdePkg/Library/UefiMemoryLib/IsZeroBuffer.c

diff --git a/MdePkg/Include/Library/BaseMemoryLib.h b/MdePkg/Include/Library/BaseMemoryLib.h
index 5a57dee..1338c27 100644
--- a/MdePkg/Include/Library/BaseMemoryLib.h
+++ b/MdePkg/Include/Library/BaseMemoryLib.h
@@ -463,4 +463,27 @@ IsZeroGuid (
IN CONST GUID *Guid
);

+/**
+ Checks if the contents of a buffer are all zeros.
+
+ This function checks whether the contents of a buffer are all zeros. If the
+ contents are all zeros, return TRUE. Otherwise, return FALSE.
+
+ If Length > 0 and Buffer is NULL, then ASSERT().
+ If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
+
+ @param Buffer The pointer to the buffer to be checked.
+ @param Length The size of the buffer (in bytes) to be checked.
+
+ @retval TRUE Contents of the buffer are all zeros.
+ @retval FALSE Contents of the buffer are not all zeros.
+
+**/
+BOOLEAN
+EFIAPI
+IsZeroBuffer (
+ IN CONST VOID *Buffer,
+ IN UINTN Length
+ );
+
#endif
diff --git a/MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf b/MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
index 5dfab35..51b4d16 100644
--- a/MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
+++ b/MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
@@ -45,6 +45,7 @@
MemLibGeneric.c
MemLibGuid.c
CopyMem.c
+ IsZeroBuffer.c
MemLibInternals.h

[Packages]
diff --git a/MdePkg/Library/BaseMemoryLib/IsZeroBuffer.c b/MdePkg/Library/BaseMemoryLib/IsZeroBuffer.c
new file mode 100644
index 0000000..fda0c7c
--- /dev/null
+++ b/MdePkg/Library/BaseMemoryLib/IsZeroBuffer.c
@@ -0,0 +1,65 @@
+/** @file
+ Implementation of IsZeroBuffer function.
+
+ The following BaseMemoryLib instances contain the same copy of this file:
+
+ BaseMemoryLib
+ BaseMemoryLibMmx
+ BaseMemoryLibSse2
+ BaseMemoryLibRepStr
+ BaseMemoryLibOptDxe
+ BaseMemoryLibOptPei
+ PeiMemoryLib
+ UefiMemoryLib
+
+ Copyright (c) 2016, Intel Corporation. All rights reserved.<BR>
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD License
+ which accompanies this distribution. The full text of the license may be found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include <Base.h>
+#include <Library/DebugLib.h>
+
+/**
+ Checks if the contents of a buffer are all zeros.
+
+ This function checks whether the contents of a buffer are all zeros. If the
+ contents are all zeros, return TRUE. Otherwise, return FALSE.
+
+ If Length > 0 and Buffer is NULL, then ASSERT().
+ If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
+
+ @param Buffer The pointer to the buffer to be checked.
+ @param Length The size of the buffer (in bytes) to be checked.
+
+ @retval TRUE Contents of the buffer are all zeros.
+ @retval FALSE Contents of the buffer are not all zeros.
+
+**/
+BOOLEAN
+EFIAPI
+IsZeroBuffer (
+ IN CONST VOID *Buffer,
+ IN UINTN Length
+ )
+{
+ CONST UINT8 *BufferData;
+ UINTN Index;
+
+ ASSERT (!(Buffer == NULL && Length > 0));
+ ASSERT ((Length - 1) <= (MAX_ADDRESS - (UINTN)Buffer));
+
+ BufferData = Buffer;
+ for (Index = 0; Index < Length; Index++) {
+ if (BufferData[Index] != 0) {
+ return FALSE;
+ }
+ }
+ return TRUE;
+}
diff --git a/MdePkg/Library/BaseMemoryLibMmx/BaseMemoryLibMmx.inf b/MdePkg/Library/BaseMemoryLibMmx/BaseMemoryLibMmx.inf
index a609073..59261f9 100644
--- a/MdePkg/Library/BaseMemoryLibMmx/BaseMemoryLibMmx.inf
+++ b/MdePkg/Library/BaseMemoryLibMmx/BaseMemoryLibMmx.inf
@@ -47,6 +47,7 @@
SetMemWrapper.c
CopyMemWrapper.c
MemLibGuid.c
+ IsZeroBuffer.c
MemLibInternals.h

[Sources.Ia32]
diff --git a/MdePkg/Library/BaseMemoryLibMmx/IsZeroBuffer.c b/MdePkg/Library/BaseMemoryLibMmx/IsZeroBuffer.c
new file mode 100644
index 0000000..fda0c7c
--- /dev/null
+++ b/MdePkg/Library/BaseMemoryLibMmx/IsZeroBuffer.c
@@ -0,0 +1,65 @@
+/** @file
+ Implementation of IsZeroBuffer function.
+
+ The following BaseMemoryLib instances contain the same copy of this file:
+
+ BaseMemoryLib
+ BaseMemoryLibMmx
+ BaseMemoryLibSse2
+ BaseMemoryLibRepStr
+ BaseMemoryLibOptDxe
+ BaseMemoryLibOptPei
+ PeiMemoryLib
+ UefiMemoryLib
+
+ Copyright (c) 2016, Intel Corporation. All rights reserved.<BR>
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD License
+ which accompanies this distribution. The full text of the license may be found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include <Base.h>
+#include <Library/DebugLib.h>
+
+/**
+ Checks if the contents of a buffer are all zeros.
+
+ This function checks whether the contents of a buffer are all zeros. If the
+ contents are all zeros, return TRUE. Otherwise, return FALSE.
+
+ If Length > 0 and Buffer is NULL, then ASSERT().
+ If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
+
+ @param Buffer The pointer to the buffer to be checked.
+ @param Length The size of the buffer (in bytes) to be checked.
+
+ @retval TRUE Contents of the buffer are all zeros.
+ @retval FALSE Contents of the buffer are not all zeros.
+
+**/
+BOOLEAN
+EFIAPI
+IsZeroBuffer (
+ IN CONST VOID *Buffer,
+ IN UINTN Length
+ )
+{
+ CONST UINT8 *BufferData;
+ UINTN Index;
+
+ ASSERT (!(Buffer == NULL && Length > 0));
+ ASSERT ((Length - 1) <= (MAX_ADDRESS - (UINTN)Buffer));
+
+ BufferData = Buffer;
+ for (Index = 0; Index < Length; Index++) {
+ if (BufferData[Index] != 0) {
+ return FALSE;
+ }
+ }
+ return TRUE;
+}
diff --git a/MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf b/MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf
index e637034..a75270b 100644
--- a/MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf
+++ b/MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf
@@ -90,6 +90,7 @@
SetMemWrapper.c
CopyMemWrapper.c
MemLibGuid.c
+ IsZeroBuffer.c

[Sources.X64]
X64/ScanMem64.nasm
@@ -137,6 +138,7 @@
SetMemWrapper.c
CopyMemWrapper.c
MemLibGuid.c
+ IsZeroBuffer.c

[Packages]
MdePkg/MdePkg.dec
diff --git a/MdePkg/Library/BaseMemoryLibOptDxe/IsZeroBuffer.c b/MdePkg/Library/BaseMemoryLibOptDxe/IsZeroBuffer.c
new file mode 100644
index 0000000..fda0c7c
--- /dev/null
+++ b/MdePkg/Library/BaseMemoryLibOptDxe/IsZeroBuffer.c
@@ -0,0 +1,65 @@
+/** @file
+ Implementation of IsZeroBuffer function.
+
+ The following BaseMemoryLib instances contain the same copy of this file:
+
+ BaseMemoryLib
+ BaseMemoryLibMmx
+ BaseMemoryLibSse2
+ BaseMemoryLibRepStr
+ BaseMemoryLibOptDxe
+ BaseMemoryLibOptPei
+ PeiMemoryLib
+ UefiMemoryLib
+
+ Copyright (c) 2016, Intel Corporation. All rights reserved.<BR>
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD License
+ which accompanies this distribution. The full text of the license may be found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include <Base.h>
+#include <Library/DebugLib.h>
+
+/**
+ Checks if the contents of a buffer are all zeros.
+
+ This function checks whether the contents of a buffer are all zeros. If the
+ contents are all zeros, return TRUE. Otherwise, return FALSE.
+
+ If Length > 0 and Buffer is NULL, then ASSERT().
+ If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
+
+ @param Buffer The pointer to the buffer to be checked.
+ @param Length The size of the buffer (in bytes) to be checked.
+
+ @retval TRUE Contents of the buffer are all zeros.
+ @retval FALSE Contents of the buffer are not all zeros.
+
+**/
+BOOLEAN
+EFIAPI
+IsZeroBuffer (
+ IN CONST VOID *Buffer,
+ IN UINTN Length
+ )
+{
+ CONST UINT8 *BufferData;
+ UINTN Index;
+
+ ASSERT (!(Buffer == NULL && Length > 0));
+ ASSERT ((Length - 1) <= (MAX_ADDRESS - (UINTN)Buffer));
+
+ BufferData = Buffer;
+ for (Index = 0; Index < Length; Index++) {
+ if (BufferData[Index] != 0) {
+ return FALSE;
+ }
+ }
+ return TRUE;
+}
diff --git a/MdePkg/Library/BaseMemoryLibOptPei/BaseMemoryLibOptPei.inf b/MdePkg/Library/BaseMemoryLibOptPei/BaseMemoryLibOptPei.inf
index ff60e9e..bd915eb 100644
--- a/MdePkg/Library/BaseMemoryLibOptPei/BaseMemoryLibOptPei.inf
+++ b/MdePkg/Library/BaseMemoryLibOptPei/BaseMemoryLibOptPei.inf
@@ -90,6 +90,7 @@
SetMemWrapper.c
CopyMemWrapper.c
MemLibGuid.c
+ IsZeroBuffer.c

[Sources.X64]
X64/ScanMem64.nasm
@@ -137,6 +138,7 @@
SetMemWrapper.c
CopyMemWrapper.c
MemLibGuid.c
+ IsZeroBuffer.c


[Packages]
diff --git a/MdePkg/Library/BaseMemoryLibOptPei/IsZeroBuffer.c b/MdePkg/Library/BaseMemoryLibOptPei/IsZeroBuffer.c
new file mode 100644
index 0000000..fda0c7c
--- /dev/null
+++ b/MdePkg/Library/BaseMemoryLibOptPei/IsZeroBuffer.c
@@ -0,0 +1,65 @@
+/** @file
+ Implementation of IsZeroBuffer function.
+
+ The following BaseMemoryLib instances contain the same copy of this file:
+
+ BaseMemoryLib
+ BaseMemoryLibMmx
+ BaseMemoryLibSse2
+ BaseMemoryLibRepStr
+ BaseMemoryLibOptDxe
+ BaseMemoryLibOptPei
+ PeiMemoryLib
+ UefiMemoryLib
+
+ Copyright (c) 2016, Intel Corporation. All rights reserved.<BR>
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD License
+ which accompanies this distribution. The full text of the license may be found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include <Base.h>
+#include <Library/DebugLib.h>
+
+/**
+ Checks if the contents of a buffer are all zeros.
+
+ This function checks whether the contents of a buffer are all zeros. If the
+ contents are all zeros, return TRUE. Otherwise, return FALSE.
+
+ If Length > 0 and Buffer is NULL, then ASSERT().
+ If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
+
+ @param Buffer The pointer to the buffer to be checked.
+ @param Length The size of the buffer (in bytes) to be checked.
+
+ @retval TRUE Contents of the buffer are all zeros.
+ @retval FALSE Contents of the buffer are not all zeros.
+
+**/
+BOOLEAN
+EFIAPI
+IsZeroBuffer (
+ IN CONST VOID *Buffer,
+ IN UINTN Length
+ )
+{
+ CONST UINT8 *BufferData;
+ UINTN Index;
+
+ ASSERT (!(Buffer == NULL && Length > 0));
+ ASSERT ((Length - 1) <= (MAX_ADDRESS - (UINTN)Buffer));
+
+ BufferData = Buffer;
+ for (Index = 0; Index < Length; Index++) {
+ if (BufferData[Index] != 0) {
+ return FALSE;
+ }
+ }
+ return TRUE;
+}
diff --git a/MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf b/MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
index 9d7ce4b..aac7865 100644
--- a/MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
+++ b/MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
@@ -44,6 +44,7 @@
SetMemWrapper.c
CopyMemWrapper.c
MemLibGuid.c
+ IsZeroBuffer.c

[Sources.Ia32]
Ia32/ScanMem64.nasm
diff --git a/MdePkg/Library/BaseMemoryLibRepStr/IsZeroBuffer.c b/MdePkg/Library/BaseMemoryLibRepStr/IsZeroBuffer.c
new file mode 100644
index 0000000..fda0c7c
--- /dev/null
+++ b/MdePkg/Library/BaseMemoryLibRepStr/IsZeroBuffer.c
@@ -0,0 +1,65 @@
+/** @file
+ Implementation of IsZeroBuffer function.
+
+ The following BaseMemoryLib instances contain the same copy of this file:
+
+ BaseMemoryLib
+ BaseMemoryLibMmx
+ BaseMemoryLibSse2
+ BaseMemoryLibRepStr
+ BaseMemoryLibOptDxe
+ BaseMemoryLibOptPei
+ PeiMemoryLib
+ UefiMemoryLib
+
+ Copyright (c) 2016, Intel Corporation. All rights reserved.<BR>
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD License
+ which accompanies this distribution. The full text of the license may be found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include <Base.h>
+#include <Library/DebugLib.h>
+
+/**
+ Checks if the contents of a buffer are all zeros.
+
+ This function checks whether the contents of a buffer are all zeros. If the
+ contents are all zeros, return TRUE. Otherwise, return FALSE.
+
+ If Length > 0 and Buffer is NULL, then ASSERT().
+ If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
+
+ @param Buffer The pointer to the buffer to be checked.
+ @param Length The size of the buffer (in bytes) to be checked.
+
+ @retval TRUE Contents of the buffer are all zeros.
+ @retval FALSE Contents of the buffer are not all zeros.
+
+**/
+BOOLEAN
+EFIAPI
+IsZeroBuffer (
+ IN CONST VOID *Buffer,
+ IN UINTN Length
+ )
+{
+ CONST UINT8 *BufferData;
+ UINTN Index;
+
+ ASSERT (!(Buffer == NULL && Length > 0));
+ ASSERT ((Length - 1) <= (MAX_ADDRESS - (UINTN)Buffer));
+
+ BufferData = Buffer;
+ for (Index = 0; Index < Length; Index++) {
+ if (BufferData[Index] != 0) {
+ return FALSE;
+ }
+ }
+ return TRUE;
+}
diff --git a/MdePkg/Library/BaseMemoryLibSse2/BaseMemoryLibSse2.inf b/MdePkg/Library/BaseMemoryLibSse2/BaseMemoryLibSse2.inf
index a78d823..2919827 100644
--- a/MdePkg/Library/BaseMemoryLibSse2/BaseMemoryLibSse2.inf
+++ b/MdePkg/Library/BaseMemoryLibSse2/BaseMemoryLibSse2.inf
@@ -43,6 +43,7 @@
SetMemWrapper.c
CopyMemWrapper.c
MemLibGuid.c
+ IsZeroBuffer.c

[Sources.Ia32]
Ia32/ScanMem64.nasm
diff --git a/MdePkg/Library/BaseMemoryLibSse2/IsZeroBuffer.c b/MdePkg/Library/BaseMemoryLibSse2/IsZeroBuffer.c
new file mode 100644
index 0000000..6a3a2c1
--- /dev/null
+++ b/MdePkg/Library/BaseMemoryLibSse2/IsZeroBuffer.c
@@ -0,0 +1,65 @@
+/** @file
+ Implementation of IsZeroBuffer function.
+
+ The following BaseMemoryLib instances contain the same copy of this file:
+
+ BaseMemoryLib
+ BaseMemoryLibMmx
+ BaseMemoryLibSse2
+ BaseMemoryLibRepStr
+ BaseMemoryLibOptDxe
+ BaseMemoryLibOptPei
+ PeiMemoryLib
+ UefiMemoryLib
+
+ Copyright (c) 2016, Intel Corporation. All rights reserved.<BR>
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD License
+ which accompanies this distribution. The full text of the license may be found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include <Base.h>
+#include <Library/DebugLib.h>
+
+/**
+ Checks if the contents of a buffer are all zeros.
+
+ This function checks whether the contents of a buffer are all zeros. If the
+ contents are all zeros, return TRUE. Otherwise, return FALSE.
+
+ If Length > 0 and Buffer is NULL, then ASSERT().
+ If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
+
+ @param Buffer The pointer to the buffer to be checked.
+ @param Length The size of the buffer (in bytes) to be checked.
+
+ @retval TRUE Contents of the buffer are all zeros.
+ @retval FALSE Contents of the buffer are not all zeros.
+
+**/
+BOOLEAN
+EFIAPI
+IsZeroBuffer (
+ IN CONST VOID *Buffer,
+ IN UINTN Length
+ )
+{
+ CONST UINT8 *BufferData;
+ UINTN Index;
+
+ ASSERT (!(Buffer == NULL && Length > 0));
+ ASSERT ((Length - 1) <= (MAX_ADDRESS - (UINTN)Buffer));
+
+ BufferData = Buffer;
+ for (Index = 0; Index < Length; Index++) {
+ if (BufferData[Index] != 0) {
+ return FALSE;
+ }
+ }
+ return TRUE;
+}
diff --git a/MdePkg/Library/PeiMemoryLib/IsZeroBuffer.c b/MdePkg/Library/PeiMemoryLib/IsZeroBuffer.c
new file mode 100644
index 0000000..fda0c7c
--- /dev/null
+++ b/MdePkg/Library/PeiMemoryLib/IsZeroBuffer.c
@@ -0,0 +1,65 @@
+/** @file
+ Implementation of IsZeroBuffer function.
+
+ The following BaseMemoryLib instances contain the same copy of this file:
+
+ BaseMemoryLib
+ BaseMemoryLibMmx
+ BaseMemoryLibSse2
+ BaseMemoryLibRepStr
+ BaseMemoryLibOptDxe
+ BaseMemoryLibOptPei
+ PeiMemoryLib
+ UefiMemoryLib
+
+ Copyright (c) 2016, Intel Corporation. All rights reserved.<BR>
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD License
+ which accompanies this distribution. The full text of the license may be found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include <Base.h>
+#include <Library/DebugLib.h>
+
+/**
+ Checks if the contents of a buffer are all zeros.
+
+ This function checks whether the contents of a buffer are all zeros. If the
+ contents are all zeros, return TRUE. Otherwise, return FALSE.
+
+ If Length > 0 and Buffer is NULL, then ASSERT().
+ If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
+
+ @param Buffer The pointer to the buffer to be checked.
+ @param Length The size of the buffer (in bytes) to be checked.
+
+ @retval TRUE Contents of the buffer are all zeros.
+ @retval FALSE Contents of the buffer are not all zeros.
+
+**/
+BOOLEAN
+EFIAPI
+IsZeroBuffer (
+ IN CONST VOID *Buffer,
+ IN UINTN Length
+ )
+{
+ CONST UINT8 *BufferData;
+ UINTN Index;
+
+ ASSERT (!(Buffer == NULL && Length > 0));
+ ASSERT ((Length - 1) <= (MAX_ADDRESS - (UINTN)Buffer));
+
+ BufferData = Buffer;
+ for (Index = 0; Index < Length; Index++) {
+ if (BufferData[Index] != 0) {
+ return FALSE;
+ }
+ }
+ return TRUE;
+}
diff --git a/MdePkg/Library/PeiMemoryLib/PeiMemoryLib.inf b/MdePkg/Library/PeiMemoryLib/PeiMemoryLib.inf
index 58af9d0..9760639 100644
--- a/MdePkg/Library/PeiMemoryLib/PeiMemoryLib.inf
+++ b/MdePkg/Library/PeiMemoryLib/PeiMemoryLib.inf
@@ -45,6 +45,7 @@
MemLibGeneric.c
MemLibGuid.c
MemLib.c
+ IsZeroBuffer.c
MemLibInternals.h


diff --git a/MdePkg/Library/UefiMemoryLib/IsZeroBuffer.c b/MdePkg/Library/UefiMemoryLib/IsZeroBuffer.c
new file mode 100644
index 0000000..fda0c7c
--- /dev/null
+++ b/MdePkg/Library/UefiMemoryLib/IsZeroBuffer.c
@@ -0,0 +1,65 @@
+/** @file
+ Implementation of IsZeroBuffer function.
+
+ The following BaseMemoryLib instances contain the same copy of this file:
+
+ BaseMemoryLib
+ BaseMemoryLibMmx
+ BaseMemoryLibSse2
+ BaseMemoryLibRepStr
+ BaseMemoryLibOptDxe
+ BaseMemoryLibOptPei
+ PeiMemoryLib
+ UefiMemoryLib
+
+ Copyright (c) 2016, Intel Corporation. All rights reserved.<BR>
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD License
+ which accompanies this distribution. The full text of the license may be found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include <Base.h>
+#include <Library/DebugLib.h>
+
+/**
+ Checks if the contents of a buffer are all zeros.
+
+ This function checks whether the contents of a buffer are all zeros. If the
+ contents are all zeros, return TRUE. Otherwise, return FALSE.
+
+ If Length > 0 and Buffer is NULL, then ASSERT().
+ If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
+
+ @param Buffer The pointer to the buffer to be checked.
+ @param Length The size of the buffer (in bytes) to be checked.
+
+ @retval TRUE Contents of the buffer are all zeros.
+ @retval FALSE Contents of the buffer are not all zeros.
+
+**/
+BOOLEAN
+EFIAPI
+IsZeroBuffer (
+ IN CONST VOID *Buffer,
+ IN UINTN Length
+ )
+{
+ CONST UINT8 *BufferData;
+ UINTN Index;
+
+ ASSERT (!(Buffer == NULL && Length > 0));
+ ASSERT ((Length - 1) <= (MAX_ADDRESS - (UINTN)Buffer));
+
+ BufferData = Buffer;
+ for (Index = 0; Index < Length; Index++) {
+ if (BufferData[Index] != 0) {
+ return FALSE;
+ }
+ }
+ return TRUE;
+}
diff --git a/MdePkg/Library/UefiMemoryLib/UefiMemoryLib.inf b/MdePkg/Library/UefiMemoryLib/UefiMemoryLib.inf
index e82732f..2ea7875 100644
--- a/MdePkg/Library/UefiMemoryLib/UefiMemoryLib.inf
+++ b/MdePkg/Library/UefiMemoryLib/UefiMemoryLib.inf
@@ -45,6 +45,7 @@
MemLibGeneric.c
MemLibGuid.c
MemLib.c
+ IsZeroBuffer.c
MemLibInternals.h


--
1.9.5.msysgit.0


[PATCH 1/3] MdePkg BaseMemoryLib: Add implementation of API IsZeroGuid()

Wu, Hao A
 

Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
---
MdePkg/Include/Library/BaseMemoryLib.h | 20 ++++++++++++++++
MdePkg/Library/BaseMemoryLib/MemLibGuid.c | 31 ++++++++++++++++++++++++-
MdePkg/Library/BaseMemoryLibMmx/MemLibGuid.c | 31 ++++++++++++++++++++++++-
MdePkg/Library/BaseMemoryLibOptDxe/MemLibGuid.c | 31 ++++++++++++++++++++++++-
MdePkg/Library/BaseMemoryLibOptPei/MemLibGuid.c | 31 ++++++++++++++++++++++++-
MdePkg/Library/BaseMemoryLibRepStr/MemLibGuid.c | 31 ++++++++++++++++++++++++-
MdePkg/Library/BaseMemoryLibSse2/MemLibGuid.c | 31 ++++++++++++++++++++++++-
MdePkg/Library/PeiMemoryLib/MemLibGuid.c | 31 ++++++++++++++++++++++++-
MdePkg/Library/UefiMemoryLib/MemLibGuid.c | 31 ++++++++++++++++++++++++-
9 files changed, 260 insertions(+), 8 deletions(-)

diff --git a/MdePkg/Include/Library/BaseMemoryLib.h b/MdePkg/Include/Library/BaseMemoryLib.h
index e3a46d0..5a57dee 100644
--- a/MdePkg/Include/Library/BaseMemoryLib.h
+++ b/MdePkg/Include/Library/BaseMemoryLib.h
@@ -443,4 +443,24 @@ ScanGuid (
IN CONST GUID *Guid
);

+/**
+ Checks if the given GUID is a zero GUID.
+
+ This function checks whether the given GUID is a zero GUID. If the GUID is
+ identical to a zero GUID then TRUE is returned. Otherwise, FALSE is returned.
+
+ If Guid is NULL, then ASSERT().
+
+ @param Guid The pointer to a 128 bit GUID.
+
+ @retval TRUE Guid is a zero GUID.
+ @retval FALSE Guid is not a zero GUID.
+
+**/
+BOOLEAN
+EFIAPI
+IsZeroGuid (
+ IN CONST GUID *Guid
+ );
+
#endif
diff --git a/MdePkg/Library/BaseMemoryLib/MemLibGuid.c b/MdePkg/Library/BaseMemoryLib/MemLibGuid.c
index dc16bd5..b2590f8 100644
--- a/MdePkg/Library/BaseMemoryLib/MemLibGuid.c
+++ b/MdePkg/Library/BaseMemoryLib/MemLibGuid.c
@@ -12,7 +12,7 @@
PeiMemoryLib
UefiMemoryLib

- Copyright (c) 2006 - 2010, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -140,3 +140,32 @@ ScanGuid (
}
return NULL;
}
+
+/**
+ Checks if the given GUID is a zero GUID.
+
+ This function checks whether the given GUID is a zero GUID. If the GUID is
+ identical to a zero GUID then TRUE is returned. Otherwise, FALSE is returned.
+
+ If Guid is NULL, then ASSERT().
+
+ @param Guid The pointer to a 128 bit GUID.
+
+ @retval TRUE Guid is a zero GUID.
+ @retval FALSE Guid is not a zero GUID.
+
+**/
+BOOLEAN
+EFIAPI
+IsZeroGuid (
+ IN CONST GUID *Guid
+ )
+{
+ UINT64 LowPartOfGuid;
+ UINT64 HighPartOfGuid;
+
+ LowPartOfGuid = ReadUnaligned64 ((CONST UINT64*) Guid);
+ HighPartOfGuid = ReadUnaligned64 ((CONST UINT64*) Guid + 1);
+
+ return (BOOLEAN) (LowPartOfGuid == 0 && HighPartOfGuid == 0);
+}
diff --git a/MdePkg/Library/BaseMemoryLibMmx/MemLibGuid.c b/MdePkg/Library/BaseMemoryLibMmx/MemLibGuid.c
index c04af6e..cbb385f 100644
--- a/MdePkg/Library/BaseMemoryLibMmx/MemLibGuid.c
+++ b/MdePkg/Library/BaseMemoryLibMmx/MemLibGuid.c
@@ -12,7 +12,7 @@
PeiMemoryLib
UefiMemoryLib

- Copyright (c) 2006 - 2010, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -140,3 +140,32 @@ ScanGuid (
}
return NULL;
}
+
+/**
+ Checks if the given GUID is a zero GUID.
+
+ This function checks whether the given GUID is a zero GUID. If the GUID is
+ identical to a zero GUID then TRUE is returned. Otherwise, FALSE is returned.
+
+ If Guid is NULL, then ASSERT().
+
+ @param Guid The pointer to a 128 bit GUID.
+
+ @retval TRUE Guid is a zero GUID.
+ @retval FALSE Guid is not a zero GUID.
+
+**/
+BOOLEAN
+EFIAPI
+IsZeroGuid (
+ IN CONST GUID *Guid
+ )
+{
+ UINT64 LowPartOfGuid;
+ UINT64 HighPartOfGuid;
+
+ LowPartOfGuid = ReadUnaligned64 ((CONST UINT64*) Guid);
+ HighPartOfGuid = ReadUnaligned64 ((CONST UINT64*) Guid + 1);
+
+ return (BOOLEAN) (LowPartOfGuid == 0 && HighPartOfGuid == 0);
+}
diff --git a/MdePkg/Library/BaseMemoryLibOptDxe/MemLibGuid.c b/MdePkg/Library/BaseMemoryLibOptDxe/MemLibGuid.c
index c04af6e..cbb385f 100644
--- a/MdePkg/Library/BaseMemoryLibOptDxe/MemLibGuid.c
+++ b/MdePkg/Library/BaseMemoryLibOptDxe/MemLibGuid.c
@@ -12,7 +12,7 @@
PeiMemoryLib
UefiMemoryLib

- Copyright (c) 2006 - 2010, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -140,3 +140,32 @@ ScanGuid (
}
return NULL;
}
+
+/**
+ Checks if the given GUID is a zero GUID.
+
+ This function checks whether the given GUID is a zero GUID. If the GUID is
+ identical to a zero GUID then TRUE is returned. Otherwise, FALSE is returned.
+
+ If Guid is NULL, then ASSERT().
+
+ @param Guid The pointer to a 128 bit GUID.
+
+ @retval TRUE Guid is a zero GUID.
+ @retval FALSE Guid is not a zero GUID.
+
+**/
+BOOLEAN
+EFIAPI
+IsZeroGuid (
+ IN CONST GUID *Guid
+ )
+{
+ UINT64 LowPartOfGuid;
+ UINT64 HighPartOfGuid;
+
+ LowPartOfGuid = ReadUnaligned64 ((CONST UINT64*) Guid);
+ HighPartOfGuid = ReadUnaligned64 ((CONST UINT64*) Guid + 1);
+
+ return (BOOLEAN) (LowPartOfGuid == 0 && HighPartOfGuid == 0);
+}
diff --git a/MdePkg/Library/BaseMemoryLibOptPei/MemLibGuid.c b/MdePkg/Library/BaseMemoryLibOptPei/MemLibGuid.c
index 6f6edd0..cbb385f 100644
--- a/MdePkg/Library/BaseMemoryLibOptPei/MemLibGuid.c
+++ b/MdePkg/Library/BaseMemoryLibOptPei/MemLibGuid.c
@@ -12,7 +12,7 @@
PeiMemoryLib
UefiMemoryLib

- Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -140,3 +140,32 @@ ScanGuid (
}
return NULL;
}
+
+/**
+ Checks if the given GUID is a zero GUID.
+
+ This function checks whether the given GUID is a zero GUID. If the GUID is
+ identical to a zero GUID then TRUE is returned. Otherwise, FALSE is returned.
+
+ If Guid is NULL, then ASSERT().
+
+ @param Guid The pointer to a 128 bit GUID.
+
+ @retval TRUE Guid is a zero GUID.
+ @retval FALSE Guid is not a zero GUID.
+
+**/
+BOOLEAN
+EFIAPI
+IsZeroGuid (
+ IN CONST GUID *Guid
+ )
+{
+ UINT64 LowPartOfGuid;
+ UINT64 HighPartOfGuid;
+
+ LowPartOfGuid = ReadUnaligned64 ((CONST UINT64*) Guid);
+ HighPartOfGuid = ReadUnaligned64 ((CONST UINT64*) Guid + 1);
+
+ return (BOOLEAN) (LowPartOfGuid == 0 && HighPartOfGuid == 0);
+}
diff --git a/MdePkg/Library/BaseMemoryLibRepStr/MemLibGuid.c b/MdePkg/Library/BaseMemoryLibRepStr/MemLibGuid.c
index 6f6edd0..cbb385f 100644
--- a/MdePkg/Library/BaseMemoryLibRepStr/MemLibGuid.c
+++ b/MdePkg/Library/BaseMemoryLibRepStr/MemLibGuid.c
@@ -12,7 +12,7 @@
PeiMemoryLib
UefiMemoryLib

- Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -140,3 +140,32 @@ ScanGuid (
}
return NULL;
}
+
+/**
+ Checks if the given GUID is a zero GUID.
+
+ This function checks whether the given GUID is a zero GUID. If the GUID is
+ identical to a zero GUID then TRUE is returned. Otherwise, FALSE is returned.
+
+ If Guid is NULL, then ASSERT().
+
+ @param Guid The pointer to a 128 bit GUID.
+
+ @retval TRUE Guid is a zero GUID.
+ @retval FALSE Guid is not a zero GUID.
+
+**/
+BOOLEAN
+EFIAPI
+IsZeroGuid (
+ IN CONST GUID *Guid
+ )
+{
+ UINT64 LowPartOfGuid;
+ UINT64 HighPartOfGuid;
+
+ LowPartOfGuid = ReadUnaligned64 ((CONST UINT64*) Guid);
+ HighPartOfGuid = ReadUnaligned64 ((CONST UINT64*) Guid + 1);
+
+ return (BOOLEAN) (LowPartOfGuid == 0 && HighPartOfGuid == 0);
+}
diff --git a/MdePkg/Library/BaseMemoryLibSse2/MemLibGuid.c b/MdePkg/Library/BaseMemoryLibSse2/MemLibGuid.c
index c04af6e..cbb385f 100644
--- a/MdePkg/Library/BaseMemoryLibSse2/MemLibGuid.c
+++ b/MdePkg/Library/BaseMemoryLibSse2/MemLibGuid.c
@@ -12,7 +12,7 @@
PeiMemoryLib
UefiMemoryLib

- Copyright (c) 2006 - 2010, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -140,3 +140,32 @@ ScanGuid (
}
return NULL;
}
+
+/**
+ Checks if the given GUID is a zero GUID.
+
+ This function checks whether the given GUID is a zero GUID. If the GUID is
+ identical to a zero GUID then TRUE is returned. Otherwise, FALSE is returned.
+
+ If Guid is NULL, then ASSERT().
+
+ @param Guid The pointer to a 128 bit GUID.
+
+ @retval TRUE Guid is a zero GUID.
+ @retval FALSE Guid is not a zero GUID.
+
+**/
+BOOLEAN
+EFIAPI
+IsZeroGuid (
+ IN CONST GUID *Guid
+ )
+{
+ UINT64 LowPartOfGuid;
+ UINT64 HighPartOfGuid;
+
+ LowPartOfGuid = ReadUnaligned64 ((CONST UINT64*) Guid);
+ HighPartOfGuid = ReadUnaligned64 ((CONST UINT64*) Guid + 1);
+
+ return (BOOLEAN) (LowPartOfGuid == 0 && HighPartOfGuid == 0);
+}
diff --git a/MdePkg/Library/PeiMemoryLib/MemLibGuid.c b/MdePkg/Library/PeiMemoryLib/MemLibGuid.c
index c04af6e..cbb385f 100644
--- a/MdePkg/Library/PeiMemoryLib/MemLibGuid.c
+++ b/MdePkg/Library/PeiMemoryLib/MemLibGuid.c
@@ -12,7 +12,7 @@
PeiMemoryLib
UefiMemoryLib

- Copyright (c) 2006 - 2010, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -140,3 +140,32 @@ ScanGuid (
}
return NULL;
}
+
+/**
+ Checks if the given GUID is a zero GUID.
+
+ This function checks whether the given GUID is a zero GUID. If the GUID is
+ identical to a zero GUID then TRUE is returned. Otherwise, FALSE is returned.
+
+ If Guid is NULL, then ASSERT().
+
+ @param Guid The pointer to a 128 bit GUID.
+
+ @retval TRUE Guid is a zero GUID.
+ @retval FALSE Guid is not a zero GUID.
+
+**/
+BOOLEAN
+EFIAPI
+IsZeroGuid (
+ IN CONST GUID *Guid
+ )
+{
+ UINT64 LowPartOfGuid;
+ UINT64 HighPartOfGuid;
+
+ LowPartOfGuid = ReadUnaligned64 ((CONST UINT64*) Guid);
+ HighPartOfGuid = ReadUnaligned64 ((CONST UINT64*) Guid + 1);
+
+ return (BOOLEAN) (LowPartOfGuid == 0 && HighPartOfGuid == 0);
+}
diff --git a/MdePkg/Library/UefiMemoryLib/MemLibGuid.c b/MdePkg/Library/UefiMemoryLib/MemLibGuid.c
index 6f6edd0..cbb385f 100644
--- a/MdePkg/Library/UefiMemoryLib/MemLibGuid.c
+++ b/MdePkg/Library/UefiMemoryLib/MemLibGuid.c
@@ -12,7 +12,7 @@
PeiMemoryLib
UefiMemoryLib

- Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -140,3 +140,32 @@ ScanGuid (
}
return NULL;
}
+
+/**
+ Checks if the given GUID is a zero GUID.
+
+ This function checks whether the given GUID is a zero GUID. If the GUID is
+ identical to a zero GUID then TRUE is returned. Otherwise, FALSE is returned.
+
+ If Guid is NULL, then ASSERT().
+
+ @param Guid The pointer to a 128 bit GUID.
+
+ @retval TRUE Guid is a zero GUID.
+ @retval FALSE Guid is not a zero GUID.
+
+**/
+BOOLEAN
+EFIAPI
+IsZeroGuid (
+ IN CONST GUID *Guid
+ )
+{
+ UINT64 LowPartOfGuid;
+ UINT64 HighPartOfGuid;
+
+ LowPartOfGuid = ReadUnaligned64 ((CONST UINT64*) Guid);
+ HighPartOfGuid = ReadUnaligned64 ((CONST UINT64*) Guid + 1);
+
+ return (BOOLEAN) (LowPartOfGuid == 0 && HighPartOfGuid == 0);
+}
--
1.9.5.msysgit.0


[PATCH 0/3] Add APIs IsZeroBuffer and IsZeroGuid in BaseMemoryLib

Wu, Hao A
 

The patch series will add two APIs in BaseMemoryLib:
1. IsZeroBuffer()
The API is used to check if the contents of a buffer are all zeros.

2. IsZeroGuid()
The API is used to check if the given GUID is a zero GUID.

In order to resolve build issues in SecurityPkg, the series will also
remove the internal implementation of IsZeroBuffer() in modules within
SecurityPkg\Tcg and use the one in BaseMemoryLib instead.

Hao Wu (3):
MdePkg BaseMemoryLib: Add implementation of API IsZeroGuid()
MdePkg BaseMemoryLib: Add implementation of API IsZeroBuffer()
SecurityPkg Tcg2: Remove internal implementation of IsZeroBuffer()

MdePkg/Include/Library/BaseMemoryLib.h | 43 ++++++++++++++
MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf | 1 +
MdePkg/Library/BaseMemoryLib/IsZeroBuffer.c | 65 ++++++++++++++++++++++
MdePkg/Library/BaseMemoryLib/MemLibGuid.c | 31 ++++++++++-
.../Library/BaseMemoryLibMmx/BaseMemoryLibMmx.inf | 1 +
MdePkg/Library/BaseMemoryLibMmx/IsZeroBuffer.c | 65 ++++++++++++++++++++++
MdePkg/Library/BaseMemoryLibMmx/MemLibGuid.c | 31 ++++++++++-
.../BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf | 2 +
MdePkg/Library/BaseMemoryLibOptDxe/IsZeroBuffer.c | 65 ++++++++++++++++++++++
MdePkg/Library/BaseMemoryLibOptDxe/MemLibGuid.c | 31 ++++++++++-
.../BaseMemoryLibOptPei/BaseMemoryLibOptPei.inf | 2 +
MdePkg/Library/BaseMemoryLibOptPei/IsZeroBuffer.c | 65 ++++++++++++++++++++++
MdePkg/Library/BaseMemoryLibOptPei/MemLibGuid.c | 31 ++++++++++-
.../BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf | 1 +
MdePkg/Library/BaseMemoryLibRepStr/IsZeroBuffer.c | 65 ++++++++++++++++++++++
MdePkg/Library/BaseMemoryLibRepStr/MemLibGuid.c | 31 ++++++++++-
.../BaseMemoryLibSse2/BaseMemoryLibSse2.inf | 1 +
MdePkg/Library/BaseMemoryLibSse2/IsZeroBuffer.c | 65 ++++++++++++++++++++++
MdePkg/Library/BaseMemoryLibSse2/MemLibGuid.c | 31 ++++++++++-
MdePkg/Library/PeiMemoryLib/IsZeroBuffer.c | 65 ++++++++++++++++++++++
MdePkg/Library/PeiMemoryLib/MemLibGuid.c | 31 ++++++++++-
MdePkg/Library/PeiMemoryLib/PeiMemoryLib.inf | 1 +
MdePkg/Library/UefiMemoryLib/IsZeroBuffer.c | 65 ++++++++++++++++++++++
MdePkg/Library/UefiMemoryLib/MemLibGuid.c | 31 ++++++++++-
MdePkg/Library/UefiMemoryLib/UefiMemoryLib.inf | 1 +
SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c | 27 ---------
SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c | 27 ---------
SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c | 27 ---------
28 files changed, 813 insertions(+), 89 deletions(-)
create mode 100644 MdePkg/Library/BaseMemoryLib/IsZeroBuffer.c
create mode 100644 MdePkg/Library/BaseMemoryLibMmx/IsZeroBuffer.c
create mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/IsZeroBuffer.c
create mode 100644 MdePkg/Library/BaseMemoryLibOptPei/IsZeroBuffer.c
create mode 100644 MdePkg/Library/BaseMemoryLibRepStr/IsZeroBuffer.c
create mode 100644 MdePkg/Library/BaseMemoryLibSse2/IsZeroBuffer.c
create mode 100644 MdePkg/Library/PeiMemoryLib/IsZeroBuffer.c
create mode 100644 MdePkg/Library/UefiMemoryLib/IsZeroBuffer.c

--
1.9.5.msysgit.0


Re: [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

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

Ard,
Pls go ahead to add R_X86_64_PLT32 firstly. Below is my original path. And for the GOTPCREL type ones, I could finish enhance them after I back from vacation next week. Thanks.
https://github.com/shijunjing/edk2/commit/dd8b1c4625cbffc7e149571266e0ae0581bd207d



Steven Shi
Intel\SSG\STO\UEFI Firmware

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

-----Original Message-----
From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
Sent: Thursday, August 04, 2016 4:55 AM
To: Justen, Jordan L <jordan.l.justen@intel.com>
Cc: Shi, Steven <steven.shi@intel.com>; Kinney, Michael D
<michael.d.kinney@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>;
afish@apple.com; Gao, Liming <liming.gao@intel.com>;
mischief@offblast.org
Subject: Re: [edk2] [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf
relocation types for PIC/PIE code


On 3 aug. 2016, at 22:53, Jordan Justen <jordan.l.justen@intel.com> wrote:

On 2016-08-03 13:47:09, Ard Biesheuvel wrote:

On 3 aug. 2016, at 22:13, Jordan Justen <jordan.l.justen@intel.com>
wrote:

Where does this patch stand? I think Ard was asking for it to be
split, but also wondering if it was really required...

Some devs are still reporting unsupported relocation errors during the
build. (mischief on irc, for example.)
The patch is not correct in its current form. PLT relocations (0x4)
can be handled ok, so we can split that off and merge it. The GOT
based relocation handling needs non-trivial rework, and may
currently create corrupt binaries. Which unhandled reloc types are
being reported?
"unsupported ELF EM_X86_64 relocation 0x4"

You might join irc if you want to get some more info from mischief
about it.
That's the plt one, which we can fix easily. I'll whip up a patch in the morning
(11 pm here now)





On 2016-08-02 05:00:43, Ard Biesheuvel wrote:
On 2 August 2016 at 13:40, Shi, Steven <steven.shi@intel.com> wrote:

CoffAddFixup() must be used for absolute symbol references only.
These
instructions contain relative symbol references, which are
recalculated in WriteSections64().

The only absolute symbol reference is the GOT entry for 'n', and your
code (in WriteRelocations64()) calculates the address of the GOT
entry
(which is always in .text BTW) and adds a fixup for it, i.e.,

+ CoffAddFixup(
+ (UINT32)(UINTN)((UINT64)
mCoffSectionsOffset[RelShdr->sh_info] + GoTPcRelPtrOffset),
+ EFI_IMAGE_REL_BASED_DIR64);

This code adds a fixup to the PE/COFF .reloc section for the GOT
entry
containing the address of 'n', and the instructions perform a IP
relative load of the contents of the GOT entry to retrieve the address
of 'n'.

By adding two fixups, the PE/COFF loader will apply the load offset
twice, resulting in an incorrect value.
OK, I get your point now. Yes, the current patch could generate
multiple fixups for the same GOT relocation entry. How about we introduce a
simple IsDuplicatedCoffFixup() to check whether a converting fixup offset is
duplicated before we use CoffAddFixup() to really add it? If it is new, we add
it, otherwise just skip it.

That could work, but you have to be aware that fixups are best emitted
in the order they need to be applied in the binary, or it will become
very inefficient. (Please refer to the PE/COFF spec section that
explains the layout of the .reloc section)

What it comes down to is that relocations are grouped by target page,
and for every place in the page that requires a relocation to be
applied, a 4 bit type is emitted followed by a 12-bit offset, which is
the offset into the current page. If you emit fixups for the current
instruction, followed by one for the GOT, it will basically take two
'page switches' every time.

So it would be better to simply emit the relocations, but introduce a
sorting pass that merges all duplicates as well.

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


[PATCH] PcdBdsLinuxSupport default value

Daniil Egranov
 

The built-in Linux Loader is obsolete and not included in most builds.
The patch sets the PcdBdsLinuxSupport default value to FALSE and prevents
ArmBds from looking for built-in Linux Loader by default and ASSERTing
when it cannot be found. Platforms which still using built-in loader have
to set this PCD in their platform description file.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daniil Egranov <daniil.egranov@arm.com>
---
ArmPlatformPkg/ArmPlatformPkg.dec | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec b/ArmPlatformPkg/ArmPlatformPkg.dec
index 5864d98..d756fd2 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dec
+++ b/ArmPlatformPkg/ArmPlatformPkg.dec
@@ -55,7 +55,7 @@
gArmPlatformTokenSpaceGuid.PcdGopDisableOnExitBootServices|FALSE|BOOLEAN|0x0000003D

# Enable Legacy Linux support in the BDS
- gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport|TRUE|BOOLEAN|0x0000002E
+ gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport|FALSE|BOOLEAN|0x0000002E

[PcdsFixedAtBuild.common]
gArmPlatformTokenSpaceGuid.PcdCoreCount|1|UINT32|0x00000039
--
2.7.4


Re: [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

Ard Biesheuvel
 

On 3 aug. 2016, at 22:53, Jordan Justen <jordan.l.justen@intel.com> wrote:

On 2016-08-03 13:47:09, Ard Biesheuvel wrote:

On 3 aug. 2016, at 22:13, Jordan Justen <jordan.l.justen@intel.com> wrote:

Where does this patch stand? I think Ard was asking for it to be
split, but also wondering if it was really required...

Some devs are still reporting unsupported relocation errors during the
build. (mischief on irc, for example.)
The patch is not correct in its current form. PLT relocations (0x4)
can be handled ok, so we can split that off and merge it. The GOT
based relocation handling needs non-trivial rework, and may
currently create corrupt binaries. Which unhandled reloc types are
being reported?
"unsupported ELF EM_X86_64 relocation 0x4"

You might join irc if you want to get some more info from mischief
about it.
That's the plt one, which we can fix easily. I'll whip up a patch in the morning (11 pm here now)





On 2016-08-02 05:00:43, Ard Biesheuvel wrote:
On 2 August 2016 at 13:40, Shi, Steven <steven.shi@intel.com> wrote:

CoffAddFixup() must be used for absolute symbol references only. These
instructions contain relative symbol references, which are
recalculated in WriteSections64().

The only absolute symbol reference is the GOT entry for 'n', and your
code (in WriteRelocations64()) calculates the address of the GOT entry
(which is always in .text BTW) and adds a fixup for it, i.e.,

+ CoffAddFixup(
+ (UINT32)(UINTN)((UINT64)
mCoffSectionsOffset[RelShdr->sh_info] + GoTPcRelPtrOffset),
+ EFI_IMAGE_REL_BASED_DIR64);

This code adds a fixup to the PE/COFF .reloc section for the GOT entry
containing the address of 'n', and the instructions perform a IP
relative load of the contents of the GOT entry to retrieve the address
of 'n'.

By adding two fixups, the PE/COFF loader will apply the load offset
twice, resulting in an incorrect value.
OK, I get your point now. Yes, the current patch could generate multiple fixups for the same GOT relocation entry. How about we introduce a simple IsDuplicatedCoffFixup() to check whether a converting fixup offset is duplicated before we use CoffAddFixup() to really add it? If it is new, we add it, otherwise just skip it.
That could work, but you have to be aware that fixups are best emitted
in the order they need to be applied in the binary, or it will become
very inefficient. (Please refer to the PE/COFF spec section that
explains the layout of the .reloc section)

What it comes down to is that relocations are grouped by target page,
and for every place in the page that requires a relocation to be
applied, a 4 bit type is emitted followed by a 12-bit offset, which is
the offset into the current page. If you emit fixups for the current
instruction, followed by one for the GOT, it will basically take two
'page switches' every time.

So it would be better to simply emit the relocations, but introduce a
sorting pass that merges all duplicates as well.

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


Re: [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

Nicolas Owens <mischief@...>
 

On 08/03/2016 01:47 PM, Ard Biesheuvel wrote:

On 3 aug. 2016, at 22:13, Jordan Justen <jordan.l.justen@intel.com> wrote:

Where does this patch stand? I think Ard was asking for it to be
split, but also wondering if it was really required...

Some devs are still reporting unsupported relocation errors during the
build. (mischief on irc, for example.)
The patch is not correct in its current form. PLT relocations (0x4) can be handled ok, so we can split that off and merge it. The GOT based relocation handling needs non-trivial rework, and may currently create corrupt binaries. Which unhandled reloc types are being reported?
currently, i see:

"GenFw" -e UEFI_APPLICATION -o
/home/mischief/src/efivim/edk2/Build/vim/DEBUG_GCC49/X64/vim/DEBUG/vim.efi
/home/mischief/src/efivim/edk2/Build/vim/DEBUG_GCC49/X64/vim/DEBUG/vim.dll
GenFw: ERROR 3000: Invalid
make[1]: ***
[/home/mischief/src/efivim/edk2/Build/vim/DEBUG_GCC49/X64/vim/DEBUG/vim.efi]
Error 2

/home/mischief/src/efivim/edk2/Build/vim/DEBUG_GCC49/X64/vim/DEBUG/vim.dll
unsupported ELF EM_X86_64 relocation 0x4.

this is off edk2 master from about 2 days ago.




On 2016-08-02 05:00:43, Ard Biesheuvel wrote:
On 2 August 2016 at 13:40, Shi, Steven <steven.shi@intel.com> wrote:

CoffAddFixup() must be used for absolute symbol references only. These
instructions contain relative symbol references, which are
recalculated in WriteSections64().

The only absolute symbol reference is the GOT entry for 'n', and your
code (in WriteRelocations64()) calculates the address of the GOT entry
(which is always in .text BTW) and adds a fixup for it, i.e.,

+ CoffAddFixup(
+ (UINT32)(UINTN)((UINT64)
mCoffSectionsOffset[RelShdr->sh_info] + GoTPcRelPtrOffset),
+ EFI_IMAGE_REL_BASED_DIR64);

This code adds a fixup to the PE/COFF .reloc section for the GOT entry
containing the address of 'n', and the instructions perform a IP
relative load of the contents of the GOT entry to retrieve the address
of 'n'.

By adding two fixups, the PE/COFF loader will apply the load offset
twice, resulting in an incorrect value.
OK, I get your point now. Yes, the current patch could generate multiple fixups for the same GOT relocation entry. How about we introduce a simple IsDuplicatedCoffFixup() to check whether a converting fixup offset is duplicated before we use CoffAddFixup() to really add it? If it is new, we add it, otherwise just skip it.
That could work, but you have to be aware that fixups are best emitted
in the order they need to be applied in the binary, or it will become
very inefficient. (Please refer to the PE/COFF spec section that
explains the layout of the .reloc section)

What it comes down to is that relocations are grouped by target page,
and for every place in the page that requires a relocation to be
applied, a 4 bit type is emitted followed by a 12-bit offset, which is
the offset into the current page. If you emit fixups for the current
instruction, followed by one for the GOT, it will basically take two
'page switches' every time.

So it would be better to simply emit the relocations, but introduce a
sorting pass that merges all duplicates as well.

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


Re: [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

Jordan Justen
 

On 2016-08-03 13:47:09, Ard Biesheuvel wrote:

On 3 aug. 2016, at 22:13, Jordan Justen <jordan.l.justen@intel.com> wrote:

Where does this patch stand? I think Ard was asking for it to be
split, but also wondering if it was really required...

Some devs are still reporting unsupported relocation errors during the
build. (mischief on irc, for example.)
The patch is not correct in its current form. PLT relocations (0x4)
can be handled ok, so we can split that off and merge it. The GOT
based relocation handling needs non-trivial rework, and may
currently create corrupt binaries. Which unhandled reloc types are
being reported?
"unsupported ELF EM_X86_64 relocation 0x4"

You might join irc if you want to get some more info from mischief
about it.

-Jordan



On 2016-08-02 05:00:43, Ard Biesheuvel wrote:
On 2 August 2016 at 13:40, Shi, Steven <steven.shi@intel.com> wrote:

CoffAddFixup() must be used for absolute symbol references only. These
instructions contain relative symbol references, which are
recalculated in WriteSections64().

The only absolute symbol reference is the GOT entry for 'n', and your
code (in WriteRelocations64()) calculates the address of the GOT entry
(which is always in .text BTW) and adds a fixup for it, i.e.,

+ CoffAddFixup(
+ (UINT32)(UINTN)((UINT64)
mCoffSectionsOffset[RelShdr->sh_info] + GoTPcRelPtrOffset),
+ EFI_IMAGE_REL_BASED_DIR64);

This code adds a fixup to the PE/COFF .reloc section for the GOT entry
containing the address of 'n', and the instructions perform a IP
relative load of the contents of the GOT entry to retrieve the address
of 'n'.

By adding two fixups, the PE/COFF loader will apply the load offset
twice, resulting in an incorrect value.
OK, I get your point now. Yes, the current patch could generate multiple fixups for the same GOT relocation entry. How about we introduce a simple IsDuplicatedCoffFixup() to check whether a converting fixup offset is duplicated before we use CoffAddFixup() to really add it? If it is new, we add it, otherwise just skip it.
That could work, but you have to be aware that fixups are best emitted
in the order they need to be applied in the binary, or it will become
very inefficient. (Please refer to the PE/COFF spec section that
explains the layout of the .reloc section)

What it comes down to is that relocations are grouped by target page,
and for every place in the page that requires a relocation to be
applied, a 4 bit type is emitted followed by a 12-bit offset, which is
the offset into the current page. If you emit fixups for the current
instruction, followed by one for the GOT, it will basically take two
'page switches' every time.

So it would be better to simply emit the relocations, but introduce a
sorting pass that merges all duplicates as well.

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


Re: [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

Ard Biesheuvel
 

On 3 aug. 2016, at 22:13, Jordan Justen <jordan.l.justen@intel.com> wrote:

Where does this patch stand? I think Ard was asking for it to be
split, but also wondering if it was really required...

Some devs are still reporting unsupported relocation errors during the
build. (mischief on irc, for example.)
The patch is not correct in its current form. PLT relocations (0x4) can be handled ok, so we can split that off and merge it. The GOT based relocation handling needs non-trivial rework, and may currently create corrupt binaries. Which unhandled reloc types are being reported?



On 2016-08-02 05:00:43, Ard Biesheuvel wrote:
On 2 August 2016 at 13:40, Shi, Steven <steven.shi@intel.com> wrote:

CoffAddFixup() must be used for absolute symbol references only. These
instructions contain relative symbol references, which are
recalculated in WriteSections64().

The only absolute symbol reference is the GOT entry for 'n', and your
code (in WriteRelocations64()) calculates the address of the GOT entry
(which is always in .text BTW) and adds a fixup for it, i.e.,

+ CoffAddFixup(
+ (UINT32)(UINTN)((UINT64)
mCoffSectionsOffset[RelShdr->sh_info] + GoTPcRelPtrOffset),
+ EFI_IMAGE_REL_BASED_DIR64);

This code adds a fixup to the PE/COFF .reloc section for the GOT entry
containing the address of 'n', and the instructions perform a IP
relative load of the contents of the GOT entry to retrieve the address
of 'n'.

By adding two fixups, the PE/COFF loader will apply the load offset
twice, resulting in an incorrect value.
OK, I get your point now. Yes, the current patch could generate multiple fixups for the same GOT relocation entry. How about we introduce a simple IsDuplicatedCoffFixup() to check whether a converting fixup offset is duplicated before we use CoffAddFixup() to really add it? If it is new, we add it, otherwise just skip it.
That could work, but you have to be aware that fixups are best emitted
in the order they need to be applied in the binary, or it will become
very inefficient. (Please refer to the PE/COFF spec section that
explains the layout of the .reloc section)

What it comes down to is that relocations are grouped by target page,
and for every place in the page that requires a relocation to be
applied, a 4 bit type is emitted followed by a 12-bit offset, which is
the offset into the current page. If you emit fixups for the current
instruction, followed by one for the GOT, it will basically take two
'page switches' every time.

So it would be better to simply emit the relocations, but introduce a
sorting pass that merges all duplicates as well.

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


Re: [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

Jordan Justen
 

Where does this patch stand? I think Ard was asking for it to be
split, but also wondering if it was really required...

Some devs are still reporting unsupported relocation errors during the
build. (mischief on irc, for example.)

-Jordan

On 2016-08-02 05:00:43, Ard Biesheuvel wrote:
On 2 August 2016 at 13:40, Shi, Steven <steven.shi@intel.com> wrote:

CoffAddFixup() must be used for absolute symbol references only. These
instructions contain relative symbol references, which are
recalculated in WriteSections64().

The only absolute symbol reference is the GOT entry for 'n', and your
code (in WriteRelocations64()) calculates the address of the GOT entry
(which is always in .text BTW) and adds a fixup for it, i.e.,

+ CoffAddFixup(
+ (UINT32)(UINTN)((UINT64)
mCoffSectionsOffset[RelShdr->sh_info] + GoTPcRelPtrOffset),
+ EFI_IMAGE_REL_BASED_DIR64);

This code adds a fixup to the PE/COFF .reloc section for the GOT entry
containing the address of 'n', and the instructions perform a IP
relative load of the contents of the GOT entry to retrieve the address
of 'n'.

By adding two fixups, the PE/COFF loader will apply the load offset
twice, resulting in an incorrect value.
OK, I get your point now. Yes, the current patch could generate multiple fixups for the same GOT relocation entry. How about we introduce a simple IsDuplicatedCoffFixup() to check whether a converting fixup offset is duplicated before we use CoffAddFixup() to really add it? If it is new, we add it, otherwise just skip it.
That could work, but you have to be aware that fixups are best emitted
in the order they need to be applied in the binary, or it will become
very inefficient. (Please refer to the PE/COFF spec section that
explains the layout of the .reloc section)

What it comes down to is that relocations are grouped by target page,
and for every place in the page that requires a relocation to be
applied, a 4 bit type is emitted followed by a 12-bit offset, which is
the offset into the current page. If you emit fixups for the current
instruction, followed by one for the GOT, it will basically take two
'page switches' every time.

So it would be better to simply emit the relocations, but introduce a
sorting pass that merges all duplicates as well.

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


Re: Shell Path Issues with "../.."

Cohen, Eugene <eugene@...>
 

Thanks - I searched for the subject on my edk2-devel archive and didn't see anything. I now see the patch sent 6/21, so yeah about 3 months later. :)

Next time I ask that the maintainer respond to the original email please (granted I screwed up because I forgot to include them specifically on the To: line) and include me on the patch review (again on the To: line).

Eugene

-----Original Message-----
From: Alcantara, Paulo
Sent: Wednesday, August 03, 2016 1:27 PM
To: Cohen, Eugene <eugene@hp.com>; edk2-devel@lists.01.org;
Carsey, Jaben <jaben.carsey@intel.com> (jaben.carsey@intel.com)
<jaben.carsey@intel.com>
Cc: Thompson, Mark L. (Boise IPG) <mark.l.thompson@hp.com>
Subject: RE: Shell Path Issues with "../.."

Hi Eugene,

I think it has been fixed on master already. See the commit below:

commit 85df61243cb56c3d9c52a5005e65c4ea8bf60e52
Author: Qiu Shumin <shumin.qiu@intel.com>
Date: Tue Jun 21 16:18:56 2016 +0800

MdePkg: Fix 'cd ..\..' go up only 1 level.

When we try to cd up two levels using the "../.." notation we
only go up one level. This patch fix this bug.

Thanks,

Paulo

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf
Of Cohen, Eugene
Sent: quarta-feira, 3 de agosto de 2016 16:17
To: edk2-devel@lists.01.org; Carsey, Jaben <jaben.carsey@intel.com>
(jaben.carsey@intel.com) <jaben.carsey@intel.com>
Cc: Thompson, Mark L. (Boise IPG) <mark.l.thompson@hp.com>
Subject: Re: [edk2] Shell Path Issues with "../.."

Reminder (a few months later)

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On
Behalf Of
Cohen, Eugene
Sent: Wednesday, March 30, 2016 4:51 PM
To: edk2-devel@lists.01.org
Cc: Thompson, Mark L. (Boise IPG) <mark.l.thompson@hp.com>
Subject: [edk2] Shell Path Issues with "../.."

Dear ShellPkg maintainer,

We're seeing some weird stuff related to '..' in the shell.

The issue is that when we try to cd up two levels using the "../.."
notation we only go up one level:

FS0:\dir1\dir2\dir3\>
FS0:\dir1\dir2\dir3\> cd ..\..
FS0:\dir1\dir2\>

The same issue occurs using forward and back slashes. The old (EDK)
shell used to handle this correctly.

Any ideas what's going on here?

Thanks,

Eugene

_______________________________________________
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: Shell Path Issues with "../.."

Alcantara, Paulo <paulo.alc.cavalcanti@...>
 

Hi Eugene,

I think it has been fixed on master already. See the commit below:

commit 85df61243cb56c3d9c52a5005e65c4ea8bf60e52
Author: Qiu Shumin <shumin.qiu@intel.com>
Date: Tue Jun 21 16:18:56 2016 +0800

MdePkg: Fix 'cd ..\..' go up only 1 level.

When we try to cd up two levels using the "../.." notation we
only go up one level. This patch fix this bug.

Thanks,

Paulo

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Cohen, Eugene
Sent: quarta-feira, 3 de agosto de 2016 16:17
To: edk2-devel@lists.01.org; Carsey, Jaben <jaben.carsey@intel.com> (jaben.carsey@intel.com) <jaben.carsey@intel.com>
Cc: Thompson, Mark L. (Boise IPG) <mark.l.thompson@hp.com>
Subject: Re: [edk2] Shell Path Issues with "../.."

Reminder (a few months later)

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Cohen, Eugene
Sent: Wednesday, March 30, 2016 4:51 PM
To: edk2-devel@lists.01.org
Cc: Thompson, Mark L. (Boise IPG) <mark.l.thompson@hp.com>
Subject: [edk2] Shell Path Issues with "../.."

Dear ShellPkg maintainer,

We're seeing some weird stuff related to '..' in the shell.

The issue is that when we try to cd up two levels using the "../.."
notation we only go up one level:

FS0:\dir1\dir2\dir3\>
FS0:\dir1\dir2\dir3\> cd ..\..
FS0:\dir1\dir2\>

The same issue occurs using forward and back slashes. The old (EDK)
shell used to handle this correctly.

Any ideas what's going on here?

Thanks,

Eugene

_______________________________________________
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: Shell Path Issues with "../.."

Cohen, Eugene <eugene@...>
 

Reminder (a few months later)

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf
Of Cohen, Eugene
Sent: Wednesday, March 30, 2016 4:51 PM
To: edk2-devel@lists.01.org
Cc: Thompson, Mark L. (Boise IPG) <mark.l.thompson@hp.com>
Subject: [edk2] Shell Path Issues with "../.."

Dear ShellPkg maintainer,

We're seeing some weird stuff related to '..' in the shell.

The issue is that when we try to cd up two levels using the "../.."
notation we only go up one level:

FS0:\dir1\dir2\dir3\>
FS0:\dir1\dir2\dir3\> cd ..\..
FS0:\dir1\dir2\>

The same issue occurs using forward and back slashes. The old (EDK)
shell used to handle this correctly.

Any ideas what's going on here?

Thanks,

Eugene

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


Re: [PATCH v5 0/4] Introduce CLANG38 toolchain in edk2

Carsey, Jaben
 

For both changes in ShellPkg.

Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>

-----Original Message-----
From: Shi, Steven
Sent: Wednesday, August 03, 2016 2:43 AM
To: edk2-devel@lists.01.org; Gao, Liming <liming.gao@intel.com>; Carsey,
Jaben <jaben.carsey@intel.com>
Cc: afish@apple.com; Kinney, Michael D <michael.d.kinney@intel.com>;
ard.biesheuvel@linaro.org
Subject: [PATCH v5 0/4] Introduce CLANG38 toolchain in edk2
Importance: High

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

The difference from
V4(https://github.com/shijunjing/edk2/commits/llvm_v4):
1. Remove the GCC5 path prefix for binutils objcopy, because a clang user
may not set GCC5_BIN.
2. Follow GCC5 to disable the LTO for ASLCC flags.
3. Add CLANG38 in the "Supported Tool Chains" part.

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

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

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


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

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

--
2.7.4


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

Ard Biesheuvel
 

On 3 August 2016 at 15:20, Gao, Liming <liming.gao@intel.com> wrote:
Ard:

Thanks for your detail explain. I understand it. I add my rb for this
patch set.



Reviewed-by: Liming Gao <liming.gao@intel.com>
Pushed as

108c5b601860 BaseTools GCC: move -c compiler flag to build rules
f8d0b9662993 BaseTools GCC5: disable warnings-as-errors for now
478f50990a9a BaseTools GCC: add the compiler flags to the linker command line

with the simplification suggested by Leif regarding RVCT

Thanks,
Ard.