Date   

Re: [PATCH v1 1/2] EDK2 Code First: PI Specification: New error codes of Host Software class

Michael D Kinney
 

Hi Kun,

Memory Type Information is the name of an EDK II feature. Also, not all memory
type information changes required a reset/reboot. That is configurable by the
platform.

The system attribute that requires a reboot is if the UEFI Memory Map during a normal
boot is in a state that would be incompatible with a potential future ACPI S4
resume boot. Some OSes require the UEFI Memory ranges for RT and ACPI memory types
to be in the same location in normal boot and ACPI S4 resume boot.

I am wondering if we can choose a different name for the new PI Status code that
reflects this OS ACPI requirement for a consistent memory map instead of referring
to the EDK II Memory Type Information feature. That way, the PI Spec name would
allow implementations that do not necessarily required the EDK II specific
implementation feature.

RELEASE_ASSERT also seems to imply an implementation specific way the reset/reboot
is triggered. An ASSERT() is typically triggered for a condition for which the
code that follow the ASSERT() can not continue without unexpected or undefined
behavior. So the system is in a bad state that is not recoverable. This type of
state could be detected with a normal if/then/else logic in C code when looking
at system state or encapsulated in an ASSERT() that is enabled in release builds.
Once again, I think we need a different name that does not require the detection
logic to be in an EDK II ASSERT() macro.

Thanks,

Mike

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Kun Qin
Sent: Thursday, January 6, 2022 5:03 PM
To: devel@edk2.groups.io
Cc: Andrew Fish <afish@...>; Leif Lindholm <leif@...>; Kinney, Michael D <michael.d.kinney@...>; Gao, Liming
<gaoliming@...>; Liu, Zhiguang <zhiguang.liu@...>
Subject: [edk2-devel] [PATCH v1 1/2] EDK2 Code First: PI Specification: New error codes of Host Software class

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3794

This change includes specification update markdown file that describes
the proposed PI Specification v1.7 Errata A in detail and potential
impact to the existing codebase.

Cc: Andrew Fish <afish@...>
Cc: Leif Lindholm <leif@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>

Signed-off-by: Kun Qin <kuqin12@...>
---
CodeFirst/BZ3794-SpecChange.md | 60 ++++++++++++++++++++
1 file changed, 60 insertions(+)

diff --git a/CodeFirst/BZ3794-SpecChange.md b/CodeFirst/BZ3794-SpecChange.md
new file mode 100644
index 000000000000..bbb526896795
--- /dev/null
+++ b/CodeFirst/BZ3794-SpecChange.md
@@ -0,0 +1,60 @@
+# Title: Introduction of `EFI_MM_COMMUNICATE_HEADER_V3` and `MM_COMMUNICATE3_*` interface
+
+## Status: Draft
+
+## Document: UEFI Platform Initialization Specification Version 1.7 Errata A
+
+## License
+
+SPDX-License-Identifier: CC-BY-4.0
+
+## Submitter: [TianoCore Community](https://www.tianocore.org)
+
+## Summary of the change
+
+Introduce `EFI_SW_EC_MEMORY_TYPE_INFORMATION_CHANGE` and `EFI_SW_EC_RELEASE_ASSERT` into Status Codes definition.
+
+## Benefits of the change
+
+Current Status Codes covered various [software class error code
definitions](https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiStatusCode.h).
+
+However, there are a few critical instances where the software could trigger system reboots while the corresponding case was not
covered by the already defined status codes:
+
+1. Memory type information change triggered system reboot;
+2. Assert triggered reboot on systems that did not enable system halts;
+
+The unexpected system reboots above could indicate decay of system health and reporting of such generic events would provide
helpful information to OEMs to investigate/prevent system failures in general.
+
+The request of this change intends to expand definitions of `EFI_SW_EC_**` under Status Codes to cover more unexpected system
reboot events, which could improve Status Code futility and readability.
+
+## Impact of the change
+
+Occupy 2 new macro definitions of Error Codes under Software class Status Codes.
+
+## Detailed description of the change [normative updates]
+
+### Specification Changes
+
+1. In PI Specification v1.7 Errata A: Vol. 3, Table 3-61: Error Code Operations: Host Software Class, add 2 new rows below
`EFI_SW_EC_FV_CORRUPTED` definition:
+
+ | Operation | Description | Extended Data |
+ | --- | --- | --- |
+ | EFI_SW_EC_MEMORY_TYPE_INFORMATION_CHANGE | System will reboot due to memory type information changes | None |
+ | EFI_SW_EC_RELEASE_ASSERT | System software asserted | None |
+
+1. In PI Specification v1.7 Errata A: Vol. 3, Table 3-61: Error Code Operations: Host Software Class, replace the row of
`0x0014–0x00FF` to:
+
+ | Operation | Description | Extended Data |
+ | --- | --- | --- |
+ | 0x0016–0x00FF | Reserved for future use by this specification for Host Software class error codes. | None |
+
+1. In PI Specification v1.7 Errata A: Vol. 3, Section 6.7.4.3 Error Code Definitions: Prototype, add 2 new definitions below
`EFI_SW_EC_FV_CORRUPTED` definition:
+
+ ```c
+ #define EFI_SW_EC_MEMORY_TYPE_INFORMATION_CHANGE 0x00000014
+ #define EFI_SW_EC_RELEASE_ASSERT 0x00000015
+ ```
+
+### Code Changes
+
+1. Add macro definitions in `MdePkg/Include/Pi/PiStatusCode.h` to match new specification.
--
2.34.1.windows.1





Now: TianoCore Design Meeting - APAC/NAMO - 01/07/2022 #cal-notice

devel@edk2.groups.io Calendar <noreply@...>
 

TianoCore Design Meeting - APAC/NAMO

When:
01/07/2022
9:30am to 10:30am
(UTC+08:00) Asia/Shanghai

Where:
Microsoft Teams

Organizer: Ray Ni ray.ni@...

View Event

Description:

TOPIC

  1. NA

For more info, see here: https://www.tianocore.org/design-meeting/


Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Join with a video conferencing device

teams@...

Video Conference ID: 119 715 416 0

Alternate VTC dialing instructions

Learn More | Meeting options


Event: TianoCore Design Meeting - APAC/NAMO - 01/07/2022 #cal-reminder

devel@edk2.groups.io Calendar <noreply@...>
 

Reminder: TianoCore Design Meeting - APAC/NAMO

When:
01/07/2022
9:30am to 10:30am
(UTC+08:00) Asia/Shanghai

Where:
Microsoft Teams

Organizer: Ray Ni ray.ni@...

View Event

Description:

TOPIC

  1. NA

For more info, see here: https://www.tianocore.org/design-meeting/


Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Join with a video conferencing device

teams@...

Video Conference ID: 119 715 416 0

Alternate VTC dialing instructions

Learn More | Meeting options


[PATCH v1 2/2] MdePkg: MmCommunication: Add new Host Software class Error Codes to MdePkg

Kun Qin
 

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3794

This change introduces two new error code definitions under Host Software
class.

The new error code definitions will cover system reboot events under the
conditions of memory type information change and software asserts when
system did not enable system halts.

These error codes could provide helpful datapoints to OEMs to investigate
and prevent system failures in general.

Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>

Signed-off-by: Kun Qin <kuqin12@...>
---
MdePkg/Include/Pi/PiStatusCode.h | 42 ++++++++++----------
1 file changed, 22 insertions(+), 20 deletions(-)

diff --git a/MdePkg/Include/Pi/PiStatusCode.h b/MdePkg/Include/Pi/PiStatusCode.h
index ef2aea7364bc..6a1c9cc30f52 100644
--- a/MdePkg/Include/Pi/PiStatusCode.h
+++ b/MdePkg/Include/Pi/PiStatusCode.h
@@ -965,26 +965,28 @@ typedef struct {
/// These are shared by all subclasses.
///
///@{
-#define EFI_SW_EC_NON_SPECIFIC 0x00000000
-#define EFI_SW_EC_LOAD_ERROR 0x00000001
-#define EFI_SW_EC_INVALID_PARAMETER 0x00000002
-#define EFI_SW_EC_UNSUPPORTED 0x00000003
-#define EFI_SW_EC_INVALID_BUFFER 0x00000004
-#define EFI_SW_EC_OUT_OF_RESOURCES 0x00000005
-#define EFI_SW_EC_ABORTED 0x00000006
-#define EFI_SW_EC_ILLEGAL_SOFTWARE_STATE 0x00000007
-#define EFI_SW_EC_ILLEGAL_HARDWARE_STATE 0x00000008
-#define EFI_SW_EC_START_ERROR 0x00000009
-#define EFI_SW_EC_BAD_DATE_TIME 0x0000000A
-#define EFI_SW_EC_CFG_INVALID 0x0000000B
-#define EFI_SW_EC_CFG_CLR_REQUEST 0x0000000C
-#define EFI_SW_EC_CFG_DEFAULT 0x0000000D
-#define EFI_SW_EC_PWD_INVALID 0x0000000E
-#define EFI_SW_EC_PWD_CLR_REQUEST 0x0000000F
-#define EFI_SW_EC_PWD_CLEARED 0x00000010
-#define EFI_SW_EC_EVENT_LOG_FULL 0x00000011
-#define EFI_SW_EC_WRITE_PROTECTED 0x00000012
-#define EFI_SW_EC_FV_CORRUPTED 0x00000013
+#define EFI_SW_EC_NON_SPECIFIC 0x00000000
+#define EFI_SW_EC_LOAD_ERROR 0x00000001
+#define EFI_SW_EC_INVALID_PARAMETER 0x00000002
+#define EFI_SW_EC_UNSUPPORTED 0x00000003
+#define EFI_SW_EC_INVALID_BUFFER 0x00000004
+#define EFI_SW_EC_OUT_OF_RESOURCES 0x00000005
+#define EFI_SW_EC_ABORTED 0x00000006
+#define EFI_SW_EC_ILLEGAL_SOFTWARE_STATE 0x00000007
+#define EFI_SW_EC_ILLEGAL_HARDWARE_STATE 0x00000008
+#define EFI_SW_EC_START_ERROR 0x00000009
+#define EFI_SW_EC_BAD_DATE_TIME 0x0000000A
+#define EFI_SW_EC_CFG_INVALID 0x0000000B
+#define EFI_SW_EC_CFG_CLR_REQUEST 0x0000000C
+#define EFI_SW_EC_CFG_DEFAULT 0x0000000D
+#define EFI_SW_EC_PWD_INVALID 0x0000000E
+#define EFI_SW_EC_PWD_CLR_REQUEST 0x0000000F
+#define EFI_SW_EC_PWD_CLEARED 0x00000010
+#define EFI_SW_EC_EVENT_LOG_FULL 0x00000011
+#define EFI_SW_EC_WRITE_PROTECTED 0x00000012
+#define EFI_SW_EC_FV_CORRUPTED 0x00000013
+#define EFI_SW_EC_MEMORY_TYPE_INFORMATION_CHANGE 0x00000014
+#define EFI_SW_EC_RELEASE_ASSERT 0x00000015
///@}

//
--
2.34.1.windows.1


[PATCH v1 1/2] EDK2 Code First: PI Specification: New error codes of Host Software class

Kun Qin
 

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3794

This change includes specification update markdown file that describes
the proposed PI Specification v1.7 Errata A in detail and potential
impact to the existing codebase.

Cc: Andrew Fish <afish@...>
Cc: Leif Lindholm <leif@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>

Signed-off-by: Kun Qin <kuqin12@...>
---
CodeFirst/BZ3794-SpecChange.md | 60 ++++++++++++++++++++
1 file changed, 60 insertions(+)

diff --git a/CodeFirst/BZ3794-SpecChange.md b/CodeFirst/BZ3794-SpecChange.md
new file mode 100644
index 000000000000..bbb526896795
--- /dev/null
+++ b/CodeFirst/BZ3794-SpecChange.md
@@ -0,0 +1,60 @@
+# Title: Introduction of `EFI_MM_COMMUNICATE_HEADER_V3` and `MM_COMMUNICATE3_*` interface
+
+## Status: Draft
+
+## Document: UEFI Platform Initialization Specification Version 1.7 Errata A
+
+## License
+
+SPDX-License-Identifier: CC-BY-4.0
+
+## Submitter: [TianoCore Community](https://www.tianocore.org)
+
+## Summary of the change
+
+Introduce `EFI_SW_EC_MEMORY_TYPE_INFORMATION_CHANGE` and `EFI_SW_EC_RELEASE_ASSERT` into Status Codes definition.
+
+## Benefits of the change
+
+Current Status Codes covered various [software class error code definitions](https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiStatusCode.h).
+
+However, there are a few critical instances where the software could trigger system reboots while the corresponding case was not covered by the already defined status codes:
+
+1. Memory type information change triggered system reboot;
+2. Assert triggered reboot on systems that did not enable system halts;
+
+The unexpected system reboots above could indicate decay of system health and reporting of such generic events would provide helpful information to OEMs to investigate/prevent system failures in general.
+
+The request of this change intends to expand definitions of `EFI_SW_EC_**` under Status Codes to cover more unexpected system reboot events, which could improve Status Code futility and readability.
+
+## Impact of the change
+
+Occupy 2 new macro definitions of Error Codes under Software class Status Codes.
+
+## Detailed description of the change [normative updates]
+
+### Specification Changes
+
+1. In PI Specification v1.7 Errata A: Vol. 3, Table 3-61: Error Code Operations: Host Software Class, add 2 new rows below `EFI_SW_EC_FV_CORRUPTED` definition:
+
+ | Operation | Description | Extended Data |
+ | --- | --- | --- |
+ | EFI_SW_EC_MEMORY_TYPE_INFORMATION_CHANGE | System will reboot due to memory type information changes | None |
+ | EFI_SW_EC_RELEASE_ASSERT | System software asserted | None |
+
+1. In PI Specification v1.7 Errata A: Vol. 3, Table 3-61: Error Code Operations: Host Software Class, replace the row of `0x0014–0x00FF` to:
+
+ | Operation | Description | Extended Data |
+ | --- | --- | --- |
+ | 0x0016–0x00FF | Reserved for future use by this specification for Host Software class error codes. | None |
+
+1. In PI Specification v1.7 Errata A: Vol. 3, Section 6.7.4.3 Error Code Definitions: Prototype, add 2 new definitions below `EFI_SW_EC_FV_CORRUPTED` definition:
+
+ ```c
+ #define EFI_SW_EC_MEMORY_TYPE_INFORMATION_CHANGE 0x00000014
+ #define EFI_SW_EC_RELEASE_ASSERT 0x00000015
+ ```
+
+### Code Changes
+
+1. Add macro definitions in `MdePkg/Include/Pi/PiStatusCode.h` to match new specification.
--
2.34.1.windows.1


[PATCH v1 0/2] EDK2 Code First: PI Specification: Update EFI_MM_COMMUNICATE_HEADER

Kun Qin
 

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3794

In current Status Codes definitions of PI spec v1.7 errata, there are a
few critical instances where the software could trigger system reboots
while the corresponding case were not covered by the already defined
status codes.

Two scenarios that OEMs could be interested are memory type information
change triggered system reboot and assert triggered reboot on systems
that did not enable system halts.

The unexpected system reboots above could indicate decay of system health
and reporting of such generic events would provide helpful information to
OEMs to investigate/prevent system failures in general.

The change intends to expand definitions of `EFI_SW_EC_**` under Status
Codes to cover more unexpected system reboot events, which could improve
Status Code futility and readability.

Patch v1 branch: https://github.com/kuqin12/edk2/tree/BZ3794-expand_status_codes_v1

Cc: Andrew Fish <afish@...>
Cc: Leif Lindholm <leif@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>

Kun Qin (2):
EDK2 Code First: PI Specification: New error codes of Host Software
class
MdePkg: MmCommunication: Add new Host Software class Error Codes to
MdePkg

CodeFirst/BZ3794-SpecChange.md | 60 ++++++++++++++++++++
MdePkg/Include/Pi/PiStatusCode.h | 42 +++++++-------
2 files changed, 82 insertions(+), 20 deletions(-)
create mode 100644 CodeFirst/BZ3794-SpecChange.md

--
2.34.1.windows.1


Re: Guidance about CI

Boeuf, Sebastien
 

On Wed, 2022-01-05 at 17:55 +0100, kraxel@... wrote:
On Wed, Jan 05, 2022 at 01:44:01PM +0000, Boeuf, Sebastien wrote:
Ah nevermind I found out QEMU was installed from packaging.
On ubuntu.

We don't have packages for Cloud Hypervisor, but we can download
a static binary from a specific release, do you think that would be
acceptable?
As far I know the same happens for qemu on windows,
so that should be fine.
Cool!

BTW, about microvm, I saw that you're skipping QEMU, so does that mean
you're not *really* testing that OVMF works with microvm, or am I
missing something?

Thanks,
Sebastien


take care,
  Gerd
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: Change from "BaseTools/LzmaCompress: Fix possible uninitialized variable" patch was reverted

Denis Nikitin <denik@...>
 

Thanks for confirmation. I agree that the warning doesn't look severe.

- Denis

On Wed, Jan 5, 2022 at 4:46 PM Wu, Hao A <hao.a.wu@...> wrote:

Hello Denis,

As far as I can recall, the fix you mentioned is a change that to please the static analysis tool.
My opinion is that it not a critical fix.

Best Regards,
Hao Wu

-----Original Message-----
From: Denis Nikitin <denik@...>
Sent: Thursday, January 6, 2022 3:19 AM
To: Wu, Hao A <hao.a.wu@...>
Cc: liming.gao@...; yonghong.zhu@...; devel@edk2.groups.io;
Ramasubramanian, Karthik <kramasub@...>
Subject: Change from "BaseTools/LzmaCompress: Fix possible uninitialized
variable" patch was reverted

Hi Hao,

While updating edk2 in Chrome OS we noticed that the change in your patch
https://edk2.groups.io/g/devel/message/19270 was reverted in
commit:
5ec5a236d1 BaseTools Lzma: Update LZMA SDK version to 18.05.

If you think the fix is critical I think it should be merged in https://www.7-
zip.org/sdk.html.

Thanks,
Denis


Re: EFI shell with microvm

Boeuf, Sebastien
 

On Thu, 2022-01-06 at 13:44 +0100, kraxel@... wrote:
On Thu, Jan 06, 2022 at 11:25:37AM +0000, Boeuf, Sebastien wrote:
Hi Gerd,

I was looking at a way to add support for EFI shell interaction
with Cloud Hypervisor when
I realized you added the support for microvm with commit
55f47d22998.
I have been able to hack OvmfPkgX64 similarly to get it to work,
but here are two follow up
questions:
How do you want interact?  Serial console?  That should work just
fine
with OvmfPkgX64.
Yes I'd like to use the serial console (available on PIO 0x3f8) to
interact with the EFI shell.


qemu-system-x86_64 -nographic -bios
Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd -net none

Possibly you have to add the cloud hypervisor pci id somewhere so isa
lpc and serial line driver are initialized properly.  SioBusDxe looks
like a hot candidate.

microvm has no lpc bridge, so I had to do it in a different way ...
Cloud Hypervisor doesn't emulate any LPC bridge or ISA bus.


2. I can see the shell but I can't interact with it, do you have a
similar behavior with microvm
or is it because I'm missing the interrupt support?
Works fine for me.

qemu-system-x86_64 -nographic -machine microvm,rtc=on -bios
Build/MicrovmX64/DEBUG_GCC5/FV/MICROVM.fd
Thanks for the confirmation, something might be wrong with the
interrupt used for my serial device.
Cloud Hypervisor only has an IOAPIC, it doesn't rely on any PIC, which
is why I'm not sure what might be missing to get the EFI shell to
receive the interrupts.


HTH,
  Gerd
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: EFI shell with microvm

Gerd Hoffmann
 

On Thu, Jan 06, 2022 at 11:25:37AM +0000, Boeuf, Sebastien wrote:
Hi Gerd,

I was looking at a way to add support for EFI shell interaction with Cloud Hypervisor when
I realized you added the support for microvm with commit 55f47d22998.
I have been able to hack OvmfPkgX64 similarly to get it to work, but here are two follow up
questions:
How do you want interact? Serial console? That should work just fine
with OvmfPkgX64.

qemu-system-x86_64 -nographic -bios Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd -net none

Possibly you have to add the cloud hypervisor pci id somewhere so isa
lpc and serial line driver are initialized properly. SioBusDxe looks
like a hot candidate.

microvm has no lpc bridge, so I had to do it in a different way ...

2. I can see the shell but I can't interact with it, do you have a similar behavior with microvm
or is it because I'm missing the interrupt support?
Works fine for me.

qemu-system-x86_64 -nographic -machine microvm,rtc=on -bios Build/MicrovmX64/DEBUG_GCC5/FV/MICROVM.fd

HTH,
Gerd


EFI shell with microvm

Boeuf, Sebastien
 

Hi Gerd,

I was looking at a way to add support for EFI shell interaction with Cloud Hypervisor when
I realized you added the support for microvm with commit 55f47d22998.
I have been able to hack OvmfPkgX64 similarly to get it to work, but here are two follow up
questions:

1. Is it possible to support it as well from OvmfPkgX64 without breaking the current support
for QEMU?

2. I can see the shell but I can't interact with it, do you have a similar behavior with microvm
or is it because I'm missing the interrupt support?

Thanks,
Sebastien
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: AArch64 assembly compatibility for Xcode and GCC

Akira Moroo
 

Hi,

I tried to add support AArch64 XCODE5 about three months ago, too. I had the same compatibility issue in the other code. I just ended up adding ugly #ifdef as a workaround [1]. I think there are other compatibility issues in the current EDK2 code base. I’m not sure if the GAS macro and Apple Clang Assembler are compatible, but the C standard guarantees C preprocessor macro compatibility.

[1] https://github.com/retrage/edk2/commit/89b166758b9f858373bb20eb8e006914f7f13373

Best regards,

Akira Moroo

On Jan 6, 2022, at 8:31, Pedro Falcato <pedro.falcato@...> wrote:

Hi,

GNU Assembler and the clang assembler support more complex macros natively (using the .macro and.endm directives), without the need for the C preprocessor.
This completely sidesteps the need for explicit ";" as the GAS macros respect newlines inside the macro.

See https://godbolt.org/z/6zzqoeKE4 for a very simple example.
Of course, you can also pass arguments, see https://sourceware.org/binutils/docs/as/Macro.html for the full documentation.

Best regards,
Pedro

On Wed, Jan 5, 2022 at 8:36 PM Andrew Fish via groups.io <afish@...> wrote:
I was playing around with getting Xcode to compile AArch64 code and I hit an interesting compatibility issue. The assembler line continuation token for GCC (;) is a comment for the Xcode clang assembler. For Xcode clang you need to use %%. Yikes [1]

I was wondering if any one else has hit this in another project and if there was any cool workaround?

The only thing I can think of is the “big hammer” on both (well you only need one) ends. We could replace ; with a #define that matches the assembler. It looks like this issue mostly hits in Code that is using C pre-processor macros so we could refactor the code. I’m a little concerned that the C pre processor is getting used since the macro languages of the assembler might also have some compatibility issues?

Looking for ideas and opinions on the best way to fix this if we want to add Xcode as an ARM compiler in the future.


[1] https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.S#L13

#define GPR_LAYOUT \
REG_PAIR (x19, x20, 0); \
REG_PAIR (x21, x22, 16); \
REG_PAIR (x23, x24, 32); \
REG_PAIR (x25, x26, 48); \
REG_PAIR (x27, x28, 64); \
REG_PAIR (x29, x30, 80);/*FP, LR*/ \
REG_ONE (x16, 96) /*IP0*/

I had to change it to:

#define GPR_LAYOUT \
REG_PAIR (x19, x20, 0)%% \
REG_PAIR (x21, x22, 16)%% \
REG_PAIR (x23, x24, 32)%% \
REG_PAIR (x25, x26, 48)%% \
REG_PAIR (x27, x28, 64)%% \
REG_PAIR (x29, x30, 80)%%/*FP, LR*/ \
REG_ONE (x16, 96) /*IP0*/

Thanks,

Andrew Fish





--
Pedro Falcato


Re: [Patch MBR endless loop hang with invalid LBA0 1/1] MdeModulePkg/PartitionDxe: Add break to handle invalid LBA0 in MBR

Wu, Hao A
 

Inline comment below:

 

 

From: Edwards, Craig <Craig.Edwards@...>
Sent: Thursday, January 6, 2022 2:53 AM
To: Gao, Liming <gaoliming@...>; Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>; Ni, Ray <ray.ni@...>; Gao, Zhichao <zhichao.gao@...>; devel@edk2.groups.io; Shutt, Mark <mark.shutt@...>
Subject: [Patch MBR endless loop hang with invalid LBA0 1/1] MdeModulePkg/PartitionDxe: Add break to handle invalid LBA0 in MBR

 

Read Disk does a modification of ExtMbrStartingLba with the code MultU64x32

(ExtMbrStartingLba, BlockSize) Error detection to see if ExtMbrStartingLBA

has a value of 0. This is invalid as LBA 0 = MBR. After modification, the

next time ExtMbrStartingLba is in this function if ExtMbrStartingLba is set

to 0 in the MBR it never passes the while/do evaluation It is multiplied by 0

by read disk , set to 0 by an invalid MBR and goes back to evaluation This

condition will also cause Ws19 and WS22 to hang, however Microsoft has

developed a hotfix patch that will be released in 2022

 

Cc: Liming Gao <gaoliming@...>

Cc: Jian J Wang <jian.j.wang@...>

Cc: Hao A Wu <hao.a.wu@...>

Cc: Ray Ni <ray.ni@...>

Cc: Zhichao Gao <zhichao.gao@...>

 

Signed-off-by: Craig Edwards <craig.edwards@...>

 

Date:      Wed Jan 5 12:27:46 2022 -0600

 

On branch graceful_handle_mbr_hang_edit1

Changes to be committed:

        modified:   MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c

---

MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 6 ++++++

1 file changed, 6 insertions(+)

 

diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c

index 0f8dc5486521..ad18840e5efd 100644

--- a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c

+++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c

@@ -293,6 +293,12 @@ PartitionInstallMbrChildHandles (

           (Mbr->Partition[0].OSIndicator == EXTENDED_WINDOWS_PARTITION))

       {

         ExtMbrStartingLba = UNPACK_UINT32 (Mbr->Partition[0].StartingLBA);

+          //

+          // A value of 0 is invalid for StartingLBA

+          //

+          if (ExtMbrStartingLba == 0) {

+            break;

+          }

 

 

Seems the indent includes 2 unneeded spaces. I will help to remove them when merging the patch.

Reviewed-by: Hao A Wu <hao.a.wu@...>

 

Will wait a couple of days before merging to see if comments from other reviewers.

 

Best Regards,

Hao Wu

 

 

         continue;

       }

 

--

2.32.0.windows.1

 

 

 

 

 

Craig Edwards

Software Engineer

Dell | GDP | PSE | COMMS | BIOS

 

 

 


Internal Use - Confidential

 


Re: Change from "BaseTools/LzmaCompress: Fix possible uninitialized variable" patch was reverted

Wu, Hao A
 

Hello Denis,

As far as I can recall, the fix you mentioned is a change that to please the static analysis tool.
My opinion is that it not a critical fix.

Best Regards,
Hao Wu

-----Original Message-----
From: Denis Nikitin <denik@...>
Sent: Thursday, January 6, 2022 3:19 AM
To: Wu, Hao A <hao.a.wu@...>
Cc: liming.gao@...; yonghong.zhu@...; devel@edk2.groups.io;
Ramasubramanian, Karthik <kramasub@...>
Subject: Change from "BaseTools/LzmaCompress: Fix possible uninitialized
variable" patch was reverted

Hi Hao,

While updating edk2 in Chrome OS we noticed that the change in your patch
https://edk2.groups.io/g/devel/message/19270 was reverted in
commit:
5ec5a236d1 BaseTools Lzma: Update LZMA SDK version to 18.05.

If you think the fix is critical I think it should be merged in https://www.7-
zip.org/sdk.html.

Thanks,
Denis


Re: AArch64 assembly compatibility for Xcode and GCC

Pedro Falcato
 

Hi,

GNU Assembler and the clang assembler support more complex macros natively (using the .macro and.endm directives), without the need for the C preprocessor.
This completely sidesteps the need for explicit ";" as the GAS macros respect newlines inside the macro.

See https://godbolt.org/z/6zzqoeKE4 for a very simple example.
Of course, you can also pass arguments, see https://sourceware.org/binutils/docs/as/Macro.html for the full documentation.

Best regards,
Pedro

On Wed, Jan 5, 2022 at 8:36 PM Andrew Fish via groups.io <afish=apple.com@groups.io> wrote:
I was playing around with getting Xcode to compile AArch64 code and I hit an interesting compatibility issue. The assembler line continuation token for GCC (;) is a comment for the Xcode clang assembler. For Xcode clang you need to use %%. Yikes [1]

I was wondering if any one else has hit this in another project and if there was any cool workaround?

The only thing I can think of is the “big hammer” on both (well you only need one) ends. We could replace ; with a #define that matches the assembler. It looks like this issue mostly hits in Code that is using C pre-processor macros so we could refactor the code. I’m a little concerned that the C pre processor is getting used since the macro languages of the assembler might also have some compatibility issues?

Looking for ideas and opinions on the best way to fix this if we want to add Xcode as an ARM compiler in the future. 



#define GPR_LAYOUT \
REG_PAIR (x19, x20, 0); \
REG_PAIR (x21, x22, 16); \
REG_PAIR (x23, x24, 32); \
REG_PAIR (x25, x26, 48); \
REG_PAIR (x27, x28, 64); \
REG_PAIR (x29, x30, 80);/*FP, LR*/ \
REG_ONE (x16, 96) /*IP0*/
I had to change it to:

#define GPR_LAYOUT \
REG_PAIR (x19, x20, 0)%% \
REG_PAIR (x21, x22, 16)%% \
REG_PAIR (x23, x24, 32)%% \
REG_PAIR (x25, x26, 48)%% \
REG_PAIR (x27, x28, 64)%% \
REG_PAIR (x29, x30, 80)%%/*FP, LR*/ \
REG_ONE (x16, 96) /*IP0*/
Thanks,

Andrew Fish



--
Pedro Falcato


Re: [edk2-non-osi] [PATCH V2] WhitleyOpenBoardBinPkg : Update JunctionCity IFWI binaries

Isaac Oram
 

Pushed as: eef5e03..d02501a

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Oram, Isaac W
Sent: Tuesday, January 4, 2022 2:12 PM
To: devel@edk2.groups.io; KARPAGAVINAYAGAM, MANICKAVASAKAM <manickavasakamk@...>
Cc: Desimone, Nathaniel L <nathaniel.l.desimone@...>; DOPPALAPUDI, HARIKRISHNA <harikrishnad@...>; Jha, Manish <manishj@...>; Bobroff, Zachary <zacharyb@...>
Subject: Re: [edk2-devel] [edk2-non-osi] [PATCH V2] WhitleyOpenBoardBinPkg : Update JunctionCity IFWI binaries

Reviewed-by: Isaac Oram <isaac.w.oram@...>

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of manickavasakam karpagavinayagam via groups.io
Sent: Wednesday, December 29, 2021 9:53 AM
To: devel@edk2.groups.io
Cc: Desimone, Nathaniel L <nathaniel.l.desimone@...>; Oram, Isaac W <isaac.w.oram@...>; DOPPALAPUDI, HARIKRISHNA <harikrishnad@...>; Jha, Manish <manishj@...>; Bobroff, Zachary <zacharyb@...>; KARPAGAVINAYAGAM, MANICKAVASAKAM <manickavasakamk@...>
Subject: [edk2-devel] [edk2-non-osi] [PATCH V2] WhitleyOpenBoardBinPkg : Update JunctionCity IFWI binaries

Update JunctionCity IFWI binaries
- Recreate JunctionCity FlashDescriptor and ME binaries

Notes :
V2 :

Patch V1 had WilsonCityRvp binaries instead of JunctionCity binaries
Recreate JunctionCity binaries

Cc: Nate DeSimone <nathaniel.l.desimone@...>
Cc: Isaac Oram <isaac.w.oram@...>
Cc: Harikrishna Doppalapudi <harikrishnad@...>
Cc: Manish Jha <manishj@...>
Cc: Manickavasakam Karpagavinayagam <manickavasakamk@...>
Cc: Zachary Bobroff <zacharyb@...>

Signed-off-by: Manickavasakam Karpagavinayagam <manickavasakamk@...>
---
Platform/Intel/WhitleyOpenBoardBinPkg/Ifwi/JunctionCity/FlashDescriptor.bin | Bin 4096 -> 4096 bytes
Platform/Intel/WhitleyOpenBoardBinPkg/Ifwi/JunctionCity/Me.bin | Bin 50327552 -> 50327552 bytes
2 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/Platform/Intel/WhitleyOpenBoardBinPkg/Ifwi/JunctionCity/FlashDescriptor.bin b/Platform/Intel/WhitleyOpenBoardBinPkg/Ifwi/JunctionCity/FlashDescriptor.bin
index 040fd9cc7a29c26e2f6692788812a9741d6cfbfd..9ecbe0b0c1f64d8ec428c013e6492d03b5838a6a 100644 GIT binary patch delta 171 zcmZorXi!+dD6YW3z>omMaL{~^>AOA0WN}7S5mp8f23DX13y5F{1@ageCI>J^F)~fw
z&nP~59izzPYm5Ovo;s5+8%POIx{66o3C#Gw@!`v#KYs+k!cYRnk(j)TNtyF&!|DA%
o2?3+Y&zSTW8#jwG&*tWM@1Ve-s=&Z7aiI&#eIo{j#UEK10YW_^KmY&$

delta 162
zcmZorXi!+dD6YuBz>o;UAixB~|NsAI`o5oYvN)rvNCCSDLjgMj1CId%!`=U(3?dBn
zERzEmqbBcTl$bn=QDE{V#*oQYOk$I5m@L@rL7JH-S24*c{r}IvF!=+=hcAEr{1E^d
vECC{rfWYKkOv;>7C!F376ck{Z{ESJD@!)1r=Goj67y7W=2U@rIBMTz{`_d}p

diff --git a/Platform/Intel/WhitleyOpenBoardBinPkg/Ifwi/JunctionCity/Me.bin b/Platform/Intel/WhitleyOpenBoardBinPkg/Ifwi/JunctionCity/Me.bin
index 5e60376d53ff776f16c4e3a6bba72828093dbb4b..a24a0525a56d18b8c64c748ece9292172394ca9d 100644 GIT binary patch delta 11799
zcmbu^37k#!|3C0^KKIVdJ!iJVEN132X6`J;Y?u*ataFiln;}a`BqGa<Pzl`;J|aY)
z@*#?7-xQS=qLm~@(V~)2Y4xToWtrdWT&_;v|F{3Q(e-%xyw3KyXS?@&?t3Z^RM)A5
z=fVqOldJKHaeFoU<qrHSUY}a<Q}o{~@qHhiRCnAX6Ed;-V^?X~`>-uc)8t@H>(zXH
zdg<iB5l1%OF}$R?rln3<5~=2$4)e)FPw(-2bzRe9bn7>4>e7(45bG4OZs)_AbsD+S
z&JntGYduZ#*m;i2szi3%dAZA)g=}x3i3^$R{D8}vl%;72cD~DH%}0(!){$2s+v}Tm
zx%`(V!W|1D968dFqZ~Qfk(ndA9NF#2A&wk+Df@LT?9zm;c^uhrWNqGsy$+m}NZoqq
z;t^=;v_Q7(qtux7Jmv@1(V4X_m~(Y&eK6<f)(gm9d;R*lwZ|Wv$i^iI<~ZGot*>eE
z_DVl%RxYw(=Xl+^0(q#Nk7|}gZfEC)y0sTM($0-^>tHa~(XFG%_AY4)9l7^~Y+p*h
z)<w5YVWrvjN}Y9UTK2_j++DY3Av62_Xs=r$=i)l;bSpgf;yN95D<+tG=@t*>9=eqg
z%sq80FPJ;v0D`%jZnezC`v=~*t!`}zF1S*+wgq!n-Ks(ktkX%i`sQ7H<AJ($4RYXQ
zJ2G=*mm|9!ImD4e2m1f)D9o|I<H&|1n~ogr$Ptbl>Bv!z9PP+fF#B=ZYXv8eYddm`
zBgZ;&oFm6OaveubaO6ZsPI6?9><^yCWXFQKj-2AisgA6*(k@*Bt<8meoqZ3LXx3(2
znn3nxR$BhW8?d7zx4xA9n%3#kgr;@7kOLcc*Q}YrjeA_kf%!c(>l@4u<WZW{slmlO
zTC<)&4&3cy9l6|*OZC7y-R&K{TDML#!21Wj(aLn|95!xh-|Z>7)wt1xj&w(6j_h(|
zw<Cu*a;PJRIkLx*4ZmZ;bmVYHj&S5iM~-sjXh*gjxt1f>cI23g8ON_{v5p0CjvVjE
zbsRatkrN#`$&tAuCp&UoM@~u6{g+O4s$+rIk<%PG-H|gKIn$BrIdYaG*LURXOBvt)
zIhQ7ME!UCr968^S8#r=9M{eZE1&&<k$c-KO3OoBR-e^r63z|A|ks~*A<YGr|?#S97
zTHuVD_8rc3s}=eWwR56wwL{LbbAoP-Lau}C*OKrhfC>BAtR?G~L=Jo+4Bc9e%<TCs
zb?X7-z(=dtk&7I;g(J6e<mQgt#*v!^GVVY74O%-ElsNMI3pwz3y-K&9!A^W(uisa<
z<`!sLzWs6SqgyW)YFeuh<bJw!tVq*}>~;F<R{drdk9dG?^+0Z9&yU4J4mt3ce$%g6
z(=ibk$$Y6<GlF@)X3Y-fXuMf4Te`I%m}}|Q;$W_=TlWQXxNa>&4m`BJ*Q}J{i~awg
zS?S2t_D*<oD-C0@s5E=Rr(2Ee2|ItSS*?)+dv{2)+B8>{E>DU~7-X@gIqP!=J<eq5
zboctSSBJ-|E+4Z->o-^377~dK@%Znig=nP{Ju>Z<*ywBw4TfkdwHz%D1BqPOc6ynj
z><EvnoEEEmg%J@55vn3H!Yyx~Ib%r{+TaW|HrthecL|XxbFR0S)Q<GzP;+WQEh*QV
zo0glE=am!Yu5*X5PL|w#c!(^YU#^q<YW_=#3S4g8D~J5hNsd_@=-*SQRre_EW8Xa(
zVfH9(+PpEYT<{h8XFlS_xw$7&)6S_1w<lXwonf`H7qw~<qM7bit<SO?dH#5WuE{r+
z7G~)z_-4U26d@%zaj}(OFWa_0a(RL7j?%OO*>=T;{v0hwFVkD*YdNuc$hL63+F$K2
zDZ$4{^V%Cx*tmVTn2uLf=RWNVyj{juOrGQ|Ex%>NO}Sd`g&uNa^{{O$*aHrf;o@jt
zU+CfdsUyKooISYvm5-gIDw!*O{rS^<-K?phYK6IyLU1@NW_|9OCHhRWdV^W5pDf)_
zP{FQ9TvEz<dIyCM3cn-#bbhT=BRnRrZJYAQ@~|CEw)3Utlg+*P)&9k0OE$R6*v2q5
z<SOP>SN3J;c50WG#5qsqb$JR;<zAk~(|HEZ<n?$Kug|l24$tLzJfAn<4S6wcrZ{%+
zb2JTOYw_AVhR5<a9?$FW1fIy}9tw2LERGdY{K<=3m@Um#W^1#JSz`Lkwq`rCy?LeC
z!R%;uGCP}H%&ulPv%A^D>}mEgOU*K~BzQJ1ws+S~GP#*-)-_YiRMTswndxSRnQ7KD
zv&{NtwwYt*nt5iv*}!aQHZlv$LbI`Xh1tYxY8IKz{ARJ)+&uKjAI2HutZ~jbZ&Vwa
zshiAnnQk-03^l_{k7<~u8E!_Hk!F+`ZCYk6v$h#y#+q?vyjjOgFcZzboAw!>8($b-
z8vBi}j048k#zEtdaoG6A_}2K&IAVNn{9ycO{AB!W{9+t6$T(&kH-0sKGa^nHCyi6a
zY2$ZeUPJqYbbQa)ZoF^oFg`GL8oP`tW4H04@sY8|*lT=jd}4fRd}c)Tzl~4j)A)3L
zJNNTSK7-%EXYyHmHWz#jzmw19+l;`uEo(WD58{LQHGBxamJj8__;q|Zzn+iaBl!({
z6d%oR<YV|)K8}y)<-CGV;5YG!d=j6`Z|1k~Tlo~;r>F&Q$y@Q(ybUkmKHiqM<L&vC
zyaVsZJMqrE3-8Li@$S3_@5y`dQeMV;^FI74-k0~|{k!l1{Aym2S%X_gE8vB^F~5R0
z;Z1oFZ^nyxbDnsuea9q+HsYFg;jUrBCTvKnVAsXGRKdn>!MA`{kCs)3OE&B%aQzl9
z{X2cE@n>=~nv{*Q8cp0eRb{w*?6KvlU@!BrwePBm98a=bG%=G|WwLsgkNrAaemctM
zzIBZjjgyxo{qJP5MlICfaBP;JqaL)|-fyV`cKcWt)g}*{``^uECy%H~WK|jA%4CHT
z<<c8{EVZ>-<n<IwYmA5eR#*1g=wnN^sj-oESHH+z8{^f1d{3yX-kQla6)M7fy-XEG
zx!SUQq!u+mZ;PVP+pO(sNIJTy8tY+)Gu0|PTjM-zK9^^Q`B?4!YFacleP3;g#->>}
zs>*QeRLS;CeSrGF!mRYg%BqDmeph9+Fu8P{dajBktLJLDGGkWHnsaO4Ck=dv?5BgF
zeZYQJwW`>dB||-y?6t+mO18_px3o|dyICkpPEkE0(RcOxne3huYDH}v$=M9q>kS{P
zJfyranA|Z!-JWIdY=wtCY^p7GwkCMk3sRmP;bYYcWvh`sw)dbK5^Z<%K_(jztyV>Q
z>Pp|v4E9l|`Xv^<^dVIchj!1Gs={z#y`7mXYMiRdwtJiCVQ+7jXK(Pax?5$dQ9h=<
zA*Z1^)ktlO$6<C?=i*)I_H!?ly;UUFR{2=;Sa}pp-SMibj;o1Gm>j{5rpfZ%J~r|d
zIc&0z?K+62Sbj0t!xl-|=tCb%8!5}t%$_FKqFH^9Jc?%0d37Ms)g;O;yaZpxYZjOJ
zSc7Sc%VOn}Dfz5oqdfYNPk%}+ZqX=SolA11;?9g<w+z7j6sJnKD^)G{f<>^Kj>)xq
ze5^bN^IOTvN;k_YR>ZM;iBlt3?^Id7*T?8(xfYGgkw^FX5>rmTu5Hma<GFC*a{c9D
zUgtj^<`=#fpX!3{ee9XR>R7#qn7=&NU3%B6<<yxz_U04zI<5h0n4B;zCh)j-KHbAv
zZi&p9<70RB3mk$yK&bcsKI}F6kAKDp^?U<Y>ky5irrs+f4&#F}P<B6@790_9*3cVV
zL(ADG$Ikb$jXTssxvqMWe-~*{kye1gn4$I6`f2@-Rm-2S!sjbw{sJH41MKy30waky
zFAg<?u^D*GF18=Fuwa%dZ0xG1Dhgc|#u(vO?tU+Dg9lDZO-CB`M!L4jzEJ7GaYh7t
z`eC`7@QMCi?p8k5bNP}YS7S?ev)JltJ-oUaI}~yzPJVqnCosZ@XXP%Xk4#9e|4#-Q
z1#L78HA>i#sp|PwuI2{AWyh;`h8%joFZ=;(qPPFBo5qhGe}jx%-i$3>AQztSv4L->
z)Hbd-xomkJ3*WDX+4(c%Gr!87Cz~7gh=oeD*oWo9llZ*OlsnP<u}nst^7&nLyY%w5
z?_1i(d+}A{QBCzX&QVDX$2E!e!D&BYu;c9H(#S@hKb^oLMycnRD_getJ%Lpv%7~Rd
zHvb0MePvsHr<{+8x6jI<XJX}nmHF%pml3P*<?)N$@?fkSx+<S_%T%|!vGMso5?J0&
zHKQF)&B|4w>e=?LdMvxO^0#x<k>k$fxTi#Fmg-f4skLY7vyvs!TFvES57i4PJYAyI
zlE+Ra$?qS^U>|45h}AweZKUjuX2?mkFx2k-Yyz8qLRHzh&AGUcrUvUaQAVsuyf7M*
zxogr{(^0bf8XxQTgPf1%czwAW&FY*$)ATvJ!Pr#y;QMQ{#}y{epReQ6I?Z^#%<C2v
zE>VI1LqtXBOBG?YhpO6D?6xJ1Biw2cg|%WokHGy|ykwZ^Va=x~>sXkN<@HbpDoh_c
zH(q%spk1D%hT84%y{h!hNFOtwQj6?1bFQkg+ldb->n*fvS}X6b*#1l}waA{XyF*pk
zZR`qVy^Z#8iYm3+A4Ak4yS=Z2s<K;spR(RTd)!b3C$Rk~?3z8DF<xzXCo)OxJQ0?~
zlEx_Csjvh^??h&^T|cVQcd^Fx{naA7T`);i+3oC?m9-UZ=~ed1c&t33Dz`?as8y%J
z(plFZ96fYwBFmN~sDgLV+vIzf*c*+i6R2FXW24j#RIpixFI3d;XthFBiq=1RleWNR
zy_|rbvf=hq4;9u74A<?SiT|+1ec!kLqRQ<Ll)0Z-`d<p&HL7#J*WmIh-G2MSrfYVo
zyJ%yu%Km4uyJofS+m7n?7i&$b-F7t-KY1>dyYFm`pHP1-cxT~q*lYd6diQZvlZv-r
z`!6N$vi9~l(HuqZn%2C}ZqWW&)!YBKW$yy@ABFE4*S#MM4U}aZC0N~&FI2uSUjM%<
zeJ4Hm*W!20Yu`P!V7>UiR=@4*|G&!Lk9M~&$E5-|a!u>s2R{D03b_BDmcYY?1dqcm
zf(LU=YT#Su1@5Z9R>A#&t^$?me^3VRJXZU&5Pn&8@D*GCS_#MX54?E|O5sgie-^_p
zuNI!L{ZcjDzW$d}4)5@7u;6YuYMC{vhmWx@hyUM{#HV!&7RBwZE~h45;a?g&j>|2J
z-?Ghqa}>ret1gb~uWP>j|F$$9Srt5t8rH`BTCh0&^C^2*{!MxO?$SVk{9@VppVi0l
z*Sz4K+XeE2nZc>cEs=-nc9Hxa*T{p_e9ciLpI)H-%QE@POD`4Q|3{tN|96G*y50Y6
zsr<{;+MEBgR*w7c|5GeqSN?Cy<&O*w)X4v~UhckBFppif$sKQLUN8Pu(5;W@!nmku
zj?5j@knLS52MqGD@3*S1$*9Bl+@4Ifa+j)T7!j*hC3`$_%bsxjtWQL>#QyE9uTZ<&
z=Vf3{3JdRO&tWYl2b$5|Kr<jF(2R7UY2z-|rY}=BhkEdP_kL8ETA^5sKcA;4Zz^gc
zi$+^=*Q>GY+_SR!olG?}%#+Ms^T?8SGv(PK$!t@q+7gB>OJf4HCOPfeWcJiNbs!J(
z_J1i$wx-CF*QT?gV$~+nl`rq!7|TZ8uL{!ap2wJ~!0;roDWtj^SikEAS+dQ?o-9IH
z43mqzfr68qHY}OBvlTVKyfKBc<ULeF+|vJEu3YeXJd50=d>M9c<1*RwPh>TgJ{^N{
zlaD<-2X!%Q)66Y5W72g<R&OtoJBOR>yW#Su@%ZuHKt<KVrv5FNY~N;8YUj<!IUk~=
zlqFxkK8a0yTbArdQ9B|%>1?Elq8R!s`bG{w?dVKHS-k_*iqF)R7#B{)h-B7rs`7q>
zLf+@EsiF1leVUNTCS{<kgm?c<mZ0P}>19D-f;@r@L8hQ^K@ox?1w{#p7Gw#kC8)Nb
z7(uau;snJDsv{^tP@<qDL0nL>pt^!m1f>e{3Q7}{E+|7#rl5L)vINx^lr1PnP_Cdn
zLHU9j2x=&(k)Q%Wg@PIjx<XJBK}`h}32G*&SWt68Ed;d`)JjlmL2U$;2=WPPE2y2I
z_JXby)Im^3L7fD37Su&hS3%tbbr;k_P)|X<1eFRZ6VzK!A3;|M>MN+9p#Fje2)bI(
zKtY294Hk5bpdo^;6*N@PFhSP|8ZPL1K_di>6m)~2QG!Mbx>3*=L1P7t6Et2>xu6O`
z69nBPXriD=f+h>PS<o$lZWS~|&~1XI3YsQpx}e(y`2|%9njz>8K{Ex-5;R+o5Hv^7
zor2~HnkVQkLGuMI5VTOx-GUYgS}f=uK~m7Yg6<QvM354+RM0X(_X}DsXoa8$1U)Ed
zrJz-U9ul-#&>BGx3wlJ*qk<k2^thlW1U)I}DM3#QdPdN*g4POpPSEp$)(KiK=mkM9
z3VKP<20<?idPUHyf?gA}QP3tquM65NXp5jX1idNfEkSP!dPmT^g0>3UCg?pu+XcNZ
zXosK=1nm^GOHh@d-GV+8^pT)Fg7ymfSkNbeJ{9ztpnZZq7xaaoF9q!v^p&6kg1#1X
zP|zVkhXs8j=vzVG2|6O^dqF=4`ccqNf_@hCi=d-|NYF7s#|8Z==r=(p1f3LgO3-OR
zzYF?9&>2Bz1)URgUQqQs(if5r3|!!b5D0}Z@PGj(ghK>GLKH-U1+}0y#6T>>K|Iuf
z1W1G=;E)V;Aq7&w3u%xJ8ITF}APee4HsnAq<Uu|(fQHZr3ZM`g!xhj3nnDpYgJNh7
zEubZ|g4WOmO27wgp&hh`E1?5)gig>Ix<FUx2Hl|t^n_ke3T4n6`oLAt7y3be7ywtp
zKo|sr;TjkM*TPU32G_xGxE@BpNVow;!DzS<#=uw@2jig}DqsTK1QTHrOop4`7Pu9r
zz-=%UronW$9sE!UGvE%G3A11}2$%zR!d#dKcfovE01M%6SOkmV9*}S^+y_fQ!BSWT
z_rr2n0S~}~uo70mL$Dgwz{BteJPMD&<M0GL2~WY(@C-Z)YvDO~9@fEncmZC7mtX_D
z46nee@EUA{P4GHwhAr?0ya{i?+wcy&3tM3uya(Iieb@mXz)si&Rj?aAgpXhk?1hiv
z6ZjN9gMIKhd;wp=e)tLwz}IjP4#8pg2EK*w;0SyVKfsUh6Z{Onz)>JL2FKx7_zh0L
zNjL?k;dl50&cInX2j`($pGOQIe_-GOH-tbagn<VPFd-ZwAQGY=8Z4*<wIK##Ar9i9
z4kSP#BmswHs0%5O3SLNqbjW~As0Ue4AF?3_av=}$p#e06Mo<8S&={_OCeRd$pcxcH
zb7%oAp%t`-Hc$dSXbbJ2JzNPLpd)mG&d>$ALO19RJ)kG_f>J1h-p~iGg1*oX`ojRY
z8V1537!23I5V#hG!Z5fFhQswR0!G3OFbYP)jW7nr!Z;WY<xl|=;3k*|lVCF347b3o
zFa>UdsW1(u!|mXQN|*t6z)YA0vq8WdxD)2WJh%(y!va_ccf%rB4EKP9d*MD<0t%MG
zGPoa>!wPr+9)y*!3Lb*hum&E6N8nL-3?7Fk;7NE2o`z@OSy&6t!Sk>V*24?%BD@3}
z;AMCPUWM0SBW!}#VKZ!jH{eZp3*Lrz;9b}X+u%Le4)4Pb_yBgoE~tXt@F9Ezdtfho
z44=TK@EPob&*2OB686JaZ~(rBgK!8A!#D6Pd<RG1d-wr<grDGN_yvvv!7(@vzrt^D
V0#3pyI1RtUA8-cF!Z|q4{ts|rv<UzJ

delta 4069
zcmZ|PWl&UaABXW}SzS;N0|6BU3tO>U*KPy@QBkp5*T7b=I}z5z?nKm8>@MuU76ZFG
zQ2yWRdH>vJuFw2t?sLz1ac1tw<TTGnwKJo?d(JeiY$jg=%k;meO1zK%TettSV|nG4
z(;Q)lE1=gmv@#ejsIz8+Au7~hn9w3VUtoBs%Q>%c0fSo@4EDZDPT6MMHd~^eZoOe!
z|I1w5cH@`XV)OVdLSPBphdh5o7_5e8;Fl_T!De_1CI1R5?1HaQ;hz`*36Kgk(nKU2
z7ttmsOLToTO`UhL*jyY$0L+7H;BFMbun6vgx1;DN;=S5mH`=B@H<yTtI8`lvMM6q;
zn~$fXk1h0;(c2d4=~%!P%M{C$%#_TuJ=oF3Rx-($*_IgW=x?)Xin50HioYLT)xmZs
z#L+eCeM+nNks})vo0ybhPfBt49vBm73^1le%n#aaHw76Fn(cY5MvLcOtFhnFm@p?_
z2RGZ5_eQ@c-|0E*iT;jXJ>r5aPC8?9b=EI&P|k*n#&`BCR^u0+sV1wVGO2Vbz1?Ir
zX9}}twHiNb@1t2cDQA^IWmGQ8Rb^6cDznO>vZ`##U1e7u%2Ro%94e>ErMy*cl}GUn
zUzJzoQ~6Z^RZ#h<LaMMTqKc|ws<<klN~%)IUzJv6R9RI{l~)y1MO8^vR#jA0RZUe_
zHB?PyQMFWURY%oT^;CV;Ks8j2RAbddHC4@2fNHJ+Rgh|-TB=s6wF*{kRETP;+Nt&`
zRCQ1tRVNjuI;$?KtLmn@s~)PS>ZN+CKB}+kr~0b_YM`>JL29rXqK2w)HB1dxBh*MW
zN{v=y)L1o6MW{$MUQJLF)g(1pO;J<TG&Nn#P&3smHCxS5bJaXGUoB8kYN3i&G0LVE
zsl{rETB??*<tkRKP%G6cwOXxFYt=fnUTsht)h4xBZBbj*Hnm;tP&-we+NI*vZna14
zRd%&c?N<rvfI6rSsl)1sI;xJT<LZPusZOcW>Wn(8&Z+b2f=W~u)g^UVT~SxnHFaIx
zP&d^rm85Q~JL;~wr|zo<>Y;k1lGS7NL_Jl{REm18UZ|Jqm3pn-sJH5!dapjHkLr{9
ztiGtP>YMtmeyE@7m-?;#s8sb={ZnZ(O&=ZRDlmd0m>?ab2QxT<Gh~2_-~z6Y3EUtv
zWPz-Z4cs9+cz`E(K@P|XxxgE8Lmuz}U&ssjAU_m<g5U>*pfD7HqEHNqLkTDerNAFb
zLm4Ow<)A!NfQnEFDnk{h3e})G)PR~`fm%=->Oftn2lb%=G=xUb7@9y+Xa)h$90DN-
zT0l!^1+5_%+CT`jg?7*$LZJh6gia6!ouLbKg>KLtdO%O;1-+pU^o4%V9|picu)-i1
z3`1Zjgu^fx4kKVBjDpcH2FAiTh=52K4-;S_OoGWU1*XC@m<}^wCd`7_FbC$sJeUs)
zAPN>jG{k@n7Qtdz0!v{TEQeTF0V`n@tcEqP7S_Rf*Z>=06KsYpuobq!cGv+sAr5vy
zJnV)&uovvG5B5U>9Dsvx2oA#$I10z$IGli!a0*Vt88{2);5=M_M7Ri-;4)l+t8fjj
z!wt9zw;%~_!yUK__uxJ}fQRr1lHoBtfv4~cQs6nffS2$JUc(!B3-91Pe1MPe2|mLY
z_zK_PJN$s3@C$y!A4rA2@DI`)bp07MIDiox!360bJ($4>oFM~b1Q&3HOyCBYAq!-M
zY~T*r!2>+O3vxhC$OYbz8}fh;_(ERD2l=4@6a+sg1cjjp6oq0?97;e*C<Xpd8p=Rf
zC<o=C0#t-bP#LN~Rj3Blp$60h3)F(zPzUNlJ*W>2pdmDZ#?S<sLNf?}<`4)$&;nXQ
zD`*YD&;~-FEwqF75DFcjBXoi==nP$;D|CbI&;xoxFX#<@pfB`;{xARrf)xhAU>E{J
zAsmLma2Nq2VHAvpF)$X!K?Fp?c$feaVG>M+DKHhL!E~4bGhr6YhB+`7=D~be08y|I
zq9F!sum~2z5?Bh$U^&FX3RnrNU^T3PwXhD>!v@$0n_x3+fvvC&w!;qC330Fs;$b)J
zfxTddeXt)A-~b$iLvR?5z)?5`$KeE=gi~-D&cInX2j}4eB*I0w1ef6oT!m|J9d5u)
zxCKdY8}7hexCi&)0X&39kPMIE2|R^okOI%)1-yh;@EYF0TX+ZW;RAexPw*MOz*qPN
Y-{A-RgkSI*{y-}HH6GFRXG~4|4^Jn!RR910

--
2.25.0.windows.1


Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.


AArch64 assembly compatibility for Xcode and GCC

Andrew Fish
 

I was playing around with getting Xcode to compile AArch64 code and I hit an interesting compatibility issue. The assembler line continuation token for GCC (;) is a comment for the Xcode clang assembler. For Xcode clang you need to use %%. Yikes [1]

I was wondering if any one else has hit this in another project and if there was any cool workaround?

The only thing I can think of is the “big hammer” on both (well you only need one) ends. We could replace ; with a #define that matches the assembler. It looks like this issue mostly hits in Code that is using C pre-processor macros so we could refactor the code. I’m a little concerned that the C pre processor is getting used since the macro languages of the assembler might also have some compatibility issues?

Looking for ideas and opinions on the best way to fix this if we want to add Xcode as an ARM compiler in the future. 



#define GPR_LAYOUT \
REG_PAIR (x19, x20, 0); \
REG_PAIR (x21, x22, 16); \
REG_PAIR (x23, x24, 32); \
REG_PAIR (x25, x26, 48); \
REG_PAIR (x27, x28, 64); \
REG_PAIR (x29, x30, 80);/*FP, LR*/ \
REG_ONE (x16, 96) /*IP0*/
I had to change it to:

#define GPR_LAYOUT \
REG_PAIR (x19, x20, 0)%% \
REG_PAIR (x21, x22, 16)%% \
REG_PAIR (x23, x24, 32)%% \
REG_PAIR (x25, x26, 48)%% \
REG_PAIR (x27, x28, 64)%% \
REG_PAIR (x29, x30, 80)%%/*FP, LR*/ \
REG_ONE (x16, 96) /*IP0*/
Thanks,

Andrew Fish


Change from "BaseTools/LzmaCompress: Fix possible uninitialized variable" patch was reverted

Denis Nikitin <denik@...>
 

Hi Hao,

While updating edk2 in Chrome OS we noticed that the change in your
patch https://edk2.groups.io/g/devel/message/19270 was reverted in
commit:
5ec5a236d1 BaseTools Lzma: Update LZMA SDK version to 18.05.

If you think the fix is critical I think it should be merged in
https://www.7-zip.org/sdk.html.

Thanks,
Denis


[Patch MBR endless loop hang with invalid LBA0 1/1] MdeModulePkg/PartitionDxe: Add break to handle invalid LBA0 in MBR

Edwards, Craig <Craig.Edwards@...>
 

Read Disk does a modification of ExtMbrStartingLba with the code MultU64x32
(ExtMbrStartingLba, BlockSize) Error detection to see if ExtMbrStartingLBA
has a value of 0. This is invalid as LBA 0 = MBR. After modification, the
next time ExtMbrStartingLba is in this function if ExtMbrStartingLba is set
to 0 in the MBR it never passes the while/do evaluation It is multiplied by 0
by read disk , set to 0 by an invalid MBR and goes back to evaluation This
condition will also cause Ws19 and WS22 to hang, however Microsoft has
developed a hotfix patch that will be released in 2022
 
Cc: Liming Gao <gaoliming@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Hao A Wu <hao.a.wu@...>
Cc: Ray Ni <ray.ni@...>
Cc: Zhichao Gao <zhichao.gao@...>
 
Signed-off-by: Craig Edwards <craig.edwards@...>
 
Date:      Wed Jan 5 12:27:46 2022 -0600
 
On branch graceful_handle_mbr_hang_edit1
Changes to be committed:
        modified:   MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
---
MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 6 ++++++
1 file changed, 6 insertions(+)
 
diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
index 0f8dc5486521..ad18840e5efd 100644
--- a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
+++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
@@ -293,6 +293,12 @@ PartitionInstallMbrChildHandles (
           (Mbr->Partition[0].OSIndicator == EXTENDED_WINDOWS_PARTITION))
       {
         ExtMbrStartingLba = UNPACK_UINT32 (Mbr->Partition[0].StartingLBA);
+          //
+          // A value of 0 is invalid for StartingLBA
+          //
+          if (ExtMbrStartingLba == 0) {
+            break;
+          }
         continue;
       }
 
--
2.32.0.windows.1
 
 
 
 
 
Craig Edwards
Software Engineer
Dell | GDP | PSE | COMMS | BIOS
 
 
 

Internal Use - Confidential
 


[Patch MBR endless loop hang with invalid LBA0 0/1]

Edwards, Craig <Craig.Edwards@...>
 

 
Craig Edwards (1):
  PartitionDxe/Mbr : MdeModulePkg : added break to handle invalid LBA0
    in MBR
 
MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 6 ++++++
1 file changed, 6 insertions(+)
 
--
2.32.0.windows.1
 
 
Craig Edwards
Software Engineer
Dell | GDP | PSE | COMMS | BIOS
 
 
 

Internal Use - Confidential
 

11421 - 11440 of 96641