Re: [edk2-devel] Synchronous Exception at ArmGicDxe

[Andrew Fish via groups.io]

The fault address is 0x0004AC14. Is that in the address range of the 
GIC for this platform? What does that Physical address map to you on the 
STM32MP25?

Thanks,

Andrew Fish

> On Apr 21, 2024, at 10:07 PM, Ba Gia Bao Phan  
> wrote:
> 
> Hi Everyone,
> 
> I'm working on a project with edk2, and these guys are trying to port edk2 to 
> STM32MP25 platforms. I had no issue compiling and booting the image on my 
> device. Then I've come across an issue at very early stages of booting. I was 
> given a Synchronous Exception listed briefly below. 
> 
> Synchronous Exception at 0x00010A63501C
> PC 0x00010A63501C (0x00010A633000+0x201C) [ 0] ArmGicDxe.dll
> PC 0x00010A6350CC (0x00010A633000+0x20CC) [ 0] ArmGicDxe.dll
> PC 0x00010A63657C (0x00010A633000+0x357C) [ 0] ArmGicDxe.dll
> PC 0x00010A85853C (0x00010A851000+0x753C) [ 1] DxeCore.dll
> PC 0x00010A8666DC (0x00010A851000+0x000156DC) [ 1] DxeCore.dll
> PC 0x00010A85BF14 (0x00010A851000+0xAF14) [ 1] DxeCore.dll
> PC 0x84006EBC
> PC 0x8400700C
> 
> [ 0] 
> /local/home/phanbagi/Documents/RPi3/Build/STM32MP25/DEBUG_GCC5/AARCH64/ArmPkg/Drivers/ArmGic/ArmGicDxe/DEBUG/ArmGicDxe.dll
> [ 1] 
> /local/home/phanbagi/Documents/RPi3/Build/STM32MP25/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
> 
>   X0 0x0004AC14   X1 0x   X2 0x   X3 
> 0x4F46A76E3FDDA605
>   X4 0x083D1B53F41229AD   X5 0x003CF238   X6 0x0080   X7 
> 0x
>   X8 0x00010A850688   X9 0x0004  X10 0x000109E9F000  X11 
> 0x00010A297FFF
>  X12 0x  X13 0x000E  X14 0x00FF  X15 
> 0x0002
>  X16 0x00010AFFFAD0  X17 0x00395790  X18 0x  X19 
> 0x0004AC14
>  X20 0x00010A638000  X21 0x00010A638000  X22 0x00010A638000  X23 
> 0x00010A6380A8
>  X24 0x00010A876448  X25 0x00010A873026  X26 0x00010A877000  X27 
> 0x800E
>  X28 0x0001   FP 0x00010AFFFA50   LR 0x00010A6350CC  
> 
>   V0 0xAFAFAFAFAFAFAFAF AFAFAFAFAFAFAFAF   V1 0xFF80FFD0 
> 00010AFFFA30
>   V2 0x0007 0E001858   V3 0x1000 
> 0100
>   V4 0x    V5 0x 
> 
>   V6 0x    V7 0x 
> 
>   V8 0x    V9 0x 
> 
>  V10 0x   V11 0x 
> 
>  V12 0x   V13 0x 
> 
>  V14 0x   V15 0x 
> 
>  V16 0x6145998C70863CB0 9004002B4AC68640  V17 0x646586E820A5D596 
> AA30249EC11F1469
>  V18 0x5756252D20E5B421 336EEAEC2122B3AB  V19 0x6285C083AAECD063 
> 020A72C37700322A
>  V20 0x40846C68BA2085FB 20966526601C44BB  V21 0x818208204CD0A89D 
> 6D84E94813E14B24
>  V22 0x2362CBA9962AF073 E83ED49CD4A13F98  V23 0x0C1123CD73F5C5B0 
> C3E9222891467015
>  V24 0x02B1194895858177 1B028BE1A860D73B  V25 0x542AB00936183D90 
> 752F1D1CCC4D2345
>  V26 0x03D02013962356F3 0CCA6F83842045EA  V27 0x9DF9D2A28D44915E 
> 2892460B223FD84C
>  V28 0x61A2CC120A809CD8 AC33034803D74C10  V29 0x7A1089709810B030 
> 88B3298EEB68B450
>  V30 0xD20F81310E0896C0 20E2BA370E2AC6F9  V31 0x6C3BBEA030B2BB50 
> 2C2A91AAF201EF50
> 
>   SP 0x00010AFFFA50  ELR 0x00010A63501C  SPSR 0x43C5  FPSR 
> 0x
>  ESR 0x9605  FAR 0x0004AC14
> 
>  ESR : EC 0x25  IL 0x1  ISS 0x0005
> 
> Data abort: Translation fault, first level
> 
> 
> By using objdump to determine where the wrong source code is, I found out 
> that the program stopped around the code below.
> 
> UINT32
> EFIAPI
> MmioRead32 (
>   IN  UINTN  Address
>   )
> {
>   UINT32   Value;
>   BOOLEAN  Flag;
> 
>   ASSERT ((Address & 3) == 0);
> 
>   Flag = FilterBeforeMmIoRead (FilterWidth32, Address, );
>   if (Flag) {
> MemoryFence ();
> 
> if (IsTdxGuest ()) {
>   Value = TdMmioRead32 (Address);
> } else {
>   Value = *(volatile UINT32 *)Address;
> }
> 
> MemoryFence ();
>   }
> 
>   FilterAfterMmIoRead (FilterWidth32, Address, );
> 
>   return Value;
> }
> 
> Output of objdump:
> UINT32
> EFIAPI
> MmioRead32 (
>   IN  UINTN  Address
>   )
> {
> 1fec: a9be7bfd stp x29, x30, [sp, #-32]!
> 1ff0: 910003fd mov x29, sp
> 1ff4: f9000bf3 str x19, [sp, #16]
> 1ff8: aa0003f3 mov x19, x0
>   UINT32   Value;
>   BOOLEAN  Flag;
> 
>   ASSERT ((Address & 3) == 0);
> 1ffc: f240041f tst x0, #0x3
> 2000: 54e0 b.eq 201c   // b.none
> 2004: b002 adrp x2, 3000 
> 2008: b000 adrp x0, 3000 
> 200c: 913ac442 add x2, x2, #0xeb1
> 2010: 913b1000 add x0, x0, #0xec4
> 2014: d2804461 mov x1, #0x223 // #547
> 2018: 977a bl 1e00 
> 

Re: [edk2-devel] Is there a way to create filesystem in UEFI Shell ?

[Andrew Fish via groups.io]

FYI you can have much larger files in the newer version of the filesystem. See 
EFI_COMMON_SECTION_HEADER2

https://uefi.org/specs/PI/1.8A/V3_Code_Definitions.html#firmware-file-system
https://uefi.org/specs/PI/1.8A/V3_Code_Definitions.html#firmware-file-section

Thanks,

Andrew Fish

> On Apr 3, 2024, at 8:11 PM, John Chew  wrote:
> 
> On Wed, Apr 3, 2024 at 03:48 PM, Yoshinoya wrote:
> Maybe ref to ramdisk sample, create a memory type block io device, then mount 
> file system on it.
> UEFI supports fat file system, some 3rd drivers could be added to support 
> ext4 filesystem.
> Search them on github website
> Thanks Yoshinoya for your input. =)
> 
>  
> I have tried to compile the filesystem into my FD image as a separate FV. 
> Then building FV HOB with it using "BuildFvHob".
> 
> Next, using the "GetSectionFromAnyFv" to load the filesystem into buffer as 
> follow:
> 
> 
> 
> Finally, create a disk with the filesystem buffer created earlier. 
> 
> 
> 
> This works without having to create filesystem in EDK2. Instead loading it 
> from somewhere else.
> 
> However, this method has some limitations because the maximum size of each 
> SECTION in FFS is only 16MB.
> 
> 
> 
> Thus, I still couldn't TFTP Linux (~25MB) into my filesystem "FS0:"
> 
>  
> My solution:
> 
>  
> 
> 1. Allocate buffer
> 
> 2. Populate the buffer by with100MB FAT16 header
> 
> 3. Register virtual disk with the buffer
> 
>  
> I'm able to allocate 100MB of FAT16 filesystem and TFTP Linux successfully:
> 
> 
> 
> 
>  
> Thanks everyone!!
> 
> John
> 
>  
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117933): https://edk2.groups.io/g/devel/message/117933
Mute This Topic: https://groups.io/mt/105212723/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] bootloader build error

[Andrew Fish via groups.io]

Bill,

The Python tools can tend to throw vs.flagging errors in the config files. Did 
you happen to edit anything in *.inf,*.dsc, or *.fdf files? This could just be 
a syntax error in those changes. 

This error looks like trying to make the FV (Firmware Volume) and Ffs would be 
one of the files in the FV, and the file is built out of sections. 

> OSError: [Errno 2] No such file or directory: 
> '/.../vendor/BOOT.MXF.2.0/boot_images/Build/ClarenceLAA/Core/RELEASE_CLANG120LINUX/FV/Ffs/1C04F529-0612-4319-9315-B2E75C16810AFeatureEnablerDxe/1C04F529-0612-4319-9315-B2E75C16810ASEC2.1.pe32'



Thanks,

Andrew Fish

PS FYI  Python 2.7 is no longer supported as of January 1st, 2020.

> On Apr 4, 2024, at 5:13 AM, Bill Shih 施炫全 via groups.io 
>  wrote:
> 
> Hi Sir
>  
> I have problem when building android bootloader.
>  
> The log suggested I could mail you for help.
>  
> Can I have your suggestion to solve this error?
>  
> Thank you
>  
> The log:
>  
> build.py...
> : error C0DE: Unknown fatal error when processing 
> [/.../vendor/BOOT.MXF.2.0/boot_images/boot/***/Library/EblCmdLib/EblCmdLib.inf
>  [AARCH64, CLANG120LINUX, RELEASE]]
>
> (Please send email to devel@edk2.groups.io  for 
> help, attaching following call stack trace!)
>  
> (Python 2.7.18 on linux2) Traceback (most recent call last):
>   File 
> "/.../vendor/BOOT.MXF.2.0/boot_images/edk2/BaseTools/Source/Python/build/build.py",
>  line 2599, in Main
> MyBuild.Launch()
>   File 
> "/.../vendor/BOOT.MXF.2.0/boot_images/edk2/BaseTools/Source/Python/build/build.py",
>  line 2394, in Launch
> self._MultiThreadBuildPlatform()
>   File 
> "/.../vendor/BOOT.MXF.2.0/boot_images/edk2/BaseTools/Source/Python/build/build.py",
>  line 2234, in _MultiThreadBuildPlatform
> Wa, self.BuildModules = self.PerformAutoGen(BuildTarget,ToolChain)
>   File 
> "/.../vendor/BOOT.MXF.2.0/boot_images/edk2/BaseTools/Source/Python/build/build.py",
>  line 2109, in PerformAutoGen
> CmdListDict = self._GenFfsCmd(Wa.ArchList)
>   File 
> "/.../vendor/BOOT.MXF.2.0/boot_images/edk2/BaseTools/Source/Python/build/build.py",
>  line 2006, in _GenFfsCmd
> GenFfsDict = GenFds.GenFfsMakefile('', GlobalData.gFdfParser, self, 
> ArchList, GlobalData)
>   File 
> "/.../vendor/BOOT.MXF.2.0/boot_images/edk2/BaseTools/Source/Python/GenFds/GenFds.py",
>  line 544, in GenFfsMakefile
> FvObj.AddToBuffer(Buffer=None, Flag=True)
>   File 
> "/.../vendor/BOOT.MXF.2.0/boot_images/edk2/BaseTools/Source/Python/GenFds/Fv.py",
>  line 127, in AddToBuffer
> FileName = FfsFile.GenFfs(MacroDict, FvParentAddr=BaseAddress, 
> IsMakefile=Flag, FvName=self.UiFvName)
>   File 
> "/.../vendor/BOOT.MXF.2.0/boot_images/edk2/BaseTools/Source/Python/GenFds/FfsInfStatement.py",
>  line 518, in GenFfs
> InputSectList, InputSectAlignments = self.__GenComplexFileSection__(Rule, 
> FvChildAddr, FvParentAddr, IsMakefile=IsMakefile)
>   File 
> "/.../vendor/BOOT.MXF.2.0/boot_images/edk2/BaseTools/Source/Python/GenFds/FfsInfStatement.py",
>  line 969, in __GenComplexFileSection__
> SectList, Align = Sect.GenSection(self.OutputPath, self.ModuleGuid, 
> SecIndex, self.KeyStringList, self, IsMakefile = IsMakefile)
>   File 
> "/.../vendor/BOOT.MXF.2.0/boot_images/edk2/BaseTools/Source/Python/GenFds/EfiSection.py",
>  line 321, in GenSection
> IsMakefile=IsMakefile
>   File 
> "/.../vendor/BOOT.MXF.2.0/boot_images/edk2/BaseTools/Source/Python/GenFds/GenFdsGlobalVariable.py",
>  line 502, in GenerateSection
> if (os.path.getsize(Output) >= GenFdsGlobalVariable.LARGE_FILE_SIZE and
>   File 
> "/.../vendor/BOOT.MXF.2.0/boot_images/edk2/BaseTools/Source/Python/Common/LongFilePathOsPath.py",
>  line 21, in getsize
> return os.path.getsize(LongFilePath(filename))
>   File "/usr/lib/python2.7/genericpath.py", line 57, in getsize
> return os.stat(filename).st_size
> OSError: [Errno 2] No such file or directory: 
> '/.../vendor/BOOT.MXF.2.0/boot_images/Build/ClarenceLAA/Core/RELEASE_CLANG120LINUX/FV/Ffs/1C04F529-0612-4319-9315-B2E75C16810AFeatureEnablerDxe/1C04F529-0612-4319-9315-B2E75C16810ASEC2.1.pe32'
>  
>  
> - Failed -
> Build end time: 17:11:19, Apr.03 2024
> Build total time: 00:00:04
>  
> , u'-b', u'RELEASE', u'-t', u'CLANG120LINUX', '-D', 'TARGETPKG=SocPkg', '-D', 
> u'DTC=/pkg/qct/software/boottools/', '-D', 
> 'EDK2ROOT=/.../vendor/BOOT.MXF.2.0/boot_images/edk2', '-D', 
> u'CLANG120=/opt/LLVM/12.0.3/bin', '-D', 
> 'BOOTTOOLS=/.../vendor/BOOT.MXF.2.0/boot_images/boot_tools', '-D', 
> u'COMPILER=CLANG120LINUX', '-D', 
> u'SECTOOLSROOT=/.../vendor/QCM4490.LA.1.0/common/sectoolsv2/ext/Linux', '-D', 
> '***DIR=', '-D', 'TARGETID=SocClarence', '-D', u'VAR=LAA', '-D', 
> 'TARGETROOT=***/SocPkg/Clarence', '-D', 
> u'BOOTROOT=/.../vendor/BOOT.MXF.2.0/boot_images/boot', '-D', 
> 'BUILDROOT=/.../vendor/BOOT.MXF.2.0/boot_images', '-D', 'PRODMODE=PRODMODE', 
> '-D', 'XBLSEC=', '-D', u'AARCH=AARCH64', '-D', 'SECONDDLL=', '-D', 
> 'COMPLIER=', 

Re: [edk2-devel] Is there a way to create filesystem in UEFI Shell ?

[Andrew Fish via groups.io]

> On Mar 31, 2024, at 8:39 PM, John Chew  wrote:
> 
> On Sat, Mar 30, 2024 at 06:10 AM, Andrew Fish wrote:
> You can make a ReadOnly file system out of contents on an FV (Firmware 
> Volume): 
> https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Universal/FvSimpleFileSystemDxe
> FV is defined in the PI Spec as a layout for flash that contains files, but 
> no directories. 
> Hi Andrew,
> 
>  
> I forgot to mention earlier, that I'm developing for RISC-V architecture.
> 
> It seems like the semihosting lib in edk2 does not have support for RISC-V 
> yet.
> 
>  
> Thanks for the FvSimpleFileSystemDxe suggestion.
> 
> Actually, I'm trying to TFTP "initramfs" (1MB) and "linux.efi" (25MB) into a 
> filesystem. So, it requires to support write to the filesystem. 
> 
>  
> Do you have other suggestions?
> 
The source code Mike linked. I forgot the place it lived. 

I think we are really enough in the RISC-V that some older things have not been 
ported. It should not be that hard to port to edk2. That would probably get 
RISC-V working.

Thanks,

Andrew Fish

>  
> Thanks! =)
> 
> John
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117296): https://edk2.groups.io/g/devel/message/117296
Mute This Topic: https://groups.io/mt/105212723/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Is there a way to create filesystem in UEFI Shell ?

[Andrew Fish via groups.io]

MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf is a virtual storage 
device, so it just emulates an unformatted disk. You would need to partition or 
initialize the file system given you have a RAM disk. 

The file system driver lives here: 
https://github.com/tianocore/edk2/tree/master/FatPkg/EnhancedFatDxe

The ArmPkg has a driver that lets you do a file system over JTAG: 
https://github.com/tianocore/edk2/blob/master/ArmPkg/Filesystem/SemihostFs/Arm/

You can make a ReadOnly file system out of contents on an FV (Firmware Volume): 
https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Universal/FvSimpleFileSystemDxe
FV is defined in the PI Spec as a layout for flash that contains files, but no 
directories. 

Thanks,

Andrew Fish

> On Mar 29, 2024, at 1:21 AM, John Chew  wrote:
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117245): https://edk2.groups.io/g/devel/message/117245
Mute This Topic: https://groups.io/mt/105212723/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] test message - my messages aren't showing up?

[Andrew Fish via groups.io]

David,

You have to be subscribed to the list for the mails to got directly to the 
list. I think you just subscribed so I had to clear you as OK to post.

Basically your posts were going to moderation and a human had to approve them. 

Thanks,

Andrew Fish

> On Mar 28, 2024, at 9:48 AM, David F.  wrote:
> 
> I noticed the daily summary doesn't have my questions .. this is a
> test, can someone reply direct to confirm.
> 
> Thanks.
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117217): https://edk2.groups.io/g/devel/message/117217
Mute This Topic: https://groups.io/mt/105203224/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Memory Attribute for depex section

[Andrew Fish via groups.io]

> On Jan 12, 2024, at 11:04 AM, Kinney, Michael D  
> wrote:
> 
> Agreed.  Basically every API that takes an EF_HANDLE as input calls that API 
> to make sure it is a valid handle.
>  
> The first question is if we get value from making sure the EFI_HANDLE is a 
> member of the active set of handles.
>  
> A simple signature check in the EFI_HANDLE may be enough as long as all freed 
> handles clear the signature.
>  
> Then, the only way that the linked list walk adds value is if there it a call 
> with an invalid handle that happens to
> have the matching signature.
>  

MIke,

I seem to remember we ended up fixing the way you describe locally. Even if you 
convert the list into a tree given the index was a pointer to allocate memory 
it could get reused. The tree just made the lookup go faster. 

If we wanted to get tricky on 64-bit systems we could encode a monotonically 
increasing number in the non-canonical part of the virtual address, or above 
the max physical address if paging is not enabled. To use the EFI_HNDLE as a 
pointer you just remove count and replace it with sign extend canonical address 
(zero in our case). We could probably define a HOB to define the bits to use 
given the code constructing the page tables for DXE needs to know all the rules 
here. 

Thanks,

Andrew Fish

> The 
>  
> From: Andrew (EFI) Fish  
> Sent: Friday, January 12, 2024 10:57 AM
> To: edk2-devel-groups-io ; Kinney, Michael D 
> 
> Cc: pedro.falc...@gmail.com; Laszlo Ersek ; 
> n...@os.amperecomputing.com; ardb+tianoc...@kernel.org
> Subject: Re: [edk2-devel] Memory Attribute for depex section
>  
>  
> 
> 
> On Jan 12, 2024, at 8:37 AM, Michael D Kinney  > wrote:
>  
> Hi Pedro,
> 
> Thank you for evaluating this idea change from linked list to improve
> performance of the handle database.
> 
> The concept of using integers for an EFI_HANDLE has been considered before.
> One advantage over pointers is that a guarantee can be made that an EFI_HANDLE
> value can be guaranteed to be unique.  In the current implementation with
> EFI_HANDLE being a pointer to an allocated buffer, an EFI_HANDLE value could
> potentially be reused if an EFI_HANDLE is freed and later allocated for a 
> different EFI_HANDLE.
> 
> If you continue to explore this path I agree that EFI_HANDLE value of 0 should
> be reserved and never used.  I also recommend that new EFI_HANDLE values are
> always assigned a new unique value that freed EFI_HANDLE values are never 
> reused.
> 
> The overall linked list performance of the handle database has also been noted
> before, but has rarely raised to the level where it impacts the overall boot
> performance relative to other optimization opportunities.  I look forward to
> the performance data.  The PERF_X() macros are the right service to use.  On
> x86 it is based on the time stamp counter (TSC) which has very small 
> granularity.
> 
>  
> Mike,
>  
> We tracked this a while back with the PERF macros when we had some 
> performance issues running diagnostics on a system with 3,000+ handles. The 
> hot path was CoreValidateHandle(). I think the number of calls to 
> CoreValidateHandle() explodes if you have more handles so it is not just the 
> raw performance of CoreValidateHandle(), but also how many times it gets 
> called. 
>  
> Thanks,
>  
> Andrew Fish
> 
> 
> Mike
> 
> 
> 
> -Original Message-
> From: devel@edk2.groups.io  
> mailto:devel@edk2.groups.io>> On Behalf Of Pedro 
> Falcato
> Sent: Friday, January 12, 2024 6:47 AM
> To: Laszlo Ersek mailto:ler...@redhat.com>>
> Cc: devel@edk2.groups.io ; 
> n...@os.amperecomputing.com ;
> ardb+tianoc...@kernel.org ; Andrew Fish 
> mailto:af...@apple.com>>
> Subject: Re: [edk2-devel] Memory Attribute for depex section
> 
> On Fri, Jan 12, 2024 at 9:35 AM Laszlo Ersek  > wrote:
> 
> 
> On 1/12/24 03:10, Pedro Falcato wrote:
> 
> My idea was to make each handle an index - like a file descriptor -
> AFAIK there's no reason why it *needs* to be an actual pointer.
> We'd allocate indices when creating a handle, and return that (casted to
> VOID*).
> 
> 
> Huh, sneaky.
> 
> I see two potential problems with this.
> 
> First, per C std, these "pointers" would be invalid (they wouldn't
> actually point to valid memory), so even just evaluating them (not
> dereferencing them!) would invoke undefined behavior. May or may not
> matter in practice. With compilers getting smarter about optimization
> (and stricter about std conformance), there could be issues, perhaps.
> 
> This is true. Stashing random integers in pointers is
> implementation-defined. But it's also super common. Win32 HANDLEs are
> exactly this, just integers (stashed in VOID*). The Linux kernel world
> also has a bunch of fun tricks with stashing flags in a pointer's
> bottom bits, magic pointer 

Re: [edk2-devel] Memory Attribute for depex section

[Andrew Fish via groups.io]

> On Jan 12, 2024, at 8:37 AM, Michael D Kinney  
> wrote:
> 
> Hi Pedro,
> 
> Thank you for evaluating this idea change from linked list to improve
> performance of the handle database.
> 
> The concept of using integers for an EFI_HANDLE has been considered before.
> One advantage over pointers is that a guarantee can be made that an EFI_HANDLE
> value can be guaranteed to be unique.  In the current implementation with
> EFI_HANDLE being a pointer to an allocated buffer, an EFI_HANDLE value could
> potentially be reused if an EFI_HANDLE is freed and later allocated for a 
> different EFI_HANDLE.
> 
> If you continue to explore this path I agree that EFI_HANDLE value of 0 should
> be reserved and never used.  I also recommend that new EFI_HANDLE values are
> always assigned a new unique value that freed EFI_HANDLE values are never 
> reused.
> 
> The overall linked list performance of the handle database has also been noted
> before, but has rarely raised to the level where it impacts the overall boot
> performance relative to other optimization opportunities.  I look forward to
> the performance data.  The PERF_X() macros are the right service to use.  On
> x86 it is based on the time stamp counter (TSC) which has very small 
> granularity.
> 

Mike,

We tracked this a while back with the PERF macros when we had some performance 
issues running diagnostics on a system with 3,000+ handles. The hot path was 
CoreValidateHandle(). I think the number of calls to CoreValidateHandle() 
explodes if you have more handles so it is not just the raw performance of 
CoreValidateHandle(), but also how many times it gets called. 

Thanks,

Andrew Fish

> Mike
> 
> 
>> -Original Message-
>> From: devel@edk2.groups.io  
>> mailto:devel@edk2.groups.io>> On Behalf Of Pedro 
>> Falcato
>> Sent: Friday, January 12, 2024 6:47 AM
>> To: Laszlo Ersek mailto:ler...@redhat.com>>
>> Cc: devel@edk2.groups.io ; 
>> n...@os.amperecomputing.com ;
>> ardb+tianoc...@kernel.org ; Andrew Fish 
>> mailto:af...@apple.com>>
>> Subject: Re: [edk2-devel] Memory Attribute for depex section
>> 
>> On Fri, Jan 12, 2024 at 9:35 AM Laszlo Ersek  wrote:
>>> 
>>> On 1/12/24 03:10, Pedro Falcato wrote:
 My idea was to make each handle an index - like a file descriptor -
 AFAIK there's no reason why it *needs* to be an actual pointer.
 We'd allocate indices when creating a handle, and return that (casted to
>> VOID*).
>>> 
>>> Huh, sneaky.
>>> 
>>> I see two potential problems with this.
>>> 
>>> First, per C std, these "pointers" would be invalid (they wouldn't
>>> actually point to valid memory), so even just evaluating them (not
>>> dereferencing them!) would invoke undefined behavior. May or may not
>>> matter in practice. With compilers getting smarter about optimization
>>> (and stricter about std conformance), there could be issues, perhaps.
>> 
>> This is true. Stashing random integers in pointers is
>> implementation-defined. But it's also super common. Win32 HANDLEs are
>> exactly this, just integers (stashed in VOID*). The Linux kernel world
>> also has a bunch of fun tricks with stashing flags in a pointer's
>> bottom bits, magic pointer values, etc. I severely doubt we can run
>> into issues with this. EDK2 will not exactly run on the C standard's
>> abstract machine anyway ;)
>> 
>>> 
>>> The other concern is a bit contrived, but I *guess* there could be code
>>> out there that actually dereferences EFI_HANDLEs. That code would crash.
>>> May or may not matter, because such code is arguably already
>>> semantically invalid. (It would not necessarily be invalid at the
>>> language level -- cf. my previous paragraph --, because passing an
>>> otherwise valid EFI_HANDLE to CopyMem, for copying just 1 byte out of
>>> the underlying opaque data structure, would not violate the language.)
>> 
>> This is a feature, not a bug! :P
>> 
>> Seriously though, IHANDLE is not even exposed in semi-public headers,
>> so any code that's derefing an EFI_HANDLE will need to do something
>> like
>> 
>> typedef struct {
>>  /* ... */
>> } IHANDLE;
>> 
>> EFI_HANDLE Handle = /* ... */;
>> 
>> IHANDLE *HandleImpl = (IHANDLE *) Handle;
>> 
>> and I'm a strong believer in "play stupid games, win stupid prizes".
>> You can definitely make an argument for "this should definitely crash"
>> instead of just "maybe crashing" (for instance, platforms that still
>> map the NULL page (like OVMF!), or handles > 4096), so I'm inclined to
>> think that if we indeed go this route, we should set one or two upper
>> bits (on 64-bit platforms!) to make handles non-canonical addresses
>> and therefore necessarily crash on dereference.
>> 
>>> 
 I should note that I find it super hard to get a concrete idea on
 performance for EFI firmware without adequate tooling - I meant to
 write a standalone flamegraph tool a few 

Re: [edk2-devel] Memory Attribute for depex section

[Andrew Fish via groups.io]

> On Jan 12, 2024, at 6:46 AM, Pedro Falcato  wrote:
> 
> On Fri, Jan 12, 2024 at 9:35 AM Laszlo Ersek  wrote:
>> 
>> On 1/12/24 03:10, Pedro Falcato wrote:
>>> My idea was to make each handle an index - like a file descriptor -
>>> AFAIK there's no reason why it *needs* to be an actual pointer.
>>> We'd allocate indices when creating a handle, and return that (casted to 
>>> VOID*).
>> 
>> Huh, sneaky.
>> 
>> I see two potential problems with this.
>> 
>> First, per C std, these "pointers" would be invalid (they wouldn't
>> actually point to valid memory), so even just evaluating them (not
>> dereferencing them!) would invoke undefined behavior. May or may not
>> matter in practice. With compilers getting smarter about optimization
>> (and stricter about std conformance), there could be issues, perhaps.
> 
> This is true. Stashing random integers in pointers is
> implementation-defined. But it's also super common. Win32 HANDLEs are
> exactly this, just integers (stashed in VOID*). The Linux kernel world
> also has a bunch of fun tricks with stashing flags in a pointer's
> bottom bits, magic pointer values, etc. I severely doubt we can run
> into issues with this. EDK2 will not exactly run on the C standard's
> abstract machine anyway ;)
> 

I’d point out that CPUs we support do magic things with bits of pointers. 
ARMv8.3 defines pointer authentication and on a Mac arm64e is an ABI with 
pointer authentication enabled. 

Given call return rules are different and you have to initialize signed 
pointers it is a different ABI, but never say never that a signed pointer ABI 
could get added to UEFI.

Thanks,

Andrew Fish

>> 
>> The other concern is a bit contrived, but I *guess* there could be code
>> out there that actually dereferences EFI_HANDLEs. That code would crash.
>> May or may not matter, because such code is arguably already
>> semantically invalid. (It would not necessarily be invalid at the
>> language level -- cf. my previous paragraph --, because passing an
>> otherwise valid EFI_HANDLE to CopyMem, for copying just 1 byte out of
>> the underlying opaque data structure, would not violate the language.)
> 
> This is a feature, not a bug! :P
> 
> Seriously though, IHANDLE is not even exposed in semi-public headers,
> so any code that's derefing an EFI_HANDLE will need to do something
> like
> 
> typedef struct {
>  /* ... */
> } IHANDLE;
> 
> EFI_HANDLE Handle = /* ... */;
> 
> IHANDLE *HandleImpl = (IHANDLE *) Handle;
> 
> and I'm a strong believer in "play stupid games, win stupid prizes".
> You can definitely make an argument for "this should definitely crash"
> instead of just "maybe crashing" (for instance, platforms that still
> map the NULL page (like OVMF!), or handles > 4096), so I'm inclined to
> think that if we indeed go this route, we should set one or two upper
> bits (on 64-bit platforms!) to make handles non-canonical addresses
> and therefore necessarily crash on dereference.
> 
>> 
>>> I should note that I find it super hard to get a concrete idea on
>>> performance for EFI firmware without adequate tooling - I meant to
>>> write a standalone flamegraph tool a few weeks back (even posted in
>>> edk2-devel), but, as far as I could tell, the architectural timer
>>> protocol couldn't get me the interrupt frame[1]. Until then, whether
>>> any of this radix tree vs RB tree vs flat array stuff really
>>> matters... I find it hard to say.
>>> 
>>> [1] x86 has 3 timers (PIT, LAPIC timer, HPET) and performance
>>> monitoring interrupts, and I couldn't freely use any of them :^)
>> 
>> Edk2 has some form of profiling already (see
>> "MdePkg/Include/Library/PerformanceLib.h"). Usually one sees core code
>> peppered with PERF_CODE_BEGIN and PERF_CODE_END macros. I *think* there
>> is something like a "display performance" (dp) shell application too,
>> that can show the collected stats. But I've never used these facilities.
>> 
>> The wiki seems to have two related articles:
>> 
>> https://github.com/tianocore/tianocore.github.io/wiki/Edk2-Performance-Infrastructure
>> 
>> https://github.com/tianocore/tianocore.github.io/wiki/PerformancePkg
>> 
>> The former looks quite comprehensive, at a quick skim.
> 
> /me nods
> I've seen those macros around, but I've never used them.
> In any case, this problem has piqued my interest, I'll see if I can
> find some free time this weekend to hack on a test benchmark and a PoC
> :)
> 
> -- 
> Pedro



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113753): https://edk2.groups.io/g/devel/message/113753
Mute This Topic: https://groups.io/mt/103594587/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Memory Attribute for depex section

[Andrew Fish via groups.io]

Sorry need some more time to digest this…. First thoughts.

1) The actual performance issue we hit was the explosion of 
CoreValidateHandle() calls as the number of protocols got large for some diags. 
The newer handles tended to be at the end of the list if I remember correctly. 
  a) It looks like CoreValidateHandle() is the only place  gHandleList was 
walked, as the handle info is crossed referenced in the protocol database. So 
that is why we changed that.
2) If the issue at hand is MM why not just drop the optimizations?
  b) If we have so many MM protocols and handles that seems like its own 
problem? 
3) The issue is patching the grammar in place, why can’t we just make a copy 
for the dispatcher grammer, and operate on the copy. Maybe via a copy on 1st 
update strategy? 

Thanks,

Andrew Fish

> On Jan 10, 2024, at 5:45 AM, Laszlo Ersek  wrote:
> 
> (+ Andrew)
> 
> On 1/10/24 14:09, Laszlo Ersek wrote:
> 
>> I think that keeping the depex section read-only is valuable, so I'd
>> rule out #2. I'd also not start with option #1 -- copying the depex to
>> heap memory, just so this optimization can succeed. I'd simply start by
>> removing the optimization, and measuring how much driver dispatch slows
>> down in practice, on various platforms.
>> 
>> Can you try this? (I have only build-tested and "uncrustified" it.)
>> 
>> The patch removes the EFI_DEP_REPLACE_TRUE handling altogether, plus it
>> CONST-ifies the Iterator pointer (which points into the DEPEX section),
>> so that the compiler catch any possible accesses at *build time* that
>> would write to the write-protected DEPEX memory area.
> 
> On a tangent: the optimization in question highlights a more general
> problem, namely that the DXE (and possibly MM/SMM) protocol databases
> are considered slow, for some access patterns.
> 
> Edk2 implements those protocol databases with linked lists, where lookup
> costs O(n) operations (average and worst cases). And protocol lookups
> are quite frequent (for example, in depex evaluations, they could be
> considered "particularly frequent").
> 
> (1) The "Tasks" wiki page mentions something *similar* (but not the
> same); see
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Tasks#datahub--gcd-scalability
> 
> The description is: "The DXE core's DataHub and GCD (Global Coherency
> Domain) layers don't scale well as the number of data items gets large,
> since they are based on simple linked lists. Find better data structures."
> 
> The same might apply more or less to the protocol database implementation.
> 
> (2) More to the point, Andrew Fish reported earlier that at Apple, they
> had rewritten the DXE protocol database, using the red-black tree
> OrderedCollectionLib that I had contributed previously to edk2 -- and
> they saw significant performance improvements.
> 
> So upstreaming that feature to edk2 could be very valuable. (Red-black
> trees have O(log(n)) time cost (worst case) for lookup, insertion and
> deletion, and O(n) cost for iterating through the whole data structure.)
> 
> Let me see if I can find the bugzilla ticket...
> 
> Ah, I got it. Apologies, I misremembered: Andrew's comment was not about
> the protocol database, but about the handle database. Here it is:
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=988#c7
> 
> (the BZ is still CONFIRMED btw...)
> 
> Still, I think it must be related in a way. Namely, an EFI handle exists
> if and only if at least one protocol interface is installed on it. If
> you uninstall the last protocol interface from a handle, then the handle
> is destroyed -- in fact that's the *only* way to destroy a handle, to my
> understanding. See EFI_BOOT_SERVICES.UninstallProtocolInterface() in the
> UEFI spec: "If the last protocol interface is removed from a handle, the
> handle is freed and is no longer valid". Furthermore, calling
> InstallProtocolInterface() and InstallMultipleProtocolInterfaces() is
> how one *creates* new handles.
> 
> So given how handles and protocol interfaces are conceptually
> interlinked, an rbtree-based protocol DB might have to maintain multiple
> rbtrees internally (for the ability to search the database quickly with
> different types of "keys"). I don't have a design ready in my mind at
> all (I'm not that familiar with the *current*, list-based implementation
> to begin with!). Upstreaming Apple's (experimental?) code could prove
> very helpful.
> 
> Laszlo
> 
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113644): https://edk2.groups.io/g/devel/message/113644
Mute This Topic: https://groups.io/mt/103594587/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] UDK2022 stable202211 - GCC compiler for Windows for building X64 EFI

[Andrew Fish via groups.io]

There is info about toolchains checked in here:edk2/BaseTools/Conf/tools_def.template at master · tianocore/edk2github.comOn Sep 27, 2023, at 8:10 PM, Daniel Samuelraj  wrote:We tried GCC at https://sourceforge.net/projects/gcc-win64/And then we tried GCC ver5.4We are getting the following error:x86_64-5.4.0-release-posix-sjlj-rt_v5-rev0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.4.0/../../../../x86_64-w64-mingw32/bin/ld.exe: unrecognised emulation mode: elf_x86_64 Can you please let me know the recommended/suggested GCC version to compile UDK2022 stable202211? Also if there is any link with instructions to compile UDK2022 with GCC would be helpful?  Thanks,DanielFrom: Daniel Samuelraj  Sent: Wednesday, September 27, 2023 12:54 PMTo: 'devel@edk2.groups.io' Cc: Jianning Wang ; 'Kinney, Michael D' Subject: UDK2022 GCC compiler Hi,Can you recommend a GCC compiler to build UDK2022?  Thanks


This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.


_._,_._,_



Groups.io Links:


  
You receive all messages sent to this group.
  
  



View/Reply Online (#109135) |


  

|

  Mute This Topic


| New Topic






Your Subscription |
Contact Group Owner |

Unsubscribe

 [arch...@mail-archive.com]
_._,_._,_

Re: [edk2-devel] Maybe it is time to update code style?

[Andrew Fish via groups.io]

It took me 2-3 weeks to flip my brain over to the 2 space indent. It was not so 
bad when I was just working on EFI stuff but if switch around between projects 
my editor having the wrong settings gets a lit old sometimes. 

The history of this was some of the old Intel legacy BIOS devs really pushed 
for the 2 spaces vs. 4 spaces so we let them have a win in the requirements. 
Turns out they have an old dot matrix printer with that old computer paper that 
had alternating colors on every line to make it easier to read the code. They 
pushed for 2 spaces so less code would line wrap on their team printer…..

Thanks,

Andrew Fish

> On Sep 25, 2023, at 2:03 AM, Marcin Juszkiewicz 
>  wrote:
> 
> I feel sick each time I have to edit EDK2 code.
> 
> All those INF, DEC, DSC, FDF, XYZ files are something I do not even try
> to understand, just got minimal knowledge what goes where by asking Leif
> (thanks a lot!) and observing build error messages.
> 
> I got used to UINTN and other weird variable types. No idea where from
> they came from (MS Windows?)
> 
> 
> But what sucks more is those 2 spaces used for indenting code. Took me
> a while to reming myself when I used such. It was in 90s, when I was
> Amiga programmer and all I had was 720x480px screen.
> 
> Last time I looked at calendar it was 2023 year. Maybe it is time to move
> to 4 spaces?
> 
> And can someone take a look at config of code obfuscator used for linting?
> It spits out amount of information showing that noone looked at updating it
> to current version:
> 
> $  uncrustify -c ../edk2/.pytool/Plugin/UncrustifyCheck/uncrustify.cfg  
> Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> Option: at ../edk2/.pytool/Plugin/UncrustifyCheck/uncrustify.cfg:48: 
> Expected unsigned number , for 'mod_full_brace_if_chain'; got 'false'
> ../edk2/.pytool/Plugin/UncrustifyCheck/uncrustify.cfg:79: unknown option 
> 'indent_func_call_edk2_style'
> Option: at ../edk2/.pytool/Plugin/UncrustifyCheck/uncrustify.cfg:212: 
> Expected number , for 'indent_bool_paren'; got 'true'
> Option: at ../edk2/.pytool/Plugin/UncrustifyCheck/uncrustify.cfg:224: 
> Expected number , for 'indent_comma_paren'; got 'true'
> ../edk2/.pytool/Plugin/UncrustifyCheck/uncrustify.cfg:241: option 
> 'indent_sing_line_comments' is deprecated; did you want to use 
> 'indent_single_line_comments_before' instead?
> ../edk2/.pytool/Plugin/UncrustifyCheck/uncrustify.cfg:270: unknown option 
> 'align_edk2_style'
> ../edk2/.pytool/Plugin/UncrustifyCheck/uncrustify.cfg:426: option 
> 'nl_func_var_def_blk' is deprecated; it has been replaced by 
> 'nl_var_def_blk_end_func_top'.
> You can also use 'nl_var_def_blk_end' for additional functionality
> ../edk2/.pytool/Plugin/UncrustifyCheck/uncrustify.cfg:447: option 'pp_space' 
> is deprecated; it has been replaced by 'pp_space_after'.
> Output suffix: .uncrustify
> do_source_file(1524): Parsing: 
> Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c as language C
> 
> $  uncrustify --version
> Uncrustify_d-0.76.0_f
> 
> 
> And yet it is a tool which contributors like me are supposed to use before
> sending any change upstream.
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109046): https://edk2.groups.io/g/devel/message/109046
Mute This Topic: https://groups.io/mt/101570674/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1] EmulatorPkg: Fix Source Level Debug on Windows

[Andrew Fish via groups.io]

Very cool. Thank You!

Thanks,

Andrew Fish

> On Sep 22, 2023, at 3:49 PM, Nate DeSimone  
> wrote:
> 
> The Visual Studio Windows debugger will only load symbols for PE/COFF images
> that Windows is aware of. Therefore, to enable source level debugging, all
> PEI/DXE modules must be loaded via LoadLibrary() or LoadLibraryEx() and the
> the instance in memory created by LoadLibrary() must be the one that is
> actually executed.
> 
> The current source level debug implementation in EmulatorPkg for Windows is
> inherited from the old Nt32Pkg. This implementation makes the assumption that
> all PEI/DXE modules have a DLL export tables with a symbol named
> InitializeDriver. Therefore, this source level debug implementation requires
> all modules to be linked in a non-PI spec defined manner. Support for adding
> the InitializeDriver symbol was removed in EmulatorPkg, which broke source
> level debugging.
> 
> To fix this, the source level debugging implementation has been modified to
> use the PE/COFF entry point directly. This brings the implementation into
> compliance with the PI spec and should work with any PEIM/DXE driver.
> Implementing this requires parsing the in-memory instance of the PE/COFF image
> created by Windows to find the entrypoint and since PEIMs/DXE drivers are not
> garunteed to have 4KB aligned sections, it also requires explicit 
> configuration
> of the page table using VirtualProtect().
> 
> With this fix, the debugging experience is now so good it is unprecedented!
> In Visual Studio Code, add the following to launch.json:
> 
> {
> "version": "0.2.0",
> "configurations": [
>   {
> "name": "EmulatorPkg Launch",
> "type": "cppvsdbg",
> "request": "launch",
> "program": 
> "${workspaceFolder}//Build/EmulatorX64/DEBUG_/X64/WinHost",
> "args": [],
> "stopAtEntry": false,
> "cwd": 
> "${workspaceFolder}//Build/EmulatorX64/DEBUG_/X64/",
> "environment": [],
> "console": false,
>   }
> ]
> }
> 
> Make modifications to the above template as nessesary and build EmulatorPkg.
> Now, just add breakpoints directly in Visual Studio Code the way you would 
> with
> any other software project. When you start the debugger, it will halt at the
> breakpoint automatically without any extra configuration required.
> 
> Cc: Andrew Fish 
> Cc: Ray Ni 
> Cc: Michael D Kinney 
> Cc: Chasel Chiu 
> Signed-off-by: Nate DeSimone 
> ---
> EmulatorPkg/Win/Host/WinHost.c | 206 +
> 1 file changed, 182 insertions(+), 24 deletions(-)
> 
> diff --git a/EmulatorPkg/Win/Host/WinHost.c b/EmulatorPkg/Win/Host/WinHost.c
> index 193a947fbd..e414da6c55 100644
> --- a/EmulatorPkg/Win/Host/WinHost.c
> +++ b/EmulatorPkg/Win/Host/WinHost.c
> @@ -8,7 +8,7 @@
>  This code produces 128 K of temporary memory for the SEC stack by directly
>  allocate memory space with ReadWrite and Execute attribute.
> 
> -Copyright (c) 2006 - 2022, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2023, Intel Corporation. All rights reserved.
> (C) Copyright 2016-2020 Hewlett Packard Enterprise Development LP
> SPDX-License-Identifier: BSD-2-Clause-Patent
> **/
> @@ -977,7 +977,7 @@ AddModHandle (
>  for (Index = 0; Index < mPdbNameModHandleArraySize; Index++, Array++) {
>if (Array->PdbPointer == NULL) {
>  //
> -  // Make a copy of the stirng and store the ModHandle
> +  // Make a copy of the string and store the ModHandle
>  //
>  Handle= GetProcessHeap ();
>  Size  = AsciiStrLen (ImageContext->PdbPointer) + 1;
> @@ -1056,26 +1056,45 @@ RemoveModHandle (
>  return NULL;
> }
> 
> +typedef struct {
> +  UINTN   Base;
> +  UINT32  Size;
> +  UINT32  Flags;
> +} IMAGE_SECTION_DATA;
> +
> VOID
> EFIAPI
> PeCoffLoaderRelocateImageExtraAction (
>  IN OUT PE_COFF_LOADER_IMAGE_CONTEXT  *ImageContext
>  )
> {
> -  EFI_STATUS  Status;
> -  VOID*DllEntryPoint;
> -  CHAR16  *DllFileName;
> -  HMODULE Library;
> -  UINTN   Index;
> +  EFI_STATUS  Status;
> +  VOID*DllEntryPoint;
> +  CHAR16  *DllFileName;
> +  HMODULE Library;
> +  UINTN   Index;
> +  PE_COFF_LOADER_IMAGE_CONTEXTPeCoffImageContext;
> +  EFI_IMAGE_OPTIONAL_HEADER_PTR_UNION Hdr;
> +  EFI_IMAGE_SECTION_HEADER*FirstSection;
> +  EFI_IMAGE_SECTION_HEADER*Section;
> +  IMAGE_SECTION_DATA  *SectionData;
> +  UINTN   NumberOfSections;
> +  UINTN   Base;
> +  UINTN   End;
> +  UINTN   RegionBase;
> +  UINTN   RegionSize;
> +  UINT32  Flags;
> +  DWORD   NewProtection;
> +  DWORD   OldProtection;
> 
>  ASSERT (ImageContext != NULL);
>  //
> -  // 

Re: [edk2-devel] How i can fix this build error VariableRuntimeDxe.inf

[Andrew Fish via groups.io]

Well NintendoSwitchPkg is a project we are not involved in….

Looks like you are missing a line in your DSC file:
VariableFlashInfoLib|MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.inf

The build failure is VariableRuntimeDxe.inf has a dependency on on a 
VariableFlashInfoLib instance and the DSC does not have a mapping for one. The 
VariableFlashInfoLib is just the library class just implies the library API, it 
does not imply which library to link against. The DSC file picks the correct 
library instance for your platforms build. 

My guess is your edk2 version is newer and you need to sync with some changes. 
Here is an example of the fix you need for the OVMF project. Basically an extra 
dependency got added to the Variable driver so you need to update the DSC.

commit a7d3d4e7c4343c478ec8a57c6ae1ae64286d866b
Author: Michael Kubacki 
Date:   Fri Apr 8 16:05:38 2022 -0400

OvmfPkg: Add VariableFlashInfoLib

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

Adds an instance of VariableFlashInfoLib to the platform build as
it is a new library class introduced in MdeModulePkg.

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: Gerd Hoffmann 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Julien Grall 
Cc: Min Xu 
Cc: Peter Grehan 
Cc: Rebecca Cran 
Cc: Sebastien Boeuf 
Cc: Tom Lendacky 
Signed-off-by: Michael Kubacki 
Acked-by: Ard Biesheuvel 
Reviewed-by: Liming Gao 
Reviewed-by: Rebecca Cran 
Reviewed-by: Jiewen Yao 

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index f0700035c1..bead9722ea 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -196,6 +196,7 @@
   VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
   
VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.inf
   
VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
+  
VariableFlashInfoLib|MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.inf
 
 !if $(BUILD_SHELL) == TRUE
   ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index 002cef32a3..f0166e136c 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -206,6 +206,7 @@
   VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
   
VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.inf
   
VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
+  
VariableFlashInfoLib|MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.inf
 
   #
   # Network libraries
diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc
index d1c85f60c7..92664f319b 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.dsc
+++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
@@ -217,6 +217,7 @@
   VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
   
VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.inf
   
VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
+  
VariableFlashInfoLib|MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.inf
 
 
   #
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index 80c331ea23..00bc1255bc 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
@@ -190,6 +190,7 @@
   VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
   
VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.inf
   
VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
+  
VariableFlashInfoLib|MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.inf
 
   ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
   ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
index 20c3c9c4d8..f8fc977cb2 100644
--- a/OvmfPkg/Microvm/MicrovmX64.dsc
+++ b/OvmfPkg/Microvm/MicrovmX64.dsc
@@ -207,6 +207,7 @@
   VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
   
VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.inf
   
VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
+  
VariableFlashInfoLib|MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.inf
 
 
   #
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 533bbdb435..c16a840fff 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -214,6 +214,7 @@
   VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
   
VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.inf
   

Re: [edk2-devel] VT100 terminal for UEFI shell

[Andrew Fish via groups.io]

> On Sep 7, 2023, at 12:11 PM, Marcin Juszkiewicz 
>  wrote:
> 
> W dniu 7.09.2023 o 19:40, Andrew (EFI) Fish pisze:
>>> On Sep 7, 2023, at 8:00 AM, Marcin Juszkiewicz wrote:
>>> 
>>> Is there a way to have VT100 (or any other black/white, non-ANSI) terminal 
>>> for UEFI Shell?
>>> 
>>> I do many runs of QEMU/sbsa-ref with logging and all those ANSI colour 
>>> codes only make problems.
> 
> 
>> Thus we get to the TL;DR part… The console NVRAM variables that point to the 
>> UART has a MESSAGING_DEVICE_PATH MSG_VENDOR_DP node after the UART 
>> definition that has a UUID (EFI_GUID) that defines the type of terminal 
>> emulation to use.
>> The definition of the ConIn and ConOut variables is here [4]
> 
> Feels like adding alias into ~/.bashrc is easier solution:
> 
> alias strip_ansi=" sed -e 's/\x1b\[[0-9;]*m//g' "
> 

Well like everything  the terminal default is optimized for the personal 
preference of who ever did OVMF port. 

> EDK2 code feels like ancient Perl to me too often. Someone wrote it, everyone 
> uses it, hard to find someone who know why it is that way.
> 
> 

Feel free to ask I’ll probably be 24 years into at some point soon or maybe 
already I kind of forgot when I started.  I was around for most of the big 
picture stuff so that is one of the reasons I answer these general questions on 
the list.

Thanks,

Andrew Fish

> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108416): https://edk2.groups.io/g/devel/message/108416
Mute This Topic: https://groups.io/mt/101216135/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] VT100 terminal for UEFI shell

[Andrew Fish via groups.io]

> On Sep 7, 2023, at 8:00 AM, Marcin Juszkiewicz 
>  wrote:
> 
> Is there a way to have VT100 (or any other black/white, non-ANSI) terminal 
> for UEFI Shell?
> 
> I do many runs of QEMU/sbsa-ref with logging and all those ANSI colour codes 
> only make problems.
> 

These are the supported consoles [1]

EFI_GUID  *mTerminalType[] = {
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  ,
  
};

CHAR16  *mSerialConsoleNames[] = {
  L"PC-ANSI Serial Console",
  L"VT-100 Serial Console",
  L"VT-100+ Serial Console",
  L"VT-UTF8 Serial Console",
  L"Tty Terminal Serial Console",
  L"Linux Terminal Serial Console",
  L"Xterm R6 Serial Console",
  L"VT-400 Serial Console",
  L"SCO Terminal Serial Console"
};

I think the OVMF default is coming from here [2]
VENDOR_DEVICE_PATHgTerminalTypeDeviceNode= gVtUtf8Terminal;

If you look up gVtUtf8Terminal you see [3]
#define gVtUtf8Terminal \
  { \
{ \
  MESSAGING_DEVICE_PATH, \
  MSG_VENDOR_DP, \
  { \
(UINT8) (sizeof (VENDOR_DEVICE_PATH)), \
(UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8) \
  } \
}, \
DEVICE_PATH_MESSAGING_VT_UTF8 \
  }

Thus we get to the TL;DR part… The console NVRAM variables that point to the 
UART has a MESSAGING_DEVICE_PATH MSG_VENDOR_DP node after the UART definition 
that has a UUID (EFI_GUID) that defines the type of terminal emulation to use. 

The definition of the ConIn and ConOut variables is here [4]

[1] 
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c#L24
[2] 
https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c#L50
[3] 
https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h#L129
[4] 
https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html#globally-defined-variables

Thanks,

Andrew Fish

> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108407): https://edk2.groups.io/g/devel/message/108407
Mute This Topic: https://groups.io/mt/101216135/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] Use C99 flexible arrays

[Andrew Fish via groups.io]

My understanding is zero length arrays have not been legal C code since C89. 
They may still function as a compiler extension. 

struct foo {
  size_t len;
  char. Str[]0]; 
};

I seem to remember the reason we did not use the C99 flexible array members is 
back in the day as Visual Studio 2003 did not have proper C99 support, and did 
not support it. 

struct foo {
  size_t len;
  char. Str[]]; 
};

I think the recommended C89 method for doing this is:

struct foo {
  size_t len;
  char. Str[]1]; 
};

But that is not backwards compatible as the sizes are different. 

So it is probably good long term to move to valid C99, but we should verify we 
did not break anything. 

Thanks,

Andrew Fish


> On Aug 21, 2023, at 9:56 AM, ehaouas  wrote:
> 
> ‌
> Hi,
> 
> No, I didn't.
>  
> De : "Yao, Jiewen"
> A : "devel@edk2.groups.io" ,"ehao...@noos.fr" ,"Yao, Jiewen"
> Envoyé: lundi 21 Août 2023 16:35
> Objet : RE: [edk2-devel] [PATCH] Use C99 flexible arrays
>  
> Hi
> This fix breaks the compatibility.
> 
> Have you tested all features that depends on this data structure?
> 
> Thank you
> Yao, Jiewen
> 
> > -Original Message-
> > From: devel@edk2.groups.io On Behalf Of Elyes Haouas
> > Sent: Sunday, August 20, 2023 8:07 PM
> > To: devel@edk2.groups.io
> > Cc: Elyes Haouas
> > Subject: [edk2-devel] [PATCH] Use C99 flexible arrays
> >
> > Use C99 flexible arrays instead of older style of one-element or
> > zero-length arrays.
> > It allows the compiler to generate errors when the flexible array does
> > not occur at the end in the structure.
> >
> > Signed-off-by: Elyes Haouas
> > ---
> > EmbeddedPkg/Include/fdt.h | 4 ++--
> > .../Library/FrameBufferBltLib/FrameBufferBltLib.c | 2 +-
> > MdePkg/Include/IndustryStandard/IpmiNetFnApp.h | 8 
> > MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h | 4 ++--
> > MdePkg/Include/IndustryStandard/IpmiNetFnStorage.h | 6 +++---
> > MdePkg/Include/IndustryStandard/IpmiNetFnTransport.h | 8 
> > MdePkg/Include/IndustryStandard/PldmSmbiosTransfer.h | 8 
> > MdePkg/Include/IndustryStandard/TcgStorageCore.h | 6 +++---
> > MdePkg/Include/Protocol/NetworkInterfaceIdentifier.h | 2 +-
> > MdePkg/Include/Protocol/NvdimmLabel.h | 2 +-
> > UefiPayloadPkg/Include/Coreboot.h | 10 +-
> > 11 files changed, 30 insertions(+), 30 deletions(-)
> >
> > diff --git a/EmbeddedPkg/Include/fdt.h b/EmbeddedPkg/Include/fdt.h
> > index 120dbc8bc6..f64695da5c 100644
> > --- a/EmbeddedPkg/Include/fdt.h
> > +++ b/EmbeddedPkg/Include/fdt.h
> > @@ -81,14 +81,14 @@ struct fdt_reserve_entry {
> >
> >
> > struct fdt_node_header {
> >
> > fdt32_t tag;
> >
> > - char name[0];
> >
> > + char name[];
> >
> > };
> >
> >
> >
> > struct fdt_property {
> >
> > fdt32_t tag;
> >
> > fdt32_t len;
> >
> > fdt32_t nameoff;
> >
> > - char data[0];
> >
> > + char data[];
> >
> > };
> >
> >
> >
> > #endif /* !__ASSEMBLY */
> >
> > diff --git a/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> > b/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> > index 432577bcfd..5fc5779e16 100644
> > --- a/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> > +++ b/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> > @@ -24,7 +24,7 @@ struct FRAME_BUFFER_CONFIGURE {
> > EFI_PIXEL_BITMASK PixelMasks;
> >
> > INT8 PixelShl[4]; // R-G-B-Rsvd
> >
> > INT8 PixelShr[4]; // R-G-B-Rsvd
> >
> > - UINT8 LineBuffer[0];
> >
> > + UINT8 LineBuffer[];
> >
> > };
> >
> >
> >
> > CONST EFI_PIXEL_BITMASK mRgbPixelMasks = {
> >
> > diff --git a/MdePkg/Include/IndustryStandard/IpmiNetFnApp.h
> > b/MdePkg/Include/IndustryStandard/IpmiNetFnApp.h
> > index b6bc91f46c..b5174a5042 100644
> > --- a/MdePkg/Include/IndustryStandard/IpmiNetFnApp.h
> > +++ b/MdePkg/Include/IndustryStandard/IpmiNetFnApp.h
> > @@ -433,7 +433,7 @@ typedef union {
> > typedef struct {
> >
> > UINT8 CompletionCode;
> >
> > IPMI_GET_MESSAGE_CHANNEL_NUMBER ChannelNumber;
> >
> > - UINT8 MessageData[0];
> >
> > + UINT8 MessageData[];
> >
> > } IPMI_GET_MESSAGE_RESPONSE;
> >
> >
> >
> > //
> >
> > @@ -457,12 +457,12 @@ typedef union {
> > typedef struct {
> >
> > UINT8 CompletionCode;
> >
> > IPMI_SEND_MESSAGE_CHANNEL_NUMBER ChannelNumber;
> >
> > - UINT8 MessageData[0];
> >
> > + UINT8 MessageData[];
> >
> > } IPMI_SEND_MESSAGE_REQUEST;
> >
> >
> >
> > typedef struct {
> >
> > UINT8 CompletionCode;
> >
> > - UINT8 ResponseData[0];
> >
> > + UINT8 ResponseData[];
> >
> > } IPMI_SEND_MESSAGE_RESPONSE;
> >
> >
> >
> > //
> >
> > @@ -906,7 +906,7 @@ typedef union {
> > typedef struct {
> >
> > IPMI_SET_USER_PASSWORD_USER_ID UserId;
> >
> > IPMI_SET_USER_PASSWORD_OPERATION Operation;
> >
> > - UINT8 PasswordData[0]; // 16 or 20 bytes, depending on the
> > 'PasswordSize' field
> >
> > + UINT8 PasswordData[]; // 16 or 20 bytes, depending on the
> > 'PasswordSize' field
> >
> > } IPMI_SET_USER_PASSWORD_REQUEST;
> >
> >
> >
> > //
> >
> > diff --git a/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
> > 

Re: [edk2-devel] About EDK2 supports Self Modifying Code

[Andrew Fish via groups.io]

> On Aug 17, 2023, at 12:53 PM, Michael D Kinney  
> wrote:
> 
> How many different integer values are needed by FW for use of the csrrd 
> instruction?
>  

MIke,

I’m no expert on this and I just tried to site read a specification for the 1st 
time….
It looks to me the like the arch spec does not say something like mm0 - mm7 it 
seems to imply mm0 - mmN (N is implementation defined). Some of these resources 
seemed to be debug registers and performance counters, so things that make a 
lot of sense to have a variable number defined by the implementation? 

Thanks,

Andrew Fish

> There are examples of access functions on x86 for things like mm0, mm1, mm2, 
> …, mm7 and cs, ds, es, ss, fs, gs.  These are implemented as different 
> BaseLib APIs because they would also require SMC to do in a single API.
>  
> If there is a small number of csrrd index values that need to be accessed, 
> and they have standard names, then perhaps you could define a set of APIs to 
> access those registers.
>  
> Mike
>  
> From: devel@edk2.groups.io  
> mailto:devel@edk2.groups.io>> On Behalf Of Chao Li
> Sent: Wednesday, August 16, 2023 7:30 PM
> To: devel@edk2.groups.io ; 
> pedro.falc...@gmail.com 
> Cc: Andrew (EFI) Fish mailto:af...@apple.com>>; Gao, Liming 
> mailto:gaolim...@byosoft.com.cn>>; Feng, Bob C 
> mailto:bob.c.f...@intel.com>>; Chen, Christine 
> mailto:yuwei.c...@intel.com>>
> Subject: Re: [edk2-devel] About EDK2 supports Self Modifying Code
>  
> Hi Pedro,
> 
> Sorry for the late reply, I was a bit busy yesterday.
> 
> I think the better way is to use inline asm, because this issue must has to 
> be dealt with in preprocessing stage, because in other stages, it has no 
> chance to get immediate value except using SMC. But then we should ask to the 
> MdePkg maintainer if it is OK.
> 
>  
> Thanks,
> Chao
> 在 2023/8/15 23:35, Pedro Falcato 写道:
> On Tue, Aug 15, 2023 at 9:20 AM Chao Li  
>  wrote:
>  
> Hi Andrew,
>  
> Yes, you are right, I also think that SMC is a bit flawed in terms of 
> security, but can we use some security mechanism to protect the SMC, like 
> encryption and decryption? Sorry, I'm not consider mature enough about SMC 
> security.
>  
> There isn't any. Actual use cases in something like a kernel are
> heavily vetted and read-protected as soon as possible.
>  
>  
> I can tell you real problem, there are some CSR instructions in LoongArch64 
> that can only accept immediate value, for example: `csrrd $a0, 0x1`, the 0x1 
> is the selection of CSR register number, it can't use the registers to 
> select. This operation should be in the MdePkg base library.
>  
> I know that .c or .h files in MdePkg shouldn't depend on a single compiler 
> feature, so I can't use the GNU AT style inline ASM function(AT style 
> inline supports input parameters being immedite value, use "i" option). In 
> this case, I think using SMC can handle this, that is use register transfer 
> the CSR registers selection, and dynamically modify CSR instructions during 
> execution phase with reference to transfer register value, this way is depend 
> on the .text section or target memory is executable and writable.
>  
> FYI, poking instructions willy-nilly is unsafe and unreliable (except
> on x86 due to kludges, but then it's slow).
>  
>  
> The problem of immediate values can only be handled by preprocessing stage or 
> using SMC, otherwise I can only write a lot of similar functions and use 
> `switch case` to call them. This method will cause the program size to expand 
> a lot.
>  
> So, I think I have following choice:
>  
> Choice 1:
>  
> Use AT style inline function, and create a file named: CsrOperationGcc.c, 
> and other future compiler feature-dependent files will be named: 
> CsrOperationClang.c, CsrOperationXlang.c and so on.
>  
> If you're going to use inline assembly, just expose them directly? I
> don't see the problem there, I don't expect loongarch to be picked up
> by visual studio any time soon.
>  
>  
>  
> Choice 2:
>  
> Use SMC.
>  
>  
> Choice 3:
>  
> Write a lot of similar CSR functions.
>  
> You /could/ use a GAS macro.
>  
> .macro csr_write csr
> .global CsrWrite\csr
> CsrWrite\csr:
> csrw a0, \csr
> ret
>  
> (this is riscv pseudo-asm but I know your arch is similar enough)
>  
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107841): https://edk2.groups.io/g/devel/message/107841
Mute This Topic: https://groups.io/mt/100751724/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Error F001: Module SmmLockBox.inf NOT found

[Andrew Fish via groups.io]

I think I may have botched this message in moderation….

Andrew,

Did you update the submodule?
git submodule update —init
See Submodules under this section of the ReadMe.rst: 
https://github.com/tianocore/edk2

What were you trying to build?

Thanks,

Andrew Fish
> Subject: Error F001: Module SmmLockBox.inf NOT found
> 
> Hi,
> 
> I have cloned edk from git:
> 
> I have got an error:
> 
> Architecture(s): IA32 X64
> Build target = RELEASE
> Toolchain =GCC5
> 
> Error F001: Module SmmLockBox.inf NOT found in DSC file; Is it really a 
> binary module?
> 
> I did not make any changes, just trying to build.
> 
> How can I solve it?
> 
> Thank you in advance,
> Andrew
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107833): https://edk2.groups.io/g/devel/message/107833
Mute This Topic: https://groups.io/mt/100798668/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

[Andrew Fish via groups.io]

Can you add -Wno-maybe-uninitialized to compiler flags to work around the error?On Aug 16, 2023, at 11:31 PM, 汪流  wrote:
	This is the failed build log: https://build.tarsier-infra.com/package/live_build_log/home:ouuleilei:branches:openEuler:Mainline/edk2/openEuler_Mainline_standard_riscv64_gcc/riscv64


	    arch:    riscv64


	gcc version： 10.3.1


	


	




	-原始郵件-
發件人:"Kinney, Michael D" 
發送時間:2023-08-17 01:50:37 (星期四)
收件人: "Andrew (EFI) Fish" , edk2-devel-groups-io 
抄送: "wang...@iscas.ac.cn" , "Kinney, Michael D" 
主題: RE: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

	

		
			

	Hi Andrew,


	 


	There are compiler flags we set to suppress some of these types of specific warnings to avoid disable warnings as errors.



	 


	For example, this commit to tools_def.template:


	 


	https://github.com/tianocore/edk2/commit/8e985ac3fdb2b117968ac1fa1f54666e166af8ac


	 


	I would like to see the compiler, version, arch, log info with the specific warning being flagged to see if we can apply the techniques we have been able to apply in the past.


	 


	Mike


	 


	
		
			
From: Andrew (EFI) Fish  
Sent: Wednesday, August 16, 2023 10:41 AM
To: edk2-devel-groups-io ; Kinney, Michael D 
Cc: wang...@iscas.ac.cn
Subject: Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？
			
		
	
	
		 
	
	
		Mike,
	
	
		
			 
		
	
	
		
			I seem to remember it was a maybe-uninitialized compiler error. The DEBUG build did not hit it due to the NULL check in the ASSERT. The NULL check
 only exists if ASSERT() is enabled. So if ASSERT is disabled this code in the DXE Core will dereference a NULL pointer. 
		
	
	
		
			 
		
	
	
		
			

	
		
			
      ASSERT (Prot != NULL);
			
		
	
	
		
			
      // 
			
		
	
	
		
			
      // EFI_ALREADY_STARTED is not an error for bus driver.
			
		
	
	
		
			
      // Return the corresponding protocol interface.
			
		
	
	
		
			
      // 
			
		
	
	
		
			
      *Interface = Prot->Interface;
			
		
	

			
		
	
	
		
			 
		
	
	
		
			Thanks,
		
	
	
		
			 
		
	
	
		
			Andrew Fish
		
		
			



			
			

	
		On Aug 16, 2023, at 10:02 AM, Michael D Kinney  wrote:
	


	 


	
		
			Can you provide the specific build error?
		
	
	
		
			 
		
	
	
		
			So far, we have not had to relax that flag for any RELEASE builds.
		
	
	
		
			 
		
	
	
		
			Thanks,
		
	
	
		
			 
		
	
	
		
			Mike
		
	
	
		
			 
		
	
	
		
			

	
		From: devel@edk2.groups.io  On
 Behalf Of ??
Sent: Wednesday, August 16, 2023 12:46 AM
To: Andrew (EFI) Fish 
Cc: edk2-devel-groups-io 
Subject: Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？
	

			
		
		
			
 
			
		
		
			Yes, the RELEASE build compiler flags should be relaxed, all error checks that the DEBUG target should do, it doesn't belong to the RELEASE's job. 
		
		
			  
		
		
			--- 
OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc | 2 +- 
1 file changed, 1 insertion(+), 1 deletion(-) 

diff --git a/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc b/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc 
index 28d9af4..ac3b5ec 100644 
--- a/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc 
+++ b/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc 
@@ -54,7 +54,7 @@ 
!include MdePkg/MdeLibs.dsc.inc 

[BuildOptions] 
-  GCC:RELEASE_*_*_CC_FLAGS   = -DMDEPKG_NDEBUG 
+  GCC:RELEASE_*_*_CC_FLAGS   = -flto 
!ifdef $(SOURCE_DEBUG_ENABLE) 
  GCC:*_*_RISCV64_GENFW_FLAGS    = --keepexceptiontable 
!endif 
-- 
2.39.1


 
		
		
			I have added the LTO flag and dropped MDEPKG_NDEBUG in the .dsc file, it compiled successfully, the build 

Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

[Andrew Fish via groups.io]

Mike,

I seem to remember it was a maybe-uninitialized compiler error. The DEBUG build 
did not hit it due to the NULL check in the ASSERT. The NULL check only exists 
if ASSERT() is enabled. So if ASSERT is disabled this code in the DXE Core will 
dereference a NULL pointer. 

>   ASSERT (Prot != NULL);
>   // 
>   // EFI_ALREADY_STARTED is not an error for bus driver.
>   // Return the corresponding protocol interface.
>   // 
>   *Interface = Prot->Interface;


Thanks,

Andrew Fish

> On Aug 16, 2023, at 10:02 AM, Michael D Kinney  
> wrote:
> 
> Can you provide the specific build error?
>  
> So far, we have not had to relax that flag for any RELEASE builds.
>  
> Thanks,
>  
> Mike
>  
> From: devel@edk2.groups.io  
> mailto:devel@edk2.groups.io>> On Behalf Of ??
> Sent: Wednesday, August 16, 2023 12:46 AM
> To: Andrew (EFI) Fish mailto:af...@apple.com>>
> Cc: edk2-devel-groups-io mailto:devel@edk2.groups.io>>
> Subject: Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？
>  
> Yes, the RELEASE build compiler flags should be relaxed, all error checks 
> that the DEBUG target should do, it doesn't belong to the RELEASE's job.
> 
>  
> 
> --- 
> OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc | 2 +- 
> 1 file changed, 1 insertion(+), 1 deletion(-) 
> 
> diff --git a/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc 
> b/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc 
> index 28d9af4..ac3b5ec 100644 
> --- a/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc 
> +++ b/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc 
> @@ -54,7 +54,7 @@ 
> !include MdePkg/MdeLibs.dsc.inc 
> 
> [BuildOptions] 
> -  GCC:RELEASE_*_*_CC_FLAGS   = -DMDEPKG_NDEBUG 
> +  GCC:RELEASE_*_*_CC_FLAGS   = -flto 
> !ifdef $(SOURCE_DEBUG_ENABLE) 
>   GCC:*_*_RISCV64_GENFW_FLAGS= --keepexceptiontable 
> !endif 
> -- 
> 2.39.1
> 
> 
> I have added the LTO flag and dropped MDEPKG_NDEBUG in the .dsc file, it 
> compiled successfully, the build 
> log:https://build.tarsier-infra.com/package/live_build_log/home:ouuleilei:branches:openEuler:Mainline/edk2/openEuler_Mainline_standard_riscv64_gcc/riscv64
> 
> Do you have other way to add LTO flag to compile that don't change the source 
> code, i tried to use environment variable, like exported CFLAGS=-flto to 
> compile, but the compiler doesn't work with it.
> 
>  
>  
> 
>  
> 
>  
> 
> -原始郵件-
> 發件人:"Andrew (EFI) Fish" mailto:af...@apple.com>>
> 發送時間:2023-08-10 21:50:55 (星期四)
> 收件人: edk2-devel-groups-io  >, wang...@iscas.ac.cn 
> 
> 抄送: 
> 主題: Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？
> 
> I think that you are advocating that since we have code that error checks on 
> DEBUG and not RELEASE builds we should relax the RELEASE build compiler flags?
>  
> /home/abuild/rpmbuild/BUILD/edk2-edk2-stable202305/MdeModulePkg/Core/Dxe/Hand/Handle.c:1183:24:
>  error: ‘Prot’ may be used uninitialized [-Werror=maybe-uninitialized]
>   ASSERT (Prot != NULL);
>   // 
>   // EFI_ALREADY_STARTED is not an error for bus driver.
>   // Return the corresponding protocol interface.
>   // 
>   *Interface = Prot->Interface;
>  
> A given platform can add ASSERT into release builds if it wants. I’ve 
> actually done that for power on before. If your compiler supports LTO you are 
> not required to set MDEPKG_NDEBUG on RELEASE builds, and you can used a PCD 
> to configure your debug level, per build type.  
>  
> Maybe we should just have the error checks in all paths?
>  
> Thanks, 
>  
> Andrew Fish 
> 
> 
> On Aug 10, 2023, at 6:44 AM, 汪流  > wrote:
>  
> I want to build a rpm package for edk2-stable202305 on riscv64, however I get 
> some uninitialized variable error, I have found that the reason is -Werror 
> flag.
> My build target was release. I think the flag should used in the debug ,not 
> in release.
> My build command:  build -t GCC5 -n $NCPUS -b RELEASE -a RISCV64 -p 
> OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc -D SECURE_BOOT_ENABLE=TRUE -D 
> TPM_ENABLE=TRUE -D TPM_CONFIG_ENABLE=TRUE
> This is my packet log:
> 
> https://build.tarsier-infra.com/package/live_build_log/home:ouuleilei:branches:home:ouuleilei:branches:openEuler:Mainline/edk2-test/openEuler_Mainline_standard_riscv64_gcc/riscv64
> 
> https://build.tarsier-infra.com/build/home:ouuleilei:branches:home:ouuleilei:branches:openEuler:Mainline/openEuler_Mainline_standard_riscv64_gcc/riscv64/edk2-test/_log
>  
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107801): https://edk2.groups.io/g/devel/message/107801
Mute This Topic: https://groups.io/mt/100663199/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] About EDK2 supports Self Modifying Code

[Andrew Fish via groups.io]

> On Aug 15, 2023, at 11:48 AM, Ard Biesheuvel  wrote:
> 
> On Tue, 15 Aug 2023 at 18:31, Andrew Fish via groups.io <http://groups.io/>
> mailto:afish=apple@groups.io>> wrote:
>> 
>> 
>> 
>>> On Aug 15, 2023, at 8:39 AM, Pedro Falcato  wrote:
>>> 
>>> On Tue, Aug 15, 2023 at 4:05 PM Andrew Fish via groups.io
>>>  wrote:
>>>> 
>>>> Chao,
>>>> 
>>>> From a quick google it looks like CSR* is used to access banks of 
>>>> registers that relate to things like performance counters and debug 
>>>> infrastructure and the number of banks of these register sets is likely 
>>>> implementation defined. Seems like we could introduce some Fixed At Build 
>>>> PCD values that define the maximum number of elements in a given bank.
>>>> 
>>>> If we are forced to use assembler it might be possible to write some 
>>>> macros that used the fixed at build values to only generate functions for 
>>>> banks that are needed for a given build. Then I think it becomes an 
>>>> exercise in dead code stripping the assembler. Most compilers generate 
>>>> assembler that contains functions that can be stripped as long as those 
>>>> functions follow certain rules.
>>>> 
>>>> As a side note it would be good for us to have an FAQ/Wiki entry for the 
>>>> dead code stripping rules for the various flavors of assembler. I know the 
>>>> Apple assembler has a unique take on this.
>>> 
>>> FWIW, I'm almost positive there's no DCE in GNU as (or llvm-as as
>>> well). Unless you use something ffunction-sections
>>> -fdata-sections-like, but then you're relying on the linker +
>>> gc-sections to take care of it, just like GCC/clang would.
>>> 
>> 
>> I guess I usually think of DCE as a linker job, since the linker knows the 
>> functions that are NOT called. At least from the Apple tools the DCE has the 
>> same rules if you are using Link Time Optimization or not. It is basically a 
>> flag in the object that tells the inker it is OK to follow the DCE rules 
>> around labels and remove stuff.
>> 
>> Worst case it seems like we could have macros that generate assembly files 
>> based on build time constants so we have one function per file. This might 
>> take a tweak to the build system, but I’d rather do that than have library 
>> functions that magically turn on Self Modifying Code.
>> 
>> Regardless of the answer I think documenting the rules is a useful exercises 
>> since needing to save size in firmware images is not an uncommon task.
>> 
> 
> There is already prior art in MdePkg where code targeting both GCC and
> VS uses inline asm, so I don't see why we would make our lives
> difficult and deviate from that for LoongArch.
> 

If you look at the BaseLib you can see an example of the INF file[1] using C 
inline assembler for the GCC family[2] of compilers and NASM for the MSFT [3] 
tools. Maybe you can plan on using a similar pattern.

[1] 
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/BaseLib.inf#L321
[2] 
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/X64/GccInline.c
[3] 
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/X64/CpuPause.nasm

Thanks,

Andrew Fish

> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107772): https://edk2.groups.io/g/devel/message/107772
Mute This Topic: https://groups.io/mt/100751724/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] About EDK2 supports Self Modifying Code

[Andrew Fish via groups.io]

> On Aug 15, 2023, at 8:39 AM, Pedro Falcato  wrote:
> 
> On Tue, Aug 15, 2023 at 4:05 PM Andrew Fish via groups.io
>  wrote:
>> 
>> Chao,
>> 
>> From a quick google it looks like CSR* is used to access banks of registers 
>> that relate to things like performance counters and debug infrastructure and 
>> the number of banks of these register sets is likely implementation defined. 
>> Seems like we could introduce some Fixed At Build PCD values that define the 
>> maximum number of elements in a given bank.
>> 
>> If we are forced to use assembler it might be possible to write some macros 
>> that used the fixed at build values to only generate functions for banks 
>> that are needed for a given build. Then I think it becomes an exercise in 
>> dead code stripping the assembler. Most compilers generate assembler that 
>> contains functions that can be stripped as long as those functions follow 
>> certain rules.
>> 
>> As a side note it would be good for us to have an FAQ/Wiki entry for the 
>> dead code stripping rules for the various flavors of assembler. I know the 
>> Apple assembler has a unique take on this.
> 
> FWIW, I'm almost positive there's no DCE in GNU as (or llvm-as as
> well). Unless you use something ffunction-sections
> -fdata-sections-like, but then you're relying on the linker +
> gc-sections to take care of it, just like GCC/clang would.
> 

I guess I usually think of DCE as a linker job, since the linker knows the 
functions that are NOT called. At least from the Apple tools the DCE has the 
same rules if you are using Link Time Optimization or not. It is basically a 
flag in the object that tells the inker it is OK to follow the DCE rules around 
labels and remove stuff. 

Worst case it seems like we could have macros that generate assembly files 
based on build time constants so we have one function per file. This might take 
a tweak to the build system, but I’d rather do that than have library functions 
that magically turn on Self Modifying Code. 

Regardless of the answer I think documenting the rules is a useful exercises 
since needing to save size in firmware images is not an uncommon task. 

Thanks,

Andrew Fish

> -- 
> Pedro
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107770): https://edk2.groups.io/g/devel/message/107770
Mute This Topic: https://groups.io/mt/100751724/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] About EDK2 supports Self Modifying Code

[Andrew Fish via groups.io]

Chao,

>From a quick google it looks like CSR* is used to access banks of registers 
>that relate to things like performance counters and debug infrastructure and 
>the number of banks of these register sets is likely implementation defined. 
>Seems like we could introduce some Fixed At Build PCD values that define the 
>maximum number of elements in a given bank. 

If we are forced to use assembler it might be possible to write some macros 
that used the fixed at build values to only generate functions for banks that 
are needed for a given build. Then I think it becomes an exercise in dead code 
stripping the assembler. Most compilers generate assembler that contains 
functions that can be stripped as long as those functions follow certain rules.

As a side note it would be good for us to have an FAQ/Wiki entry for the dead 
code stripping rules for the various flavors of assembler. I know the Apple 
assembler has a unique take on this.  

Thanks,

Andrew Fish

> On Aug 15, 2023, at 1:54 AM, Chao Li  wrote:
> 
> Hi Ard, 
> 
> Ok, I see, thanks for you suggestion.
> 
> 
> Thanks,
> Chao
> 在 2023/8/15 16:28, Ard Biesheuvel 写道:
>> On Tue, 15 Aug 2023 at 10:20, Chao Li  
>>  wrote:
>>> Hi Andrew,
>>> 
>>> Yes, you are right, I also think that SMC is a bit flawed in terms of 
>>> security, but can we use some security mechanism to protect the SMC, like 
>>> encryption and decryption? Sorry, I'm not consider mature enough about SMC 
>>> security.
>>> 
>>> I can tell you real problem, there are some CSR instructions in LoongArch64 
>>> that can only accept immediate value, for example: `csrrd $a0, 0x1`, the 
>>> 0x1 is the selection of CSR register number, it can't use the registers to 
>>> select. This operation should be in the MdePkg base library.
>>> 
>> That is *not* a good reason for using self modifying code. If the CSR
>> register number is known at build time, it should be emitted into the
>> binary at build time in one way or another.
>> 
>>> I know that .c or .h files in MdePkg shouldn't depend on a single compiler 
>>> feature, so I can't use the GNU AT style inline ASM function(AT style 
>>> inline supports input parameters being immedite value, use "i" option). In 
>>> this case, I think using SMC can handle this, that is use register transfer 
>>> the CSR registers selection, and dynamically modify CSR instructions during 
>>> execution phase with reference to transfer register value, this way is 
>>> depend on the .text section or target memory is executable and writable.
>>> 
>>> The problem of immediate values can only be handled by preprocessing stage 
>>> or using SMC, otherwise I can only write a lot of similar functions and use 
>>> `switch case` to call them. This method will cause the program size to 
>>> expand a lot.
>>> 
>>> So, I think I have following choice:
>>> 
>>> Choice 1:
>>> 
>>> Use AT style inline function, and create a file named: CsrOperationGcc.c, 
>>> and other future compiler feature-dependent files will be named: 
>>> CsrOperationClang.c, CsrOperationXlang.c and so on.
>>> 
>> If the only currently supported compiler (GCC?) has a syntax that
>> permits emitting this as inline asm, it is perfectly fine to use this
>> in your implementation. Once other compiler support is introduced, we
>> can think about how to address the difference, but I suspect that
>> Clang will just work with the GCC notation.
>> 
>> 
>> 
>> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107766): https://edk2.groups.io/g/devel/message/107766
Mute This Topic: https://groups.io/mt/100751724/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] About EDK2 supports Self Modifying Code

[Andrew Fish via groups.io]

We also support Xcode clang so that means we also support Mach-O executables 
that get converted to PE/COFF. The is a tool called mtoc (mach-o to coff) in a 
crufty old open source project that does the conversion. 

The reason you are having issues is due to security hardening as the self 
modifying code is a security risk. It is kind of hard to imagine a case in UEFI 
that the self modifying code is worth the security risk?. I know Linux does 
some patching but those are really hot paths that get used a lot, I don’t see 
that being a pattern that would be common in firmware. The only case I can 
think you might want SMC is if you were trying to make an UEFI based stress 
test of some kind? 

It might be helpful if you could explain why you can’t use a dispatch table or 
just define a UEFI Protocol and construct it on the fly to meet your 
configuration? To me saying you need Self Modifying Code is kind of like saying 
you need to write it in assembler since the C compiler is not smart enough, and 
most of the times people think that they are wrong.  

Thanks,

Andrew Fish

> On Aug 14, 2023, at 8:06 PM, Chao Li  wrote:
> 
> Hi Liming, Bob and Yuwei
> 
> There is a need that some code wants to supports Self-Modification, because 
> some program behavior may not be determined during compilation, and I think 
> this demand may be very popular. 
> 
> The permise of Self-Modification is that the section has executable and 
> writable permissions. Adding a new section and giving it executable and 
> writable permissions is a better way, and the 'pragma seg_code' is recognized 
> in Microsoft VS compiler but GCC doesn't. If use the GCC as the compiler, the 
> '.section name flags' of GNU GAS are acceptable.
> 
> But there is a problem, if converting from elf to efi, the user-defined 
> section with W+X or A+W+X will be droped, Elf64Convert.c will scan the file 
> section permission of elf, if the section is A+X, it will be classified into 
> the .text section, if the section is A+W , then it will be classified into 
> the .data section, if the section is A+W+X or W+X, then it will be 
> droped(Elf64Convert.c, line 272 to 325).
> 
> That is:
> 
> If using the VS compiler, the user-defined with executable and writable 
> sections may be perserved, but GCC elf to efi conversion may not.
> 
> 
> 
> Hope hearback from you and discuss the necessity of SMC(Slef-Modifying-Code) 
> and how to implement it.
> 
> 
> 
> 
> Thanks,
> Chao
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107760): https://edk2.groups.io/g/devel/message/107760
Mute This Topic: https://groups.io/mt/100751724/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 0/7] Add DebugMacroCheck

[Andrew Fish via groups.io]

> On Aug 14, 2023, at 5:26 PM, Michael Kubacki  
> wrote:
> 
> On 8/14/2023 8:23 PM, Andrew Fish via groups.io wrote:
>>> On Aug 14, 2023, at 3:51 PM, Pedro Falcato  wrote:
>>> 
>>> On Mon, Aug 14, 2023 at 9:49 PM Michael Kubacki
>>> mailto:mikub...@linux.microsoft.com>> wrote:
>>>> 
>>>> From: Michael Kubacki 
>>>> 
>>>> Adds a new script and build plugin called DebugMacroCheck.
>>>> 
>>>> The script verifies that the number of print specifiers match the
>>>> number of arguments in DEBUG() calls.
>>>> 
>>>> Overview:
>>>> 
>>>> - Build plugin: BuildPlugin/DebugMacroCheckBuildPlugin.py
>>>>  - Runs on any build target that is not NO-TARGET
>>>> - Standalone script: DebugMacroCheck.py
>>>>  - Run `DebugMacroCheck.py --help` to see command line options
>>>> - Unit tests:
>>>>  - Tests/test_DebugMacroCheck.py
>>>>  - Can be run with:
>>>>`python -m unittest discover -s ./.pytool/Plugin/DebugMacroCheck/tests 
>>>> -v`
>>>>  - Also visible in VS Code Test Explorer
>>>> 
>>>> Background:
>>>> 
>>>> The tool has been constantly run against edk2 derived code for about
>>>> a year now. During that time, its found over 20 issues in edk2, over
>>>> 50 issues in various vendor code, and numerous other issues specific
>>>> to Project Mu.
>>>> 
>>>> See the following series for a batch of issues previously fixed in
>>>> edk2 discovered by the tool:
>>>> 
>>>>  https://edk2.groups.io/g/devel/message/93104
>>>> 
>>>> I've received interest from vendors to place it in edk2 to
>>>> immediately find issues in the upstream and make it easier for edk2
>>>> consumers to directly acquire it. That led to this patch series.
>>>> 
>>>> This would run in edk2 as a build plugin. All issues in the edk2
>>>> codebase have been resolved so this would find new issues before
>>>> they are merged into the codebase.
>>> 
>>> Hi,
>>> 
>>> I really like this change but I cannot stop and think that if DEBUG
>>> and PrintLib were ISO C compliant, we could be using normal interfaces
>>> with normal argument types and the compiler's intrinsic knowledge of
>>> printf-like functions.
>>> Have you explored that option for future code? See e.g
>>> https://godbolt.org/z/4e8d3WToT <https://godbolt.org/z/4e8d3WToT>(I don't 
>>> know what MSVC uses, if
>>> anything).
>>> 
>> I have a dream that we add an eft_print as an attribute format archetype and 
>> then do what you recommend. After all clang and gcc are open source.
> I agree that would be preferred. I did something in similar in GCC at the 
> time, but I couldn't find an equivalent in VS. The issues kept appearing so 
> this was a cross-platform way to address it.
> 

This is a case that CI can help :)

Thanks,

Andrew Fish 

> I uploaded some usage examples to the PR for reference:
> https://github.com/tianocore/edk2/pull/4736
> 
> Thanks,
> Michael
>> Thanks,
>> Andrew Fish
>>> --
>>> Pedro
>>> 
>>> 
>> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107752): https://edk2.groups.io/g/devel/message/107752
Mute This Topic: https://groups.io/mt/100745693/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 0/7] Add DebugMacroCheck

[Andrew Fish via groups.io]

> On Aug 14, 2023, at 3:51 PM, Pedro Falcato  wrote:
> 
> On Mon, Aug 14, 2023 at 9:49 PM Michael Kubacki
> mailto:mikub...@linux.microsoft.com>> wrote:
>> 
>> From: Michael Kubacki 
>> 
>> Adds a new script and build plugin called DebugMacroCheck.
>> 
>> The script verifies that the number of print specifiers match the
>> number of arguments in DEBUG() calls.
>> 
>> Overview:
>> 
>> - Build plugin: BuildPlugin/DebugMacroCheckBuildPlugin.py
>>  - Runs on any build target that is not NO-TARGET
>> - Standalone script: DebugMacroCheck.py
>>  - Run `DebugMacroCheck.py --help` to see command line options
>> - Unit tests:
>>  - Tests/test_DebugMacroCheck.py
>>  - Can be run with:
>>`python -m unittest discover -s ./.pytool/Plugin/DebugMacroCheck/tests -v`
>>  - Also visible in VS Code Test Explorer
>> 
>> Background:
>> 
>> The tool has been constantly run against edk2 derived code for about
>> a year now. During that time, its found over 20 issues in edk2, over
>> 50 issues in various vendor code, and numerous other issues specific
>> to Project Mu.
>> 
>> See the following series for a batch of issues previously fixed in
>> edk2 discovered by the tool:
>> 
>>  https://edk2.groups.io/g/devel/message/93104
>> 
>> I've received interest from vendors to place it in edk2 to
>> immediately find issues in the upstream and make it easier for edk2
>> consumers to directly acquire it. That led to this patch series.
>> 
>> This would run in edk2 as a build plugin. All issues in the edk2
>> codebase have been resolved so this would find new issues before
>> they are merged into the codebase.
> 
> Hi,
> 
> I really like this change but I cannot stop and think that if DEBUG
> and PrintLib were ISO C compliant, we could be using normal interfaces
> with normal argument types and the compiler's intrinsic knowledge of
> printf-like functions.
> Have you explored that option for future code? See e.g
> https://godbolt.org/z/4e8d3WToT (I don't know what MSVC uses, if
> anything).
> 

I have a dream that we add an eft_print as an attribute format archetype and 
then do what you recommend. After all clang and gcc are open source. 

Thanks,

Andrew Fish

> -- 
> Pedro
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107746): https://edk2.groups.io/g/devel/message/107746
Mute This Topic: https://groups.io/mt/100745693/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

[Andrew Fish via groups.io]

I think that you are advocating that since we have code that error checks on 
DEBUG and not RELEASE builds we should relax the RELEASE build compiler flags?

/home/abuild/rpmbuild/BUILD/edk2-edk2-stable202305/MdeModulePkg/Core/Dxe/Hand/Handle.c:1183:24:
 error: ‘Prot’ may be used uninitialized [-Werror=maybe-uninitialized]
  ASSERT (Prot != NULL);
  //
  // EFI_ALREADY_STARTED is not an error for bus driver.
  // Return the corresponding protocol interface.
  //
  *Interface = Prot->Interface;

A given platform can add ASSERT into release builds if it wants. I’ve actually 
done that for power on before. If your compiler supports LTO you are not 
required to set MDEPKG_NDEBUG on RELEASE builds, and you can used a PCD to 
configure your debug level, per build type. 

Maybe we should just have the error checks in all paths?

Thanks,

Andrew Fish

> On Aug 10, 2023, at 6:44 AM, 汪流  wrote:
> 
> I want to build a rpm package for edk2-stable202305 on riscv64, however I get 
> some uninitialized variable error, I have found that the reason is -Werror 
> flag.
> My build target was release. I think the flag should used in the debug ,not 
> in release.
> My build command:  build -t GCC5 -n $NCPUS -b RELEASE -a RISCV64 -p 
> OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc -D SECURE_BOOT_ENABLE=TRUE -D 
> TPM_ENABLE=TRUE -D TPM_CONFIG_ENABLE=TRUE
> This is my packet log:   
> 
> https://build.tarsier-infra.com/package/live_build_log/home:ouuleilei:branches:home:ouuleilei:branches:openEuler:Mainline/edk2-test/openEuler_Mainline_standard_riscv64_gcc/riscv64
> 
> https://build.tarsier-infra.com/build/home:ouuleilei:branches:home:ouuleilei:branches:openEuler:Mainline/openEuler_Mainline_standard_riscv64_gcc/riscv64/edk2-test/_log
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107692): https://edk2.groups.io/g/devel/message/107692
Mute This Topic: https://groups.io/mt/100663199/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Runtime Page Granularity on ARM64

[Andrew Fish via groups.io]

Oliver,

My understanding is that AArch64 (ARMv8) supports 3 page table granules: 4KB, 
16KB, and 64KB [1]. These granules represent the smallest range for a page 
table, and this granule changes which bits of the VA index into what level of 
paging. On x86 this indexing was fixed an a 2 MiB page table just liveds higher 
up in the same hierarchy. 

While AArch64 supports all 3 granule sizes, how many granule sizes are 
supported by a given CPU is implementation defined. So it is legal for an 
AArch64 CPU to only support 64KB pages. You can always do 4K pages on Intel, so 
that is the difference. 

[1] https://developer.arm.com/documentation/101811/0103/Translation-granule

Thanks,

Andrew Fish

> On Aug 9, 2023, at 5:35 PM, Oliver Smith-Denny  
> wrote:
> 
> Hi Ard,
> 
> I just sent out a patch (MdeModulePkg: HeapGuard: Don't Assume Pool Head
> Allocated In First Page) to fix HeapGuard GuardAlignedToTail behavior on
> ARM64. However, this raised a question of why ARM64 sets
> RUNTIME_PAGE_ALLOCATION_GRANULARITY to 64k when X64 does not. You added
> this in ProcessorBind.h for ARM64, so I am hoping to get some additional
> context from you (or anyone on the mailing list who has insight).
> 
> I understand that on ARM64 we can have 64k pages in the OS, but what I
> do not understand is why we need to map in 64k chunks in UEFI. I see the
> UEFI spec says that ARM allows for 64K pages and that if runtime code
> or data is within a 64KB page then all 4k pages within that 64K page
> need the same memory attributes, which makes sense.
> 
> Is this runtime granularity just to satisfy that requirement that the
> memory attributes are the same or is there an additional reason that
> we need to use the 64k granularity on ARM64?
> 
> In any case, I am confused why this is not an issue on X64 or if we
> have 2MB pages in the OS? I'm not as familiar with the mechanisms an
> OS will use to map runtime services within its space, but they will be
> virtualized and the OS will have its own page tables, so it doesn't
> quite follow to me why the OS cares all that much what UEFI has done.
> 
> Any light you can shed here would be greatly appreciated.
> 
> Thanks,
> Oliver
> 
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107660): https://edk2.groups.io/g/devel/message/107660
Mute This Topic: https://groups.io/mt/100652665/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-test]

[Andrew Fish via groups.io]

John,

The UEFI Forum (https://uefi.org/) is the industry trade group that owns the 
UEFI and ACPI specifications. It also hosts the SCTs: https://uefi.org/testtools

Thanks,

Andrew Fish

> On Jul 17, 2023, at 9:31 AM, Sellock, John via groups.io 
>  wrote:
> 
> Hello,
>  
> I am John Sellock, an Associate Software Engineering Technician at Leonardo 
> DRS.
> I believe I need Self-Certification Test source code for UEFI 2.5, but I 
> cannot find any saved archive for it available in the tianocore or edk2-test 
> repositories.
> I would appreciate if someone could point me in the right direction, if I 
> overlooked it, or let me know if archived SCT source are no longer available 
> by any means.
> 
> Thank you,
> John Sellock
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107018): https://edk2.groups.io/g/devel/message/107018
Mute This Topic: https://groups.io/mt/100212052/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Managing boot order dependencies with ResetNotification Protocol

[Andrew Fish via groups.io]

Ajay,

In general the order of dispatch when all the DEPEX evaluate to TRUE and the 
oder of events are not defined by the specification. 

I think you are trying to say stuff that dispatches later is higher up the 
stack and it would make more sense to send the rest to things higher up the 
stack? 

I’m not sure how this would work in your example as the Tcg2Dxe driver has a 
Depex of gEfiVariableArchProtocolGuid and the NVMe driver is a UEFI_DRIVER so 
it has an implied Depex [1] that is more complex?

To really fix we would probably need to add some kind of new protocol tot he 
NVMe driver that lets drivers request the reset get delayed. It would have a 
register, unregister, I’m Done.  
The NVMe driver would do something like:
1) Register for the  reset notification
2) Publish the new protocol
3) When the 1st driver registers the NVMe driver unregisters the reset 
notification, or I guess it could just ignore it. 

When the shutdown happens and the last registered driver calls back in to say 
I’m Done then the NVMe driver can shutdown. 
The other drivers will need to RegisterProtocolNotify so there is not dispatch 
sequence dependency.

I’m not sure that is the best solution, that is just the best I have right now.

[1] UEFI_DRIVER depends on all the protocols required to impelemnt all the UEFI 
Boot and Runtime Services.
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/DxeMain/DxeProtocolNotify.c#L21
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/DxeMain/DxeProtocolNotify.c#L80

Thanks,

Andrew FIsh

> On Jun 28, 2023, at 5:23 PM, Ajay Iyengar (QUIC)  
> wrote:
> 
> Hello,
>  
> This is a comment and query on the Reset Notification Protocol defined by the 
> UEFI specification.
>  
> The specification requires clients to be notified for ResetSystem() without 
> imposing any specific ordering on how these notifications are dispatched: 
> https://uefi.org/specs/UEFI/2.10/39_Micellaneous_Protocols.html#reset-notification-protocol.
>  
> For example, this is used for gracefully shutting off NVMe and TPM through 
> their respective spec defined power off notifications: 
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c#L950
> https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c#L2597
>  
> If we assume a platform implementing fTPM using NVMe-RPMB,  the boot order 
> would require NVMe as a dependency for TPM, but that might result in an issue 
> with the reset notification path. The default EDK2 implementation dispatches 
> these notifications in boot order: 
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c#L78.
>   Here NVMe would power off, before TPM commits to NVMe-RPMB within its reset 
> notification callback. Reversing the order of dispatch (i.e. reverse-boot 
> order) would help with this situation.
>  
> We have several similar situations on our platform -- drivers with a Depex 
> ordering registering for ResetNotify which would benefit from being signaled 
> in reverse-boot order. Are there any provisions that could be made with 
> regards to ensuring the ordering requirement?  Could we mimic the behavior of 
> the ExitBootServices event dispatch for ResetNotify:
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Event/Event.c#L492
>  ?
> [The proposal would be to use InsertHeadList() instead of InsertTailList() in 
> RegisterResetNotify()]
>  
> Thanks,
> Ajay



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106822): https://edk2.groups.io/g/devel/message/106822
Mute This Topic: https://groups.io/mt/99845132/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] CpuDeadLoop() is optimized by compiler

[Andrew Fish via groups.io]

I don’t think the atomic is going to help. The compiler honored the volatile by 
doing a read, but assumed it would never change due to scoping. As you can see 
in my example if the compiler thinks DeadLoopCount can be changed it will put 
the check back in and assume the function can return. So an assembly function 
that does nothing called IncreaseScope()  would fix this issue too. 

void IncreaseScope(int *ptr);

void CpuDeadLoopFix(void) {
  volatile int DeadLoopCount = 0;
  while(DeadLoopCount == 0) {
IncreaseScope();
  }
}

void CpuDeadLoop(void) {
  volatile int DeadLoopCount = 0;
  while(DeadLoopCount == 0);
}

Gives us:

voltbl  SEGMENT
voltbl  ENDS
voltbl  SEGMENT
voltbl  ENDS

DeadLoopCount$ = 48
CpuDeadLoopFix PROC   ; COMDAT
$LN12:
sub rsp, 40 ; 0028H
mov DWORD PTR DeadLoopCount$[rsp], 0
jmp SHORT $LN10@CpuDeadLoo
$LL2@CpuDeadLoo:
lea rcx, QWORD PTR DeadLoopCount$[rsp]
callIncreaseScope
$LN10@CpuDeadLoo:
mov eax, DWORD PTR DeadLoopCount$[rsp]
testeax, eax
je  SHORT $LL2@CpuDeadLoo
add rsp, 40 ; 0028H
ret 0
CpuDeadLoopFix ENDP

DeadLoopCount$ = 8
CpuDeadLoop PROC; COMDAT
mov DWORD PTR DeadLoopCount$[rsp], 0
$LL2@CpuDeadLoo:
mov eax, DWORD PTR DeadLoopCount$[rsp]
jmp SHORT $LL2@CpuDeadLoo
CpuDeadLoop ENDP


https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYTStJg1DIApACYAQuYukl9ZATwDKjdAGFUtAK4sGIM6SuADJ4DJgAcj4ARpjEINIADqgKhE4MHt6%2B/qRJKY4CIWGRLDFx0naYDmlCBEzEBBk%2BfgEVVQI1dQSFEdGx8ba19Y1ZLYNdoT0lfZIAlLaoXsTI7BwA9KsA1AAqAJ4JmBs7C8QbaFgbCLGYpBskG7SoTOgbhhuYqqwJ9AB0JhoAgqECBsFABHLx1TAQIEbBg%2BGYbEwAdisAI26I2xEwBEWDFhPg2ACp8SwTABmVH/ZEAEQ4c1onAArLw/BwtKRUJw3NZrCDjstEWYyTxSARNHS5gBrECMjT6TiSFnijmcXgKEBysVsumkOCwJBoFgJOixciUQ3G%2BhxYBcMxcPh0AixdUQKLKqKhOo7Tgiw1sQQAeQYtG92tIWBYhmA4jD%2BCxVQAbph1WH3pUvE6fbwgZgGWHaHgosQvR4sMqCMQ8Cws3MqAZgAoAGp4TAAdwD%2B1ZIv4ghEYnYUhkgkUKnUYd09oMRhQPMs%2BkL6sgc1QCXyDBTAFoA2SNhvI0sEOTqQpJTsDJLMGrc5U1y4GO5PE09MEJsVSnpcqkBMM/PbP2vujfPp7VaNcOiGR8shA682gYcDxiKXo4hAsYfz0BQxkApCJDmBR%2BQHUUsRWHh6SZJUw05DhVAADgANg3WjJA2YBkGQDZbW%2BLgNggblLGsG5cEIO5zGFG4PCNE0ThErgZl4LUtDmCADVQCSrTNCALUklApxtSQNDlGhaCdYgXTdMMPWYYhQ19FT/QIIMQ2VCMoxjdk4xvPAkxTdk02QDNiOzQRc2VAsixLDAVnZCsqxrPh6ybFt207LMh2EURxEHHt5CUNRlV0AIdJnPi51CxcIGXVc0k3bdd33ZBDzJY9T3PS9bBg28IFcND7RfRCpmQnJki/dJIN/Qa8jSLD%2BvQ9rqlQ0aZvsMDMNfbCUM6bqBk6Kb3xk%2BZFmWPQK0wALSI4ZlSFZdlKJo%2BjGNOHT2Mkb4NBe7jeKsOcNkEogpKFe0NnEy1YkFMkzFk0VxUUpB8CoKh1KyvsMukLKR1y/MEHVSdMdhqgCD2dg5WITHsmJhRcfx/YNTOi6rt4SjqTwOGNmbNsQduhimJYtiOK4hMFA2Dn7uQR6pBel65KhqUZTlPNFUu5VKLVbJ5IleUODMcjrtVSHtRmOYkxMtJ4iAA

Thanks,

Andrew Fish

PS I’m still not 100% sure it is a compiler bug. Some times things like this 
are due to the order the compiler applies the optimizations, and changing the 
order can change the behavior. 


> On May 19, 2023, at 8:31 AM, Rebecca Cran  wrote:
> 
> Just to add more data, I also tried with "volatile sig_atomic_t" as someone 
> suggested and both "/volatile:iso" and "/volatile:ms" with no change in 
> results.
> 
> 
> -- 
> 
> Rebecca Cran
> 
> 
> On 5/18/23 20:53, Ni, Ray wrote:
>> 
>> I think all the options we considered are workarounds. These might break 
>> again if compiler is “cleverer” in future. Unless some Cxx spec clearly 
>> guarantees that.
>> 
>> I like Mike’s idea to use assembly implementation for CpuDeadLoop. The 
>> assembly can simply “jmp $” then “ret”.
>> 
>> I didn’t find a dead-loop intrinsic function in MSVC.
>> 
>> Any better idea?
>> 
>> Thanks,
>> 
>> Ray
>> 
>> *From:* Andrew (EFI) Fish 
>> *Sent:* Friday, May 19, 2023 8:42 AM
>> *To:* devel@edk2.groups.io; Kinney, Michael D 
>> *Cc:* Ni, Ray ; Rebecca Cran 
>> *Subject:* Re: [edk2-devel] CpuDeadLoop() is optimized by compiler
>> 
>> Mike,
>> 
>> Sorry static was just to scope the name to the file since it is a lib, not 
>> to make it work.
>> 
>> That is a cool site. I learned about it complaining about stuff to the 
>> compiler team on our internal clang Slack channel as they use it to answer 
>> my questions.
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> 
>> 
>>On May 18, 2023, at 2:42 PM, Michael D Kinney
>> wrote:
>> 
>>Using that tool, the following fragment seems to generate the
>>right code. Volatile is required.  Static is optional.
>> 
>>staticvolatileint mDeadLoopCount =0;
>> 
>>void
>> 
>>CpuDeadLoop(
>> 
>>void
>> 
>>  )
>> 
>>{
>> 
>>while(mDeadLoopCount ==0);
>> 
>>}
>> 
>>GCC
>> 
>>===
>> 
>>CpuDeadLoop():
>> 
>>.L2:
>> 
>>moveax,DWORDPTRmDeadLoopCount[rip]
>> 
>>testeax,eax
>> 
>>je.L2
>> 
>>ret
>> 
>>CLANG
>> 
>>=
>> 
>>CpuDeadLoop():# @CpuDeadLoop()
>> 
>>.LBB0_1:  

Re: [edk2-devel] CpuDeadLoop() is optimized by compiler

[Andrew Fish via groups.io]

ciUQ3G%2BhxYBcMxcPh0AixdUQKLKqKhOo7Tgiw1sQQAeQYtG92tIWBYhmA4jD%2BCxVQAbph1WH3pUvE6fbwgZgGWHaHgosQvR4sMqCMQ8Cws3MqAZgAoAGp4TAAdwD%2B1ZIv4ghEYnYUhkgkUKnUYd09oMRhQPMs%2BkL6sgc1QCXyDBTAFoA2SNhvI0sEOTqQpJTsDJLMGrc5U1y4GO5PE09MEJsVSnpcqkBMM/PbP2vujfPp7VaNcOiGR8shA682gYcDxiKXo4hAsYfz0BQxkApCJDmBR%2BQHUUsRWHh6SZJUw05DhVAADgANg3WjJA2YBkGQDZbW%2BLgNggblLGsG5cEIO5zGFG4PCNE0ThErgZl4LUtDmCADVQCSrTNCALUklApxtSQNDlGhaCdYgXTdMMPWYYhQ19FT/QIIMQ2VCMoxjdk4xvPAkxTdk02QDNiOzQRc2VAsixLDAVnZCsqxrPh6ybFt207LMh2EURxEHHt5CUNRlV0AIdJnPi51CxcIGXVc0k3bdd33ZBDzJY9T3PS9bBg28IFcND7RfRCpmQnJki/dJIN/Qa8jSLD%2BvQ9rqlQ0aZvsMDMNfbCUM6bqBk6Kb3xk%2BZFmWPQK0wALSI4ZlSFZdlKJo%2BjGNOHT2Mkb4NBe7jeKsOcNkEogpKFe0NnEy1YkFMkzFk0VxUUpB8CoKh1KyvsMukLKR1y/MEHVSdMdhqgCD2dg5WITHsmJhRcfx/YNTOi6rt4SjqTwOGNmbNsQduhimJYtiOK4hMFA2Dn7uQR6pBel65KhqUZTlPNFUu5VKLVbJ5IleUODMcjrtVSHtRmOYkxMtJ4iAA>
>  
> Thanks,
>  
> Andrew Fish
> 
> 
> On May 18, 2023, at 11:45 AM, Andrew Fish via groups.io 
> <http://groups.io/> <mailto:afish=apple@groups.io>> wrote:
>  
> Mike,
>  
> This is a good way to play around with fixes, and to report bugs. You can see 
> the assembler for different compilers with different flag. 
>  
> Compiler Explorer 
> <https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYTStJg1DIApACYAQuYukl9ZATwDKjdAGFUtAK4sGIM6SuADJ4DJgAcj4ARpjEINIADqgKhE4MHt6%2B/qRJKY4CIWGRLDFx0naYDmlCBEzEBBk%2BfgEVVQI1dQSFEdGx8ba19Y1ZLYNdoT0lfZIAlLaoXsTI7BwA9KsA1AAqAJ4JmBs7C8QbaFgbCLGYpBskG7SoTOgbhhuYqqwJ9AB0JhoAgqECBsFABHLx1TAQIEbBg%2BGYbEwAdisAI26I2xEwBEWDFhPg2ACp8SwTABmVH/ZEAEQ4c1onAArLw/BwtKRUJw3NZrCDjstEWYyTxSARNHS5gBrECMjT6TiSFnijmcXgKEBysVsumkOCwJBoFgJOixciUQ3G%2BhxYBcMxcPh0AixdUQKLKqKhOo7Tgiw1sQQAeQYtG92tIWBYhmA4jD%2BCxVQAbph1WH3pUvE6fbwgZgGWHaHgosQvR4sMqCMQ8Cws3MqAZgAoAGp4TAAdwD%2B1ZIv4ghEYnYUhkgkUKnUYd09oMRhQPMs%2BkL6sgc1QCXyDBTAFoA2SNhvI0sEOTqQpJTsDJLMGrc5U1y4GO5PE09MEJsVSnpcqkBMM/PbP2vujfPp7VaNcOiGR8shA682gYcDxiKXo4hAsYfz0BQxkApCJDmBR%2BQHUUsRWHh6SZJUw05DhVAADgANg3WjJA2YBkGQDZbW%2BLgNggblLGsG5cEIO5zGFG4PCNE0ThErgZl4LUtDmCADVQCSrTNCALUklApxtSQNDlGhaCdYgXTdMMPWYYhQ19FT/QIIMQ2VCMoxjdk4xvPAkxTdk02QDNiOzQRc2VAsixLDAVnZCsqxrPh6ybFt207LMh2EURxEHHt5CUNRlV0AIdJnPi51CxcIGXVc0k3bdd33ZBDzJY9T3PS9bBg28IFcND7RfRCpmQnJki/dJIN/Qa8jSLD%2BvQ9rqlQ0aZvsMDMNfbCUM6bqBk6Kb3xk%2BZFmWPQK0wALSI4ZlSFZdlKJo%2BjGNOHT2Mkb4NBe7jeKsOcNkEogpKFe0NnEy1YkFMkzFk0VxUUpB8CoKh1KyvsMukLKR1y/MEHVSdMdhqgCD2dg5WITHsmJhRcfx/YNTOi6rt4SjqTwOGNmbNsQduhimJYtiOK4hMFA2Dn7uQR6pBel65KhqUZTlPNFUu5VKLVbJ5IleUODMcjrtVSHtRmOYkxMtJ4iAA>
> godbolt.org 
> <https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYTStJg1DIApACYAQuYukl9ZATwDKjdAGFUtAK4sGIM6SuADJ4DJgAcj4ARpjEINIADqgKhE4MHt6%2B/qRJKY4CIWGRLDFx0naYDmlCBEzEBBk%2BfgEVVQI1dQSFEdGx8ba19Y1ZLYNdoT0lfZIAlLaoXsTI7BwA9KsA1AAqAJ4JmBs7C8QbaFgbCLGYpBskG7SoTOgbhhuYqqwJ9AB0JhoAgqECBsFABHLx1TAQIEbBg%2BGYbEwAdisAI26I2xEwBEWDFhPg2ACp8SwTABmVH/ZEAEQ4c1onAArLw/BwtKRUJw3NZrCDjstEWYyTxSARNHS5gBrECMjT6TiSFnijmcXgKEBysVsumkOCwJBoFgJOixciUQ3G%2BhxYBcMxcPh0AixdUQKLKqKhOo7Tgiw1sQQAeQYtG92tIWBYhmA4jD%2BCxVQAbph1WH3pUvE6fbwgZgGWHaHgosQvR4sMqCMQ8Cws3MqAZgAoAGp4TAAdwD%2B1ZIv4ghEYnYUhkgkUKnUYd09oMRhQPMs%2BkL6sgc1QCXyDBTAFoA2SNhvI0sEOTqQpJTsDJLMGrc5U1y4GO5PE09MEJsVSnpcqkBMM/PbP2vujfPp7VaNcOiGR8shA682gYcDxiKXo4hAsYfz0BQxkApCJDmBR%2BQHUUsRWHh6SZJUw05DhVAADgANg3WjJA2YBkGQDZbW%2BLgNggblLGsG5cEIO5zGFG4PCNE0ThErgZl4LUtDmCADVQCSrTNCALUklApxtSQNDlGhaCdYgXTdMMPWYYhQ19FT/QIIMQ2VCMoxjdk4xvPAkxTdk02QDNiOzQRc2VAsixLDAVnZCsqxrPh6ybFt207LMh2EURxEHHt5CUNRlV0AIdJnPi51CxcIGXVc0k3bdd33ZBDzJY9T3PS9bBg28IFcND7RfRCpmQnJki/dJIN/Qa8jSLD%2BvQ9rqlQ0aZvsMDMNfbCUM6bqBk6Kb3xk%2BZFmWPQK0wALSI4ZlSFZdlKJo%2BjGNOHT2Mkb4NBe7jeKsOcNkEogpKFe0NnEy1YkFMkzFk0VxUUpB8CoKh1KyvsMukLKR1y/MEHVSdMdhqgCD2dg5WITHsmJhRcfx/YNTOi6rt4SjqTwOGNmbNsQduhimJYtiOK4hMFA2Dn7uQR6pBel65KhqUZTlPNFUu5VKLVbJ5IleUODMcjrtVSHtRmOYkxMtJ4iAA>
>  
>  
> <https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYTStJg1DIApACYAQuYukl9ZATwDKjdAGFUtAK4sGIM6SuADJ4DJgAcj4ARpjEINIADqgKhE4MHt6%2B/qRJKY4CIWGRLDFx0naYDmlCBEzEBBk%2BfgEVVQI1dQSFEdGx8ba19Y1ZLYNdoT0lfZIAlLaoXsTI7BwA9KsA1AAqAJ4JmBs7C8QbaFgbCLGYpBskG7SoTOgbhhuYqqwJ9AB0JhoAgqECBsFABHLx1TAQIEbBg%2BGYbEwAdisAI26I2xEwBEWDFhPg2ACp8SwTABmVH/ZEAEQ4c1onAArLw/BwtKRUJw3NZrCDjstEWYyTxSARNHS5gBrECMjT6TiSFnijmcXgKEBysVsumkOCwJBoFgJOixciUQ3G%2BhxYBcMxcPh0AixdUQKLKqKhOo7Tgiw1sQQAeQYtG92tIWBYhmA4jD%2BCxVQAbph1WH3pUvE6fbwgZgGWHaHgosQvR4sMqCMQ8Cws3MqAZgAoAGp4TAAdwD%2B1ZIv4ghEYnYUhkgkUKnUYd09oMRhQPMs%2BkL6sgc1QCXyDBTAFoA2SNhvI0sEOTqQpJTsDJLMGrc5U1y4GO5PE09MEJsVSnpcqkBMM/PbP2vujfPp7VaNcOiGR8shA682gYcDxiKXo4hAsYfz0BQxkApCJDmBR%2BQHUUsRWHh6SZJUw05DhVAADgANg3WjJA2YBkGQDZbW%2BLgNggblLGsG5cEIO5zGFG4PCNE0ThErgZl4LUtDmCADVQCSrTNCALUklApxtSQNDlGhaCdYgXTdMMPWYYhQ19FT/QIIMQ2VCMoxjdk4xvPAkxTdk02QDNiOzQRc2VAsixLDAVnZCsqxrPh6ybFt207LMh2EURxEHHt5CUNRlV0AIdJnPi

Re: [edk2-devel] CpuDeadLoop() is optimized by compiler

[Andrew Fish via groups.io]

Whoops wrong compiler. Here is an update. I added the flags so this one 
reproduces the issue.

https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYTStJg1DIApACYAQuYukl9ZATwDKjdAGFUtAK4sGIM6SuADJ4DJgAcj4ARpjEINIADqgKhE4MHt6%2B/qRJKY4CIWGRLDFx0naYDmlCBEzEBBk%2BfgEVVQI1dQSFEdGx8ba19Y1ZLYNdoT0lfZIAlLaoXsTI7BwA9KsA1AAqAJ4JmBs7C8QbaFgbCLGYpBskG7SoTOgbhhuYqqwJ9AB0JhoAgqECBsFABHLx1TAQIEbBg%2BGYbEwAdisAI26I2xEwBEWDFhPg2ACp8SwTABmVH/ZEAEQ4c1onAArLw/BwtKRUJw3NZrCDjstEWYyTxSARNHS5gBrECMjT6TiSFnijmcXgKEBysVsumkOCwJBoFgJOixciUQ3G%2BhxYBcMxcPh0AixdUQKLKqKhOo7Tgiw1sQQAeQYtG92tIWBYhmA4jD%2BCxVQAbph1WH3pUvE6fbwgZgGWHaHgosQvR4sMqCMQ8Cws3MqAZgAoAGp4TAAdwD%2B1ZIv4ghEYnYUhkgkUKnUYd09oMRhQPMs%2BkL6sgc1QCXyDBTAFoA2SNhvI0sEOTqQpJTsDJLMGrc5U1y4GO5PE09MEJsVSnpcqkBMM/PbP2vujfPp7VaNcOiGR8shA682gYcDxiKXo4hAsYfz0BQxkApCJDmBR%2BQHUUsRWHh6SZJUw05DhVAADgANg3WjJA2YBkGQDZbW%2BLgNggblLGsG5cEIO5zGFG4PCNE0ThErgZl4LUtDmCADVQCSrTNCALUklApxtSQNDlGhaCdYgXTdMMPWYYhQ19FT/QIIMQ2VCMoxjdk4xvPAkxTdk02QDNiOzQRc2VAsixLDAVnZCsqxrPh6ybFt207LMh2EURxEHHt5CUNRlV0AIdJnPi51CxcIGXVc0k3bdd33ZBDzJY9T3PS9bBg28IFcND7RfRCpmQnJki/dJIN/Qa8jSLD%2BvQ9rqlQ0aZvsMDMNfbCUM6bqBk6Kb3xk%2BZFmWPQK0wALSI4ZlSFZdlKJo%2BjGNOHT2Mkb4NBe7jeKsOcNkEogpKFe0NnEy1YkFMkzFk0VxUUpB8CoKh1KyvsMukLKR1y/MEHVSdMdhqgCD2dg5WITHsmJhRcfx/YNTOi6rt4SjqTwOGNmbNsQduhimJYtiOK4hMFA2Dn7uQR6pBel65KhqUZTlPNFUu5VKLVbJ5IleUODMcjrtVSHtRmOYkxMtJ4iAA

Thanks,

Andrew Fish

> On May 18, 2023, at 11:45 AM, Andrew Fish via groups.io 
>  wrote:
> 
> Mike,
> 
> This is a good way to play around with fixes, and to report bugs. You can see 
> the assembler for different compilers with different flag. 
> 
> https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYTStJg1DIApACYAQuYukl9ZATwDKjdAGFUtAK4sGIM6SuADJ4DJgAcj4ARpjEINIADqgKhE4MHt6%2B/qRJKY4CIWGRLDFx0naYDmlCBEzEBBk%2BfgEVVQI1dQSFEdGx8ba19Y1ZLYNdoT0lfZIAlLaoXsTI7BwA9KsA1AAqAJ4JmBs7C8QbaFgbCLGYpBskG7SoTOgbhhuYqqwJ9AB0JhoAgqECBsFABHLx1TAQIEbBg%2BGYbEwAdisAI26I2xEwBEWDFhPg2ACp8SwTABmVH/ZEAEQ4c1onAArLw/BwtKRUJw3NZrCDjstEWYyTxSARNHS5gBrECMjT6TiSFnijmcXgKEBysVsumkOCwJBoFgJOixciUQ3G%2BhxYBcMxcPh0AixdUQKLKqKhOo7Tgiw1sQQAeQYtG92tIWBYhmA4jD%2BCxVQAbph1WH3pUvE6fbwgZgGWHaHgosQvR4sMqCMQ8Cws3MqAZgAoAGp4TAAdwD%2B1ZIv4ghEYnYUhkgkUKnUYd09oMRhQPMs%2BkL6sgc1QCXyDBTAFoA2SNhvI0sEOTqQpJTsDJLMGrc5U1y4GO5PE09MEJsVSnpcqkBMM/PbP2vujfPp7VaNcOiGR8shA682gYcDxiKXo4hAsYfz0BQxkApCJDmBR%2BQHUUsRWHh6SZJUw05DhVAADgANg3WjJA2YBkGQDZbW%2BLgNggblLGsG5cEIO5zGFG4PCNE0ThErgZl4LUtDmCADVQCSrTNCALUklApxtSQNDlGhaCdYgXTdMMPWYYhQ19FT/QIIMQ2VCMoxjdk4xvPAkxTdk02QDNiOzQRc2VAsixLDAVnZCsqxrPh6ybFt207LMh2EURxEHHt5CUNRlV0AIdJnPi51CxcIGXVc0k3bdd33ZBDzJY9T3PS9bBg28IFcND7RfRCpmQnJki/dJIN/Qa8jSLD%2BvQ9rqlQ0aZvsMDMNfbCUM6bqBk6Kb3xk%2BZFmWPQK0wALSI4ZlSFZdlKJo%2BjGNOHT2Mkb4NBe7jeKsOcNkEogpKFe0NnEy1YkFMkzFk0VxUUpB8CoKh1KyvsMukLKR1y/MEHVSdMdhqgCD2dg5WITHsmJhRcfx/YNTOi6rt4SjqTwOGNmbNsQduhimJYtiOK4hMFA2Dn7uQR6pBel65KhqUZTlPNFUu5VKLVbJ5IleUODMcjrtVSHtRmOYkxMtJ4iAA
> 
> Sorry I’m traveling and in Cupertino with lots of meetings so I did not have 
> time to adjust the compiler flags….
> 
> Thanks,
> 
> Andrew Fish
> 
>> On May 18, 2023, at 10:24 AM, Andrew (EFI) Fish  wrote:
>> 
>> Mike,
>> 
>> I guess my other question… If this turns out to be a compiler bug should we 
>> scope the change to the broken toolchain. I’m not sure what the right answer 
>> is for that, but I want to ask the question? 
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> On May 18, 2023, at 10:19 AM, Michael D Kinney  
>>> wrote:
>>> 
>>> Andrew,
>>>  
>>> This might work for XIP.  Set non const global to initial value that is 
>>> expected value to stay in dead loop.
>>>  
>>> UINTN  mDeadLoopCount = 0;
>>>  
>>> VOID
>>> CpuDeadLoop(
>>>   VOID
>>>   ) 
>>> {
>>>   while (mDeadLoopCount == 0) {
>>>   CpuPause();
>>>   }
>>> }
>>>  
>>> When deadloop is entered, developer can not change value of mDeadLoopCount, 
>>> but they can use debugger to force exit loop and return from function.
>>>  
>>> Mike
>>>  
>>>  
>>> From: Andrew (EFI) Fish mailto:af...@apple.com>> 
>>> Sent: Thursday, May 18, 2023 10:09 AM
>>> To: Kinney, Michael D >> <mailto:michael.d.kin...@intel.com>>
>>> Cc: edk2-devel-groups-io >> <mailto:devel@edk2.groups.io>>; Ni, Ray >> <mailto:ray...@intel.com>>; Rebecca Cran >> <mailto:rebe...@bsdio.com>>
>>> Subject: Re: [edk2-devel] CpuDeadLoop() is optimized by compiler
>>>  
>>> Mike,
>>>  
>>> Good point, that is why we a

Re: [edk2-devel] CpuDeadLoop() is optimized by compiler

[Andrew Fish via groups.io]

Mike,

This is a good way to play around with fixes, and to report bugs. You can see 
the assembler for different compilers with different flag. 

https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYTStJg1DIApACYAQuYukl9ZATwDKjdAGFUtAK4sGIM6SuADJ4DJgAcj4ARpjEINIADqgKhE4MHt6%2B/qRJKY4CIWGRLDFx0naYDmlCBEzEBBk%2BfgEVVQI1dQSFEdGx8ba19Y1ZLYNdoT0lfZIAlLaoXsTI7BwA9KsA1AAqAJ4JmBs7C8QbaFgbCLGYpBskG7SoTOgbhhuYqqwJ9AB0JhoAgqECBsFABHLx1TAQIEbBg%2BGYbEwAdisAI26I2xEwBEWDFhPg2ACp8SwTABmVH/ZEAEQ4c1onAArLw/BwtKRUJw3NZrCDjstEWYyTxSARNHS5gBrECMjT6TiSFnijmcXgKEBysVsumkOCwJBoFgJOixciUQ3G%2BhxYBcMxcPh0AixdUQKLKqKhOo7Tgiw1sQQAeQYtG92tIWBYhmA4jD%2BCxVQAbph1WH3pUvE6fbwgZgGWHaHgosQvR4sMqCMQ8Cws3MqAZgAoAGp4TAAdwD%2B1ZIv4ghEYnYUhkgkUKnUYd09oMRhQPMs%2BkL6sgc1QCXyDBTAFoA2SNhvI0sEOTqQpJTsDJLMGrc5U1y4GO5PE09MEJsVSnpcqkBMM/PbP2vujfPp7VaNcOiGR8shA682gYcDxiKXo4hAsYfz0BQxkApCJDmBR%2BQHUUsRWHh6SZJUw05DhVAADgANg3WjJA2YBkGQDZbW%2BLgNggblLGsG5cEIO5zGFG4PCNE0ThErgZl4LUtDmCADVQCSrTNCALUklApxtSQNDlGhaCdYgXTdMMPWYYhQ19FT/QIIMQ2VCMoxjdk4xvPAkxTdk02QDNiOzQRc2VAsixLDAVnZCsqxrPh6ybFt207LMh2EURxEHHt5CUNRlV0AIdJnPi51CxcIGXVc0k3bdd33ZBDzJY9T3PS9bBg28IFcND7RfRCpmQnJki/dJIN/Qa8jSLD%2BvQ9rqlQ0aZvsMDMNfbCUM6bqBk6Kb3xk%2BZFmWPQK0wALSI4ZlSFZdlKJo%2BjGNOHT2Mkb4NBe7jeKsOcNkEogpKFe0NnEy1YkFMkzFk0VxUUpB8CoKh1KyvsMukLKR1y/MEHVSdMdhqgCD2dg5WITHsmJhRcfx/YNTOi6rt4SjqTwOGNmbNsQduhimJYtiOK4hMFA2Dn7uQR6pBel65KhqUZTlPNFUu5VKLVbJ5IleUODMcjrtVSHtRmOYkxMtJ4iAA

Sorry I’m traveling and in Cupertino with lots of meetings so I did not have 
time to adjust the compiler flags….

Thanks,

Andrew Fish

> On May 18, 2023, at 10:24 AM, Andrew (EFI) Fish  wrote:
> 
> Mike,
> 
> I guess my other question… If this turns out to be a compiler bug should we 
> scope the change to the broken toolchain. I’m not sure what the right answer 
> is for that, but I want to ask the question? 
> 
> Thanks,
> 
> Andrew Fish
> 
>> On May 18, 2023, at 10:19 AM, Michael D Kinney  
>> wrote:
>> 
>> Andrew,
>>  
>> This might work for XIP.  Set non const global to initial value that is 
>> expected value to stay in dead loop.
>>  
>> UINTN  mDeadLoopCount = 0;
>>  
>> VOID
>> CpuDeadLoop(
>>   VOID
>>   ) 
>> {
>>   while (mDeadLoopCount == 0) {
>>   CpuPause();
>>   }
>> }
>>  
>> When deadloop is entered, developer can not change value of mDeadLoopCount, 
>> but they can use debugger to force exit loop and return from function.
>>  
>> Mike
>>  
>>  
>> From: Andrew (EFI) Fish mailto:af...@apple.com>> 
>> Sent: Thursday, May 18, 2023 10:09 AM
>> To: Kinney, Michael D > >
>> Cc: edk2-devel-groups-io > >; Ni, Ray > >; Rebecca Cran > >
>> Subject: Re: [edk2-devel] CpuDeadLoop() is optimized by compiler
>>  
>> Mike,
>>  
>> Good point, that is why we are using the stack ….
>>  
>> The only other thing I can think of is to pass the address of Index to some 
>> inline assembler, or an asm no op function, to give it a side effect the 
>> compiler can’t resolve. 
>>  
>> Thanks,
>>  
>> Andrew Fish
>> 
>> 
>> On May 18, 2023, at 10:05 AM, Kinney, Michael D > > wrote:
>>  
>> Static global will not work for XIP
>>  
>> Mike
>>  
>> From: Andrew (EFI) Fish mailto:af...@apple.com>> 
>> Sent: Thursday, May 18, 2023 9:49 AM
>> To: edk2-devel-groups-io > >; Kinney, Michael D 
>> mailto:michael.d.kin...@intel.com>>
>> Cc: Ni, Ray mailto:ray...@intel.com>>; Rebecca Cran 
>> mailto:rebe...@bsdio.com>>
>> Subject: Re: [edk2-devel] CpuDeadLoop() is optimized by compiler
>>  
>> Mike,
>>  
>> I pinged some compiler experts to see if our code is correct, or if the 
>> compiler has an issue. Seems to be trending compiler issue right now, but 
>> I’ve NOT gotten feedback from anyone on the spec committee yet. 
>>  
>> If we move Index to a static global that would likely work around the 
>> compiler issue.
>>  
>> Thanks,
>>  
>> Andrew Fish
>> 
>> 
>> 
>> On May 18, 2023, at 8:36 AM, Michael D Kinney > > wrote:
>>  
>> Hi Ray,
>>  
>> So the code generated does deadloop, but is just not easy to resume from as 
>> we have been able to do in the past.
>>  
>> We use CpuDeadloop() for 2 purposes.  One is a terminal condition with no 
>> reason to ever continue.
>>  
>> The 2nd is a debug aide for developers to halt the system at a specific 
>> location and then continue from that point, usually with a debugger, to step 
>> through code to an area to evaluate unexpected behavior.
>>  
>> We may have to do a NASM implementation of CpuDeadloop() to make sure it 
>> meets both use cases.
>>  
>> Mike
>>  
>> From: Ni, Ray mailto:ray...@intel.com>> 
>> Sent: Thursday, May 18, 2023 3:00 AM
>> To: devel@edk2.groups.io 
>> Cc: Kinney, Michael D > >; Rebecca Cran > 

Re: [edk2-devel] CpuDeadLoop() is optimized by compiler

[Andrew Fish via groups.io]

Rebecca,

It looks like VC++ is trying to honor the volatile by reading the variable, 
incase that has side effects. But the loop is not checking the value of the 
variable and it is just doing an unconditional jump. This is why I think it is 
likely a compiler bug. Since the compiler emitted a hard code jmp in a loop it 
optimized out the return instruction….

$LN10@CpuDeadLoo:
mov   rax, QWORD PTR Index$[rsp]
call  CpuPause
jmp   SHORT $LN10@CpuDeadLoo
….

So changing the variable does not break you out of the loop. If you pc += 2 
when you are at the jmp instruction that will not return you from CpuDeadLoop() 
that will just fall into the next function. That might work if CpuDeadLoop() 
was inlined, but if it was a call you would start running the next function in 
the binary. 

Thanks,

Andrew Fish


> On May 18, 2023, at 10:36 AM, Rebecca Cran  wrote:
> 
> When I use CpuDeadLoop for debugging on Aarch64 I have symbols loaded so I 
> can just do ‘set Index=1’ and resume, but it sounds like the issue is that 
> people want to sometimes debug without symbols/source, and the generated 
> assembly is making that difficult.
> 
> Rebecca
> 
> On Thu, May 18, 2023, at 9:36 AM, Michael D Kinney wrote:
>> Hi Ray,
>> 
>> So the code generated does deadloop, but is just not easy to resume 
>> from as we have been able to do in the past.
>> 
>> We use CpuDeadloop() for 2 purposes.  One is a terminal condition with 
>> no reason to ever continue.
>> 
>> The 2nd is a debug aide for developers to halt the system at a specific 
>> location and then continue from that point, usually with a debugger, to 
>> step through code to an area to evaluate unexpected behavior.
>> 
>> We may have to do a NASM implementation of CpuDeadloop() to make sure 
>> it meets both use cases.
>> 
>> Mike
>> 
>> *From:* Ni, Ray  
>> *Sent:* Thursday, May 18, 2023 3:00 AM
>> *To:* devel@edk2.groups.io
>> *Cc:* Kinney, Michael D ; Rebecca Cran 
>> ; Ni, Ray 
>> *Subject:* CpuDeadLoop() is optimized by compiler
>> 
>> Hi,
>> Starting from certain version of Visual Studio C compiler (I don’t have 
>> the exact version. I am using VS2019), CpuDeadLoop is now optimized 
>> quite well by compiler.
>> 
>> The optimization is so “good” that it becomes harder for developers to 
>> break out of the deadloop.
>> 
>> I copied the assembly instructions as below for your reference.
>> The compiler does not generate instructions that jump out of the loop 
>> when the Index is not zero.
>> So in order to break out of the loop, developers need to:
>> 1. Manually adjust rsp by increasing 40
>> 2. Manually “ret”
>> 
>> I am not sure if anyone has interest to re-write this function so that 
>> compiler can be “fooled” again.
>> Thanks,
>> Ray
>> 
>> ===
>> ; Function compile flags: /Ogspy
>> ; File e:\work\edk2\MdePkg\Library\BaseLib\CpuDeadLoop.c
>> ;  COMDAT CpuDeadLoop
>> _TEXTSEGMENT
>> Index$ = 48
>> CpuDeadLoop PROC
>>; COMDAT
>> 
>> ; 26   : {
>> 
>> $LN12:
>>  0  48 83 ec 28 subrsp, 40 
>>   ; 0028H
>> 
>> ; 27   :   volatile UINTN  Index;
>> ; 28   : 
>> ; 29   :   for (Index = 0; Index == 0;) {
>> 
>>  4  48 c7 44 24 30
>>   00 00 00 00mov  QWORD PTR Index$[rsp], 0
>> $LN10@CpuDeadLoo:
>> 
>> ; 30   : CpuPause ();
>> 
>>  d  48 8b 44 24 30   mov  rax, QWORD PTR Index$[rsp]
>>  00012  e8 00 00 00 00   callCpuPause
>>  00017  eb f4 jmp   SHORT $LN10@CpuDeadLoo
>> CpuDeadLoop ENDP
>> _TEXTENDS
>> END
>> 
>> 
>> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105047): https://edk2.groups.io/g/devel/message/105047
Mute This Topic: https://groups.io/mt/98987896/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] CpuDeadLoop() is optimized by compiler

[Andrew Fish via groups.io]

Mike,

I guess my other question… If this turns out to be a compiler bug should we 
scope the change to the broken toolchain. I’m not sure what the right answer is 
for that, but I want to ask the question? 

Thanks,

Andrew Fish

> On May 18, 2023, at 10:19 AM, Michael D Kinney  
> wrote:
> 
> Andrew,
>  
> This might work for XIP.  Set non const global to initial value that is 
> expected value to stay in dead loop.
>  
> UINTN  mDeadLoopCount = 0;
>  
> VOID
> CpuDeadLoop(
>   VOID
>   ) 
> {
>   while (mDeadLoopCount == 0) {
>   CpuPause();
>   }
> }
>  
> When deadloop is entered, developer can not change value of mDeadLoopCount, 
> but they can use debugger to force exit loop and return from function.
>  
> Mike
>  
>  
> From: Andrew (EFI) Fish mailto:af...@apple.com>> 
> Sent: Thursday, May 18, 2023 10:09 AM
> To: Kinney, Michael D  >
> Cc: edk2-devel-groups-io  >; Ni, Ray  >; Rebecca Cran  >
> Subject: Re: [edk2-devel] CpuDeadLoop() is optimized by compiler
>  
> Mike,
>  
> Good point, that is why we are using the stack ….
>  
> The only other thing I can think of is to pass the address of Index to some 
> inline assembler, or an asm no op function, to give it a side effect the 
> compiler can’t resolve. 
>  
> Thanks,
>  
> Andrew Fish
> 
> 
> On May 18, 2023, at 10:05 AM, Kinney, Michael D  > wrote:
>  
> Static global will not work for XIP
>  
> Mike
>  
> From: Andrew (EFI) Fish mailto:af...@apple.com>> 
> Sent: Thursday, May 18, 2023 9:49 AM
> To: edk2-devel-groups-io  >; Kinney, Michael D  >
> Cc: Ni, Ray mailto:ray...@intel.com>>; Rebecca Cran 
> mailto:rebe...@bsdio.com>>
> Subject: Re: [edk2-devel] CpuDeadLoop() is optimized by compiler
>  
> Mike,
>  
> I pinged some compiler experts to see if our code is correct, or if the 
> compiler has an issue. Seems to be trending compiler issue right now, but 
> I’ve NOT gotten feedback from anyone on the spec committee yet. 
>  
> If we move Index to a static global that would likely work around the 
> compiler issue.
>  
> Thanks,
>  
> Andrew Fish
> 
> 
> 
> On May 18, 2023, at 8:36 AM, Michael D Kinney  > wrote:
>  
> Hi Ray,
>  
> So the code generated does deadloop, but is just not easy to resume from as 
> we have been able to do in the past.
>  
> We use CpuDeadloop() for 2 purposes.  One is a terminal condition with no 
> reason to ever continue.
>  
> The 2nd is a debug aide for developers to halt the system at a specific 
> location and then continue from that point, usually with a debugger, to step 
> through code to an area to evaluate unexpected behavior.
>  
> We may have to do a NASM implementation of CpuDeadloop() to make sure it 
> meets both use cases.
>  
> Mike
>  
> From: Ni, Ray mailto:ray...@intel.com>> 
> Sent: Thursday, May 18, 2023 3:00 AM
> To: devel@edk2.groups.io 
> Cc: Kinney, Michael D  >; Rebecca Cran  >; Ni, Ray  >
> Subject: CpuDeadLoop() is optimized by compiler
>  
> Hi,
> Starting from certain version of Visual Studio C compiler (I don’t have the 
> exact version. I am using VS2019), CpuDeadLoop is now optimized quite well by 
> compiler.
>  
> The optimization is so “good” that it becomes harder for developers to break 
> out of the deadloop.
>  
> I copied the assembly instructions as below for your reference.
> The compiler does not generate instructions that jump out of the loop when 
> the Index is not zero.
> So in order to break out of the loop, developers need to:
> Manually adjust rsp by increasing 40
> Manually “ret”
>  
> I am not sure if anyone has interest to re-write this function so that 
> compiler can be “fooled” again.
> Thanks,
> Ray
>  
> ===
> ; Function compile flags: /Ogspy
> ; File e:\work\edk2\MdePkg\Library\BaseLib\CpuDeadLoop.c
> ;  COMDAT CpuDeadLoop
> _TEXTSEGMENT
> Index$ = 48
> CpuDeadLoop PROC  
>   ; COMDAT
>  
> ; 26   : {
>  
> $LN12:
>   0  48 83 ec 28 subrsp, 40   
>  ; 0028H
>  
> ; 27   :   volatile UINTN  Index;
> ; 28   : 
> ; 29   :   for (Index = 0; Index == 0;) {
>  
>   4  48 c7 44 24 30
>00 00 00 00mov  QWORD PTR Index$[rsp], 0
> $LN10@CpuDeadLoo:
>  
> ; 30   : CpuPause ();
>  
>   d  48 8b 44 24 30   mov  rax, QWORD PTR Index$[rsp]
>   00012  e8 00 00 00 00   callCpuPause
>   00017  eb f4 jmp   SHORT $LN10@CpuDeadLoo
> CpuDeadLoop ENDP
> _TEXTENDS
> END
>  
>  
>  
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online 

Re: [edk2-devel] CpuDeadLoop() is optimized by compiler

[Andrew Fish via groups.io]

Yea,  but I think you want static and volatile on the global. But good idea as 
for the non XIP case you can just modify the global. It might be a good idea to 
document the debugging flow in the header for CpuDeadLoop()...

Thanks,

Andrew Fish

> On May 18, 2023, at 10:19 AM, Kinney, Michael D  
> wrote:
> 
> Andrew,
>  
> This might work for XIP.  Set non const global to initial value that is 
> expected value to stay in dead loop.
>  
> UINTN  mDeadLoopCount = 0;
>  
> VOID
> CpuDeadLoop(
>   VOID
>   ) 
> {
>   while (mDeadLoopCount == 0) {
>   CpuPause();
>   }
> }
>  
> When deadloop is entered, developer can not change value of mDeadLoopCount, 
> but they can use debugger to force exit loop and return from function.
>  
> Mike
>  
>  
> From: Andrew (EFI) Fish  
> Sent: Thursday, May 18, 2023 10:09 AM
> To: Kinney, Michael D 
> Cc: edk2-devel-groups-io ; Ni, Ray ; 
> Rebecca Cran 
> Subject: Re: [edk2-devel] CpuDeadLoop() is optimized by compiler
>  
> Mike,
>  
> Good point, that is why we are using the stack ….
>  
> The only other thing I can think of is to pass the address of Index to some 
> inline assembler, or an asm no op function, to give it a side effect the 
> compiler can’t resolve. 
>  
> Thanks,
>  
> Andrew Fish
> 
> 
> On May 18, 2023, at 10:05 AM, Kinney, Michael D  > wrote:
>  
> Static global will not work for XIP
>  
> Mike
>  
> From: Andrew (EFI) Fish mailto:af...@apple.com>> 
> Sent: Thursday, May 18, 2023 9:49 AM
> To: edk2-devel-groups-io  >; Kinney, Michael D  >
> Cc: Ni, Ray mailto:ray...@intel.com>>; Rebecca Cran 
> mailto:rebe...@bsdio.com>>
> Subject: Re: [edk2-devel] CpuDeadLoop() is optimized by compiler
>  
> Mike,
>  
> I pinged some compiler experts to see if our code is correct, or if the 
> compiler has an issue. Seems to be trending compiler issue right now, but 
> I’ve NOT gotten feedback from anyone on the spec committee yet. 
>  
> If we move Index to a static global that would likely work around the 
> compiler issue.
>  
> Thanks,
>  
> Andrew Fish
> 
> 
> 
> On May 18, 2023, at 8:36 AM, Michael D Kinney  > wrote:
>  
> Hi Ray,
>  
> So the code generated does deadloop, but is just not easy to resume from as 
> we have been able to do in the past.
>  
> We use CpuDeadloop() for 2 purposes.  One is a terminal condition with no 
> reason to ever continue.
>  
> The 2nd is a debug aide for developers to halt the system at a specific 
> location and then continue from that point, usually with a debugger, to step 
> through code to an area to evaluate unexpected behavior.
>  
> We may have to do a NASM implementation of CpuDeadloop() to make sure it 
> meets both use cases.
>  
> Mike
>  
> From: Ni, Ray mailto:ray...@intel.com>> 
> Sent: Thursday, May 18, 2023 3:00 AM
> To: devel@edk2.groups.io 
> Cc: Kinney, Michael D  >; Rebecca Cran  >; Ni, Ray  >
> Subject: CpuDeadLoop() is optimized by compiler
>  
> Hi,
> Starting from certain version of Visual Studio C compiler (I don’t have the 
> exact version. I am using VS2019), CpuDeadLoop is now optimized quite well by 
> compiler.
>  
> The optimization is so “good” that it becomes harder for developers to break 
> out of the deadloop.
>  
> I copied the assembly instructions as below for your reference.
> The compiler does not generate instructions that jump out of the loop when 
> the Index is not zero.
> So in order to break out of the loop, developers need to:
> Manually adjust rsp by increasing 40
> Manually “ret”
>  
> I am not sure if anyone has interest to re-write this function so that 
> compiler can be “fooled” again.
> Thanks,
> Ray
>  
> ===
> ; Function compile flags: /Ogspy
> ; File e:\work\edk2\MdePkg\Library\BaseLib\CpuDeadLoop.c
> ;  COMDAT CpuDeadLoop
> _TEXTSEGMENT
> Index$ = 48
> CpuDeadLoop PROC  
>   ; COMDAT
>  
> ; 26   : {
>  
> $LN12:
>   0  48 83 ec 28 subrsp, 40   
>  ; 0028H
>  
> ; 27   :   volatile UINTN  Index;
> ; 28   : 
> ; 29   :   for (Index = 0; Index == 0;) {
>  
>   4  48 c7 44 24 30
>00 00 00 00mov  QWORD PTR Index$[rsp], 0
> $LN10@CpuDeadLoo:
>  
> ; 30   : CpuPause ();
>  
>   d  48 8b 44 24 30   mov  rax, QWORD PTR Index$[rsp]
>   00012  e8 00 00 00 00   callCpuPause
>   00017  eb f4 jmp   SHORT $LN10@CpuDeadLoo
> CpuDeadLoop ENDP
> _TEXTENDS
> END
>  
>  
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105043): https://edk2.groups.io/g/devel/message/105043
Mute This Topic: https://groups.io/mt/98987896/21656
Group Owner: 

Re: [edk2-devel] CpuDeadLoop() is optimized by compiler

[Andrew Fish via groups.io]

Mike,

Good point, that is why we are using the stack ….

The only other thing I can think of is to pass the address of Index to some 
inline assembler, or an asm no op function, to give it a side effect the 
compiler can’t resolve. 

Thanks,

Andrew Fish

> On May 18, 2023, at 10:05 AM, Kinney, Michael D  
> wrote:
> 
> Static global will not work for XIP
>  
> Mike
>  
> From: Andrew (EFI) Fish  
> Sent: Thursday, May 18, 2023 9:49 AM
> To: edk2-devel-groups-io ; Kinney, Michael D 
> 
> Cc: Ni, Ray ; Rebecca Cran 
> Subject: Re: [edk2-devel] CpuDeadLoop() is optimized by compiler
>  
> Mike,
>  
> I pinged some compiler experts to see if our code is correct, or if the 
> compiler has an issue. Seems to be trending compiler issue right now, but 
> I’ve NOT gotten feedback from anyone on the spec committee yet. 
>  
> If we move Index to a static global that would likely work around the 
> compiler issue.
>  
> Thanks,
>  
> Andrew Fish
> 
> 
> On May 18, 2023, at 8:36 AM, Michael D Kinney  > wrote:
>  
> Hi Ray,
>  
> So the code generated does deadloop, but is just not easy to resume from as 
> we have been able to do in the past.
>  
> We use CpuDeadloop() for 2 purposes.  One is a terminal condition with no 
> reason to ever continue.
>  
> The 2nd is a debug aide for developers to halt the system at a specific 
> location and then continue from that point, usually with a debugger, to step 
> through code to an area to evaluate unexpected behavior.
>  
> We may have to do a NASM implementation of CpuDeadloop() to make sure it 
> meets both use cases.
>  
> Mike
>  
> From: Ni, Ray mailto:ray...@intel.com>> 
> Sent: Thursday, May 18, 2023 3:00 AM
> To: devel@edk2.groups.io 
> Cc: Kinney, Michael D  >; Rebecca Cran  >; Ni, Ray  >
> Subject: CpuDeadLoop() is optimized by compiler
>  
> Hi,
> Starting from certain version of Visual Studio C compiler (I don’t have the 
> exact version. I am using VS2019), CpuDeadLoop is now optimized quite well by 
> compiler.
>  
> The optimization is so “good” that it becomes harder for developers to break 
> out of the deadloop.
>  
> I copied the assembly instructions as below for your reference.
> The compiler does not generate instructions that jump out of the loop when 
> the Index is not zero.
> So in order to break out of the loop, developers need to:
> Manually adjust rsp by increasing 40
> Manually “ret”
>  
> I am not sure if anyone has interest to re-write this function so that 
> compiler can be “fooled” again.
> Thanks,
> Ray
>  
> ===
> ; Function compile flags: /Ogspy
> ; File e:\work\edk2\MdePkg\Library\BaseLib\CpuDeadLoop.c
> ;  COMDAT CpuDeadLoop
> _TEXTSEGMENT
> Index$ = 48
> CpuDeadLoop PROC  
>   ; COMDAT
>  
> ; 26   : {
>  
> $LN12:
>   0  48 83 ec 28 subrsp, 40   
>  ; 0028H
>  
> ; 27   :   volatile UINTN  Index;
> ; 28   : 
> ; 29   :   for (Index = 0; Index == 0;) {
>  
>   4  48 c7 44 24 30
>00 00 00 00mov  QWORD PTR Index$[rsp], 0
> $LN10@CpuDeadLoo:
>  
> ; 30   : CpuPause ();
>  
>   d  48 8b 44 24 30   mov  rax, QWORD PTR Index$[rsp]
>   00012  e8 00 00 00 00   callCpuPause
>   00017  eb f4 jmp   SHORT $LN10@CpuDeadLoo
> CpuDeadLoop ENDP
> _TEXTENDS
> END
>  
>  
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105041): https://edk2.groups.io/g/devel/message/105041
Mute This Topic: https://groups.io/mt/98987896/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] CpuDeadLoop() is optimized by compiler

[Andrew Fish via groups.io]

Mike,

I pinged some compiler experts to see if our code is correct, or if the 
compiler has an issue. Seems to be trending compiler issue right now, but I’ve 
NOT gotten feedback from anyone on the spec committee yet. 

If we move Index to a static global that would likely work around the compiler 
issue.

Thanks,

Andrew Fish

> On May 18, 2023, at 8:36 AM, Michael D Kinney  
> wrote:
> 
> Hi Ray,
>  
> So the code generated does deadloop, but is just not easy to resume from as 
> we have been able to do in the past.
>  
> We use CpuDeadloop() for 2 purposes.  One is a terminal condition with no 
> reason to ever continue.
>  
> The 2nd is a debug aide for developers to halt the system at a specific 
> location and then continue from that point, usually with a debugger, to step 
> through code to an area to evaluate unexpected behavior.
>  
> We may have to do a NASM implementation of CpuDeadloop() to make sure it 
> meets both use cases.
>  
> Mike
>  
> From: Ni, Ray mailto:ray...@intel.com>> 
> Sent: Thursday, May 18, 2023 3:00 AM
> To: devel@edk2.groups.io 
> Cc: Kinney, Michael D  >; Rebecca Cran  >; Ni, Ray  >
> Subject: CpuDeadLoop() is optimized by compiler
>  
> Hi,
> Starting from certain version of Visual Studio C compiler (I don’t have the 
> exact version. I am using VS2019), CpuDeadLoop is now optimized quite well by 
> compiler.
>  
> The optimization is so “good” that it becomes harder for developers to break 
> out of the deadloop.
>  
> I copied the assembly instructions as below for your reference.
> The compiler does not generate instructions that jump out of the loop when 
> the Index is not zero.
> So in order to break out of the loop, developers need to:
> Manually adjust rsp by increasing 40
> Manually “ret”
>  
> I am not sure if anyone has interest to re-write this function so that 
> compiler can be “fooled” again.
> Thanks,
> Ray
>  
> ===
> ; Function compile flags: /Ogspy
> ; File e:\work\edk2\MdePkg\Library\BaseLib\CpuDeadLoop.c
> ;  COMDAT CpuDeadLoop
> _TEXTSEGMENT
> Index$ = 48
> CpuDeadLoop PROC  
>   ; COMDAT
>  
> ; 26   : {
>  
> $LN12:
>   0  48 83 ec 28 subrsp, 40   
>  ; 0028H
>  
> ; 27   :   volatile UINTN  Index;
> ; 28   : 
> ; 29   :   for (Index = 0; Index == 0;) {
>  
>   4  48 c7 44 24 30
>00 00 00 00mov  QWORD PTR Index$[rsp], 0
> $LN10@CpuDeadLoo:
>  
> ; 30   : CpuPause ();
>  
>   d  48 8b 44 24 30   mov  rax, QWORD PTR Index$[rsp]
>   00012  e8 00 00 00 00   callCpuPause
>   00017  eb f4 jmp   SHORT $LN10@CpuDeadLoo
> CpuDeadLoop ENDP
> _TEXTENDS
> END
>  
>  
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105039): https://edk2.groups.io/g/devel/message/105039
Mute This Topic: https://groups.io/mt/98987896/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Building error

[Andrew Fish via groups.io]

In the WmiAwcc.asl file it looks like the 1109th byte has some invalid UTF-8 
encoding. So it looks like the file got edited with an editor that us using an 
encoding other than ASCII or UTF-8?

Thanks,

Andrew Fish

> On May 18, 2023, at 1:43 AM, Eva.Ss.Feng (ńTÉșÉș)  
> wrote:
> 
> HI Devel
> I have a little question that I need to ask for you. When I was building the 
> code, the following error occurred. The error message tells me to email you 
> for help. The branch I build can be compiled on someone else's computer, but 
> it cannot be compiled successfully on my computer. I tried checking out to 
> another branch and it was successful. I don't understand the reason for the 
> moment, so I sent you an email with the error message attached to the error 
> message.
>  
> 
>  
> Eva 馮珊珊
> Foxconn Technology Group-
> PCEBG-DTSA/R/DPD/FWOD
> Tel：63150/13307169381
> Teams: eva.ss.f...@foxconn.com 
> mail:eva.ss.f...@foxconn.com 
> UC: shanshan.f...@foxconn.net 
> 
>  
> ⌘---
> 
> 本電子郵件及附件所載之信息為保密信息，其内容僅供指定收件人使用。上述信息為發表人之個人意見，並不代表本公司之立場。若您因為誤傳而收到本郵件，請立即以郵件通知寄件人，並將本郵件删除。禁止將本郵件及附件複製、散佈或洩露給任何第三者。本郵件經由網路傳遞，有可能遭竄改或病毒之入侵。為確保資訊之安全，收件人請就本郵件及附件之重要内容，與寄件人進行確認。
> 
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Hon Hai/Foxconn. If you have received it by mistake, 
> please inform the sender by an email reply and then delete the message. It is 
> forbidden to copy, forward, or in any way reveal the contents of this message 
> to anyone. The integrity and security of this email cannot be guaranteed over 
> the Internet. Therefore, it's advised for the receiver to verify the validity 
> of this message with the sender.
> 
> ---⌘
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105035): https://edk2.groups.io/g/devel/message/105035
Mute This Topic: https://groups.io/mt/98993280/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] DSC nightmare

[Andrew Fish via groups.io]

Ben,

I’d say the tools are optimized to be general purpose. So they are not really 
designed to be the easy button.

In terms of things like SEC/PEI or DXE it is very common for this code on x86 
to be compiled for different architectures. SEC/PEI is usually i386 and DXE is 
x86_64. Crazy I know but historically on x86 you can’t be in 64-bit mode 
without paging being enabled, and you can’t (legally) put page tables in ROM. 
So the early code at the reset vector (SEC) and the code to turn on memory 
(PEI) is 32-bit i386. PEI got a lot bigger than we envisioned mainly due to it 
taking a PhD in antenna design to turn on memory on an Intel chipset. Then all 
the power on engineers got good at writing PEI code and moved more code to PEI, 
but I digress….

OK let us leave behind binary compatibility and talk about the different 
contracts that exist in the different phases. For example how to allocate 
memory. There is no standard way in SEC (People use PHIT HOB), there is a PEI 
specific API[1], and a DXE/UEFI specific API[2]. So you can end up with 
different instances of the same library API coded with the same API, but 
implemented differently. This was a conscious choice on our part to make it 
much easier to port code between the different worlds. We also support the 
concept of multiple instances of a give library that use different hardware, or 
are optimized for different things. For example we have some libs that produce 
our version of memcpy etc that have different instances for PEI[3] and DXE[4]. 
Seems when you are running from ROM vs. running from memory the optimal 
optimization schemes are different. Thus we give the user a lot of power over 
which instance of a library they can pick. When you need it, it is very handy. 
You also don’t have other people randomly changing the rules on you, which can 
be important for things like security reviews etc. 

So a little lingo sometimes helps. A library class is the contract, or the 
header file that defines the public interface for the library. The library 
instance is the implementation, as I mentioned above there can be more than one 
for many reasons. Base means the code does not depend on any of the boot 
phases. SEC/PEI/DXE etc are phases defined by the UEFI PI Spec [1].

I guess we could try to combine libraries of different phases together to 
simplify things, but at this point we have lots of customers with (as you point 
out) complex DSC files that would all break if we refactored the libs. So kind 
of makes fixing things a little harder. 

In terms of tips I find it I useful to use a little git foo to find instances 
of libraries. The library INF file defines which library class the library 
implements so you can filter by LIBRARY_CLASS to get the instances 
(implementations) of a given library class. 

/Volumes/Case/edk2(master)>git grep BaseMemoryLib -- \*.inf | grep LIBRARY_CLASS
MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf:20:  LIBRARY_CLASS   
   = BaseMemoryLib
MdePkg/Library/BaseMemoryLibMmx/BaseMemoryLibMmx.inf:21:  LIBRARY_CLASS 
 = BaseMemoryLib
MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf:21:  LIBRARY_CLASS   
   = BaseMemoryLib
MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf:79:  LIBRARY_CLASS = 
BaseMemoryLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER UEFI_DRIVER 
UEFI_APPLICATION
MdePkg/Library/BaseMemoryLibOptPei/BaseMemoryLibOptPei.inf:21:  LIBRARY_CLASS   
   = BaseMemoryLib
MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf:21:  LIBRARY_CLASS   
   = BaseMemoryLib
MdePkg/Library/BaseMemoryLibSse2/BaseMemoryLibSse2.inf:20:  LIBRARY_CLASS   
   = BaseMemoryLib
MdePkg/Library/PeiMemoryLib/PeiMemoryLib.inf:21:  LIBRARY_CLASS 
 = BaseMemoryLib|PEIM
MdePkg/Library/UefiMemoryLib/UefiMemoryLib.inf:21:  LIBRARY_CLASS   
   = BaseMemoryLib|DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SMM_DRIVER 
UEFI_APPLICATION UEFI_DRIVER

/Volumes/Case/edk2(master)>git grep SerialPortLib  -- \*.inf | grep 
LIBRARY_CLASS
ArmPkg/Library/SemiHostingSerialPortLib/SemiHostingSerialPortLib.inf:17:  
LIBRARY_CLASS  = SerialPortLib
ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf:17:  
LIBRARY_CLASS  = SerialPortLib
ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.inf:17:  
LIBRARY_CLASS  = SerialPortLib|SEC PEI_CORE PEIM
ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.inf:17:  
LIBRARY_CLASS  = SerialPortLib|DXE_CORE DXE_DRIVER UEFI_DRIVER 
DXE_RUNTIME_DRIVER UEFI_APPLICATION
EmulatorPkg/Library/DxeEmuSerialPortLib/DxeEmuSerialPortLib.inf:18:  
LIBRARY_CLASS  = SerialPortLib| DXE_CORE DXE_DRIVER 
DXE_RUNTIME_DRIVER DXE_SMM_DRIVER SMM_CORE UEFI_APPLICATION UEFI_DRIVE
EmulatorPkg/Library/DxeEmuStdErrSerialPortLib/DxeEmuStdErrSerialPortLib.inf:18: 
 LIBRARY_CLASS  = SerialPortLib| DXE_CORE 

Re: [edk2-devel] regarding calling UEFI runtime services (mainly SetVariable) from linux or android OS which is running on xen+tianocore UEFI

[Andrew Fish via groups.io]

> On Feb 6, 2023, at 10:25 AM, ritul guru  wrote:
> 
> Thanks,
> so as it is memory, does it mean if anything written in variable store, and 
> VM reboot happens then variable store will be flushed?
> 

It looks like it is saved if you do an S3. S3 is ACPI speak for a sleep state 
that puts RAM into self refresh. On a cold boot it allocates the memory, so you 
are starting over.

Sorry I’ve never looked at the Xen code before so I’m sight reading.

Thanks,

Andrew Fish

> Thanks & Regards
> Ritul Guru
> +91-9916513186
> 
> 
> On Mon, Feb 6, 2023 at 11:47 PM Andrew (EFI) Fish  > wrote:
>> 
>> 
>>> On Feb 6, 2023, at 8:06 AM, ritul guru >> > wrote:
>>> 
>>> Hi,
>>> 
>>> I have been using xen hypervisor and tianocore uefi BIOS on xen to boot to 
>>> ubuntu OS on virtualized disk.
>>> and want to set a UEFI variable with UEFI runtime service SetVariable() to 
>>> a value and the same wants to read from UEFI bootloader either grubx64.efi 
>>> or botmgfw.efi,
>>> So, Is it possible to use runtime services to do such an operation for OS 
>>> running on VM when booted with OVMF/tianocore BIOS on VM guest? 
>>> If so, where does this variable gets stored? is it in some virtualized disk 
>>> as there is no virtualized SPIROM available to VM.
>>> 
>>> 
>> 
>> I don’t know the Xen specifics, but the firmware maps in a Flash Device (FD) 
>> here:
>> 
>> 
>> edk2/OvmfXen.fdf at master · tianocore/edk2
>> github.com
>>  
>> edk2/OvmfXen.fdf
>>  at master · tianocore/edk2 
>> 
>> github.com 
>> 
>> 
>> Oh looks like it uses an emulated variable store that is just memory. See 
>> ReserveEmuVariableNvStore().
>> 
>> 
>> edk2/Platform.c at master · tianocore/edk2
>> github.com
>>  
>> edk2/Platform.c
>>  at master · tianocore/edk2 
>> 
>> github.com 
>> 
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> 
>>> https://wiki.osdev.org/Using_UEFI_Runtime_Services_in_your_Kernel
>>> 
>>> Thanks & Regards
>>> Ritul Guru
>>> +91-9916513186
>>> 
>> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99694): https://edk2.groups.io/g/devel/message/99694
Mute This Topic: https://groups.io/mt/96789290/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] USB: reducing/removing EHCI and XHCI logging when bulk transfer requests timeout

[Andrew Fish via groups.io]

> On Nov 29, 2022, at 11:47 AM, Rebecca Cran  wrote:
> 
> On 11/29/22 12:43, Andrew Fish via groups.io wrote:
>>> On Nov 29, 2022, at 11:12 AM, Rebecca Cran  wrote:
>>> 
>>> I've been working on the UsbNetworkPkg drivers that Richard Ho submitted. 
>>> One problem I've run into is that since we poll for bulk requests, most of 
>>> the time they will timeout - and currently both EHCI and XHCI drivers log 
>>> errors when that happens, which results in log spam and makes interacting 
>>> with the system very difficult (e.g. using UiApp).
>>> 
>>> I was wondering if we might consider adding some mechanism to omit those 
>>> messages if the user desires, perhaps on a per-build basis?
>>> 
>> Are those DEBUG prints or report status code?
> 
> They're DEBUG prints.
> 

If they happen a lot maybe they should be DEBUG_VERBOSE?

Thanks,

Andrew Fish

> -- 
> Rebecca Cran



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#96715): https://edk2.groups.io/g/devel/message/96715
Mute This Topic: https://groups.io/mt/95342129/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] USB: reducing/removing EHCI and XHCI logging when bulk transfer requests timeout

[Andrew Fish via groups.io]

> On Nov 29, 2022, at 11:12 AM, Rebecca Cran  wrote:
> 
> I've been working on the UsbNetworkPkg drivers that Richard Ho submitted. One 
> problem I've run into is that since we poll for bulk requests, most of the 
> time they will timeout - and currently both EHCI and XHCI drivers log errors 
> when that happens, which results in log spam and makes interacting with the 
> system very difficult (e.g. using UiApp).
> 
> I was wondering if we might consider adding some mechanism to omit those 
> messages if the user desires, perhaps on a per-build basis?
> 

Are those DEBUG prints or report status code?

Thanks,

Andrew Fish

> -- 
> Rebecca Cran
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#96712): https://edk2.groups.io/g/devel/message/96712
Mute This Topic: https://groups.io/mt/95342129/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] On RPi4 and Juno, gBS->Stall(1) takes 10us and 100us respectively

[Andrew Fish via groups.io]

Rebecca, 

gBS->Stall() is built on top [1] of the Metronome Architectural Protocol [2]. 
You should look at how the platform implements the Metronome Architectural 
Protocol. 

It looks like most platform implement a generic Metronome Driver[3] that just 
sits on top of the platforms TimerLib [4] implementation. 

You can find the TimerLib implementations via:
$ git grep TimerLib -- \*.inf | grep LIBRARY_CLASS
ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf:14:  LIBRARY_CLASS   
   = TimerLib
EmbeddedPkg/Library/DebugAgentTimerLibNull/DebugAgentTimerLibNull.inf:19:  
LIBRARY_CLASS  = DebugAgentTimerLib|SEC BASE DXE_CORE
EmulatorPkg/Library/DxeCoreTimerLib/DxeCoreTimerLib.inf:22:  LIBRARY_CLASS  
= TimerLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER UEFI_DRIVER 
UEFI_APPLICATION
EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.inf:22:  LIBRARY_CLASS  
= TimerLib|DXE_DRIVER DXE_RUNTIME_DRIVER UEFI_DRIVER UEFI_APPLICATION
EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.inf:22:  LIBRARY_CLASS  
= TimerLib|PEIM PEI_CORE SEC
MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf:23:  
LIBRARY_CLASS  = TimerLib
MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf:30:  LIBRARY_CLASS 
 = TimerLib
OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf:17:  LIBRARY_CLASS  = 
TimerLib|PEI_CORE PEIM DXE_CORE
OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLibBhyve.inf:18:  LIBRARY_CLASS  = 
TimerLib
OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf:16:  LIBRARY_CLASS  = 
TimerLib|SEC
OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf:17:  LIBRARY_CLASS  = 
TimerLib|DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SMM_DRIVER UEFI_DRIVER 
UEFI_APPLICATION SMM_CORE
PcAtChipsetPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf:21:  LIBRARY_CLASS 
 = TimerLib|SEC PEI_CORE PEIM
PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf:21:  LIBRARY_CLASS  
= TimerLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SMM_DRIVER 
UEFI_APPLICATION UEFI_DRIVER SMM_CORE
PcAtChipsetPkg/Library/AcpiTimerLib/PeiAcpiTimerLib.inf:21:  LIBRARY_CLASS  
= TimerLib|PEI_CORE PEIM
PcAtChipsetPkg/Library/AcpiTimerLib/StandaloneMmAcpiTimerLib.inf:23:  
LIBRARY_CLASS  = TimerLib|MM_CORE_STANDALONE MM_STANDALONE
UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf:18:  LIBRARY_CLASS   
   = TimerLib
UefiCpuPkg/Library/SecPeiDxeTimerLibUefiCpu/SecPeiDxeTimerLibUefiCpu.inf:30:  
LIBRARY_CLASS  = TimerLib
UefiPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.inf:15:  LIBRARY_CLASS 
 = TimerLib

So I’d guess your platform is using the ArmArchTimerLi [5]. If that is the case 
I’d look at the value of PcdArmArchTimerFreqInHz if it is zero then I think you 
are running on the default ARM timer value. 

If you are using the stock stuff and all your TimerLib instances are the same 
in all your drivers then the TimerLib is also abstraction the performance 
measure.

This is probably not helpful but the UEFI Spec defines that Stall() delays for 
at least the requested amount of time, with no upper bound on how long it can 
take.  

[1] 
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Misc/Stall.c#L49
[2] 
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/Metronome.h#L25
[3] 
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Metronome/Metronome.c#L61
 
[4] 
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/TimerLib.h 
[5] 
https://github.com/tianocore/edk2/blob/master/ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.c#L18

Thanks,

Andrew Fish


> On Nov 28, 2022, at 11:02 AM, Rebecca Cran  wrote:
> 
> I've been doing some work on USB and ended up realizing that gBS->Stall(1) is 
> taking much longer than it should: on my Juno R2 it's stalling for 100 us, 
> while on my Raspberry Pi 4 it's 10 us.
> 
> This appears to be causing a USB bulk transfer request that asks for a 1ms 
> timeout taking 100ms on the Juno.
> 
> I'm measuring the delay with the following code:
> 
> 
> UINT64 First = GetPerformanceCounter ();
> 
> gBS->Stall (XHC_1_MICROSECOND);
> 
> UINT64 Second = GetPerformanceCounter ();
> 
> UINT64 FirstNs = GetTimeInNanoSecond (First);
> UINT64 SecondNs = GetTimeInNanoSecond (Second);
> 
> DEBUG ((DEBUG_INFO, "Stalled for %llu ns (%llu ms)\n", (SecondNs - FirstNs), 
> (SecondNs - FirstNs) / 1024 / 1024));
> 
> 
> 
> I see output such as:
> 
> Stalled for 10500 ns (0 ms)
> 
> 
> -- 
> Rebecca Cran
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#96657): https://edk2.groups.io/g/devel/message/96657
Mute This Topic: https://groups.io/mt/95317735/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Access 64bit address space in 32bit mode

[Andrew Fish via groups.io]

Vincent,

Thanks! I’d forgotten about that path. 

The other answer is defer the work to a DXE driver that runs 64-bit x86.

Thanks,

Andrew Fish

> On Nov 9, 2022, at 10:58 AM, vincent zimmer  wrote:
> 
> we have the challenge of 32-bit PEI needing to access 64-bit addresses to 
> support 64-bit DXE/UEFI OS's in the capsule use-case scenario.  This is 
> described in 
> https://raw.githubusercontent.com/tianocore-docs/Docs/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf
>  page 22 with code 
> https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Universal/CapsulePei
> 
> On Wed, Nov 9, 2022 at 9:21 AM Andrew Fish via groups.io <http://groups.io/> 
> mailto:apple@groups.io>> wrote:
>> 
>>> On Nov 7, 2022, at 7:16 PM, Yoshinoya >> <mailto:yoshinoyat...@163.com>> wrote:
>>> 
>>> Hello
>>> Is it possible to access 64bit address space in 32bit mode?
>>> 
>> 
>> I assume you are talking about x86?
>> 
>> 
>>> For example, opcode prefix 0x66/67 could let code running in 16bit mode to 
>>> access 32bit data/address.
>>> 
>> 
>> This is more complex than just instruction prefix. You need the CPU to be 
>> setup in big real mode via the GDT, so you basically have a 32-bit 
>> environment setup via GDT etc. Also the prefix opcodes have different 
>> meaning in different modes. I don’t think there is a way to make 32-bit code 
>> access 64-bit data via instruction prefix even if a 64-bit GDT was setup 
>> with paging enabled.  
>> 
>>> Or, establishing page table is a must requirement for accessing 64bit 
>>> address space.
>>> 
>> 
>> For x86 you have to have 64-bit versions of the IDT, GDT, and you need to 
>> enable paging to enter 64-bit Long Mode. 
>> 
>> In a 32-bit x86 world you can access up to 64 GB of physical memory via 
>> using 32-bit page table using PAE [1]. PAE is a 32-bit virtual address 
>> space, but with support for a 36-bit physical address. I think in the olden 
>> days of 32-bit x86 EFI servers would have custom EFI code that enabled 
>> paging in 32-bit and carved out a chunk of the 32-bit memory space that 
>> could be mapped to 36-bit physical addresses. I think this was platform 
>> specific code and I don’t know of any open source version. The 32-bit Long 
>> Mode EFI does not have paging enabled, so adding PAE means enabling paging 
>> yourself. 
>> 
>> The edk2 has the opposite version of this code so you can call 16-bit really 
>> mode (Legacy BIOS) from 32-bit Protected mode, or 64-bit Long Mode. This is 
>> the code to Thunk for 32-bit/64-bit mode to 16-bit code [2]/ 
>> 
>> [1] https://en.wikipedia.org/wiki/Physical_Address_Extensio 
>> <https://en.wikipedia.org/wiki/Physical_Address_Extension>n 
>> <https://en.wikipedia.org/wiki/Physical_Address_Extension>
>> [2] 
>> https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/X86Thunk.c
>> 
>> edk2/Thunk16.nasm at master · tianocore/edk2
>> github.com
>>  
>> <https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/X64/Thunk16.nasm>edk2/Thunk16.nasm
>>  at master · tianocore/edk2 
>> <https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/X64/Thunk16.nasm>
>> github.com 
>> <https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/X64/Thunk16.nasm>
>> 
>> edk2/Thunk16.nasm at master · tianocore/edk2
>> github.com
>>  
>> <https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/Ia32/Thunk16.nasm>edk2/Thunk16.nasm
>>  at master · tianocore/edk2 
>> <https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/Ia32/Thunk16.nasm>
>> github.com 
>> <https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/Ia32/Thunk16.nasm>
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> 
>>> Thanks
>>>  
>> 
>> 
>> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#96170): https://edk2.groups.io/g/devel/message/96170
Mute This Topic: https://groups.io/mt/94885261/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] How to add a DXE driver to an OVMF image?

[Andrew Fish via groups.io]

> On Nov 9, 2022, at 10:29 AM, d.meneses via groups.io 
>  wrote:
> 
> Thank you Andrew for your reply. 
> 
> Your explanation about the Driver Binding protocol cleared up some questions 
> of mine.
> 
> Regarding the BDS, I recon I have some reading to do before I understand what 
> you said and why it might be relevant to me.
> 

The BDS is what runs after all the discovered drivers have been dispatched. The 
BDS processes all those UEFI NVRAM variables I references, and sets platform 
defaults. 

> For now I am investigating the possibility of having a DxeDriver load an UEFI 
> application and create an event to start it after the DXE Phase is over and 
> the Terminal protocol is available. 
> 

That seems very Rube Goldberg. There are no threads in UEFI, just events that 
run at a higher TPL. It is not legal, per the UEFI specification to run 
applications at elevate TPL [1]. There is no way for a driver to inject its 
self into the main thread. So for example your App running at elevate TPL could 
block the lower priority events needed to read from the disk or manage the 
network traffic. EFI is a cooperative event model so your code running at a 
given event level blocks all code at that level or lower from running 
indefinitely. 

> I need to:
> - learn how to load and start images. To that end I have found a 
> CoreLoadImage and CoreStartImage edk2 functions, buuut
> - I haven't figured out how to get the device path to my UEFI app
> - I was wondering if I could somehow use my app's GUID to search for it? 

If you look at the code I pointed you to in the OVMF BDS Platform lib I think 
you will find it writes an UEFI Boot Variable that contains a Device Path that 
has the FILE_GUID as the file name. 

If you want to try something quick you could replace the FILE_GUID for the UEFI 
Shell with the FILE_GUID for your App and it should not launch in place of the 
UEFI Shell. 

> - Then I'd learn how to use events and have them start the app 
> 

As I mentioned that is going to break stuff. 

[1]
https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html#event-timer-and-task-priority-services
> I'm deeply thankful for your time, wish you luck and peace
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#96169): https://edk2.groups.io/g/devel/message/96169
Mute This Topic: https://groups.io/mt/94734592/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] How to add a DXE driver to an OVMF image?

[Andrew Fish via groups.io]

> On Nov 4, 2022, at 6:20 AM, d.meneses via groups.io 
>  wrote:
> 
> Using DebugLib instead to print a message, I was able to confirm that my 
> driver is now running properly:
> cat debug.log | grep Hello
> This works both when adding it in the OVMF build and also when inserted by 
> UEFITool.
> 
> The drivers is not being listed by the EFI Shell drivers command.
> This is expected to me as Dxe Drivers are unloaded after they return.
> Nonetheless, the same is happening when I package it as a DXE_RUNTIME_DRIVER.
> What is it that I'm missing?
> 

The UEFI Shell drivers command is managing UEFI Driver Model Drivers [1]. A 
UEFI Driver Model Driver has no depex and publishes an EFI Driver Binding 
protocol [2]. The idea is the BDS (platform) can now have the policy of what 
driver gets connected to what device. This is all managed by 
gBS->ConnectController()/gBS->DisconnectController(). 

A DXE Driver just publishes an arbitrary protocol. 

[1] https://uefi.org/specs/UEFI/2.10/11_Protocols_UEFI_Driver_Model.html
[2] 
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DriverBinding.h


PS I seem to remember a question about launching an App….

It is possible to customize a generic UEFIs system boot policy via NVRAM 
variable. You can read up on that here [3]. 

If you want to change the platform policy in a secure way to do something you 
likely need to modify the BDS (Boot Device Selection). The design idea around 
BDS is you could make a system an ATM or a PC just by changing the policy in 
the BDS, thus the BDS is a place to centralize the platform policy. The easiest 
way to customize the edk2 BDS is via a custom PlatformBootManagerLib. You can 
look at the OVMF instance here [4]. You can use this library to add extra 
policy on top of the NVRAM variables in the UEFI Spec [3]. If you look at the 
OVMF example this is how the OVMF platform makes the UEFI Shell a default boot 
option [5].

[3] 
https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html#globally-defined-variables
[4] 
https://github.com/tianocore/edk2/tree/master/OvmfPkg/Library/PlatformBootManagerLib
[5] 
https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c#L1717

Sorry if I’m mixing up threads. So much email, and so little time….

> Thank you for your attention,
> Diogo
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#96162): https://edk2.groups.io/g/devel/message/96162
Mute This Topic: https://groups.io/mt/94734592/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] How to add a DXE driver to an OVMF image?

[Andrew Fish via groups.io]

> On Nov 3, 2022, at 12:11 PM, d.meneses via groups.io 
>  wrote:
> 
> Yes I also believe I'm threading a XY problem. 
> 
> Let's simplify my learning and set the goal to: add an UEFI application to 
> OVMF so that it runs natively on startup.
> 
> Does this make more sense?
> 
> I followed the same process and I can use UEFITool to confirm there's an 
> UefiApplication inside the OVMF image.
> 
> How can I make it run?

Do you need to run it from FLASH? Or do you just want to run it? 

What I usually do with QEMU is pass -hda fat:rw:Build/OvmfX64/DEBUG_XCODE5/X64 
to mount a directory on my system in QEMU. This should show up in the UEFI 
Shell as FS0: if you don’t have any other disks. The path is the build output, 
so you need to match what you built. So DEBUG_GCC??? Vs DEBUG_XCODE, as this 
path encodes the build target, compiler, etc.

Then when you boot to the UEFI Shell you just need to mount the disk and run 
your app. 

Fs0:
MyApp.efi

You can also redirect the text output of your app to a file, and since fs0: is 
just your build directory you can get the output out of the VM. 

>From the UEFI Shell you can `reset -s` to shut down the VM.

If you place a startup.nsh the UEFI Shell command should run those commands 
when launched. 

It is also possible to make a FAT32 disk image and boot your app directly, just 
like an OS loader[1]. Just copy your app to /EFI/BOOT/BOOTx64.EFI in the disk 
image and mount the disk image from the QEMU command line.

[1] 
https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html#removable-media-boot-behavior

Thanks,

Andrew Fish


> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#95905): https://edk2.groups.io/g/devel/message/95905
Mute This Topic: https://groups.io/mt/94734592/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] How to add a DXE driver to an OVMF image?

[Andrew Fish via groups.io]

If you are building with the firmware use the DebugLib in the INF and DEBUG(); 
macros.

DEBUG((DEBUG_ERROR, “It works\n”));

Also by setting your Depex to TRUE you are basically asking to run before the 
console is available. If you want to depend on all UEFI Services being present 
don’t set a dependency expression. The Depex is for ordering the early drivers 
that don’t follow the UEFI Driver Model. So for example you have to configure 
your chipset, and SPI driver to get UEFI NVRAM working etc. 

Thanks,

Andrew Fish

> On Nov 2, 2022, at 5:58 PM, Pedro Falcato  wrote:
> 
> Hi!
> 
> If I recall correctly, UEFI drivers are not guaranteed to have a valid ConOut 
> and ConIn, and you're not supposed to use those. They are (always?) valid in 
> UEFI apps.
> Can you try to use DebugLib (don't forget to place DebugLib in 
> LibraryClasses) and DEBUG((DEBUG_INFO, "Blah\n")); ? That should pretty much 
> work. Note that OVMF will send those debug messages to a special device, so 
> you can pass "-debugcon file:debug.log -global isa-debugcon.iobase=0x402" to 
> QEMU to keep them. The rest of your procedure looks mostly OK as far as I can 
> tell.
> 
> Crash theory: ConOut was garbage, so you tried to jump into a random address. 
> Random address had random data/instructions in there, which caused you an int 
> 6 -> Invalid opcode.
> 
> Thanks,
> Pedro
> 
> On Wed, Nov 2, 2022 at 2:02 PM d.meneses via groups.io  
> mailto:softi9...@groups.io>> wrote:
>> As detailed on this post on Super User 
>> , I am trying to add a DXE driver 
>> to an OVMF image I'm building with edk2. Nobody was able to help me there so 
>> I turn here for your help.
>>  
>> I haven't found any proper documentation on exactly what I'm trying to 
>> achieve so I am probably missing something.
>>  
>> So far what I have done is:
>> create the simplest DXE driver I managed
>> In folder MdeModulePkg/Application/Hello, I have:
>> Hello.c : 
>> include
>>  
>> ...
>>  
>> while (1)
>> SystemTable->ConOut->OutputString(SystemTable->ConOut,
>>   L"It works!\n");
>> return EFI_SUCCESS;
>> 
>>  
>> Hello.inf : 
>> [Defines]
>>   INF_VERSION= 0x00010005
>>   BASE_NAME  = Hello
>>   FILE_GUID  = ...
>>   MODULE_TYPE= DXE_DRIVER
>>   VERSION_STRING = 1.0
>>   ENTRY_POINT= UefiMain
>> 
>> 
>> [Sources]
>>   Hello.c
>> 
>> [Packages]
>>   MdePkg/MdePkg.dec
>>   MdeModulePkg/MdeModulePkg.dec
>> 
>> [LibraryClasses]
>>   UefiDriverEntryPoint
>>   UefiLib
>> 
>> [Depex]
>> TRUE
>> Set OvmfPkg/OvmfPkgX64.dsc as my target platform with GCC5 as the toolchain
>> Add MdeModulePkg/Application/Hello/Hello.inf to the end of the component 
>> section (I have tried to add it after other certain drivers) in the .dsc 
>> file.
>> Add MdeModulePkg/Application/Hello/Hello.inf to the end of the [FV.DXEFV] 
>> section in OvmfPkgX64.fdf (I have also tried to add it after other certain 
>> drivers)
>> Run build
>> Run QEMU with the resulting OVMF image: qemu-system-x86_64 -d int -D log.txt 
>>  -bios OVMF.fd -net none -drive file=fat:rw:bootdrv,format=raw
>> QEMU hangs with message "Guest has not initialized display (yet)"
>> log.txt has one log: check_exception old: 0x new 0x6
>>  
>> 
>> 
> 
> 
> -- 
> Pedro Falcato
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#95875): https://edk2.groups.io/g/devel/message/95875
Mute This Topic: https://groups.io/mt/94734592/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] TPM2 EventLog EFI vs. ACPI

[Andrew Fish via groups.io]

> On Sep 17, 2022, at 11:31 AM, Jason Andryuk  wrote:
> 
> On Fri, Sep 16, 2022 at 10:28 PM Andrew Fish via groups.io
>  wrote:
>> 
>> Is it possible to query the address from fw_cfg?
> 
> Hi, Andrew,
> 
> I believe QEMU puts "commands" into fw_cfg, and OVMF processes them to
> allocate the memory and write the address into the correct ACPI table
> location.  However, it seems to be done generically without awareness
> that the Event Log is being allocated in this case.
> 

I understand, but I think there are other cases when you can query for more 
specific information. For example you can get info on how to write an EFI PCI 
Root Bridge drive, and the ACPI methods also implement a similar abstraction. 

So it’s worth looking to see if that info is availible.

> Regards,
> Jason


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#93917): https://edk2.groups.io/g/devel/message/93917
Mute This Topic: https://groups.io/mt/93730585/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] TPM2 EventLog EFI vs. ACPI

[Andrew Fish via groups.io]

Is it possible to query the address from fw_cfg?

Thanks,

Andrew Fish

> On Sep 16, 2022, at 12:45 PM, Jason Andryuk  wrote:
> 
> Hi,
> 
> I've noticed an issue with the TPM2 EventLog.  OVMF exposes the TPM
> Event Log via EFI and ACPI, but they have different addresses.  The
> EFI one retrievable by GetEventLog() is populated.  The ACPI is empty.
> Oh, there are actually two EFI Event Logs for the two formats:
> EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2
> EFI_TCG2_EVENT_LOG_FORMAT_TCG_2
> 
> The debug log from the Fedora 36 OVMF shows:
> Tcg2GetEventLog (EventLogLocation - 7EEB2000)
> which matches the address retrieved with GetEventLog().
> And hexdump-ing the TPM2 ACPI table shows 0x7fbe6000.
> 
> On a different build, I added output for both EFI logs, and the addresses are:
> 0x7ec3d000 - EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2
> 0x7ec1b000 - EFI_TCG2_EVENT_LOG_FORMAT_TCG_2
> 0x7fbe6000 - ACPI
> 
> The ACPI one is a little more user friendly as its address is
> available through the table during runtime.  The EFI addresses can
> only be grabbed before exiting boot services.
> 
> I think the issue is that the ACPI tables are created from Qemu fw_cfg
> data, which allocates memory for the log and places the address in
> ACPI tables.  Meanwhile,
> SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c:SetupEventLog() allocates its own
> event log memory.  SetupEventLog() saves the size and address in
> PcdTpm2AcpiTableLaml & PcdTpm2AcpiTableLasa, but nothing puts those
> values in the actual ACPI tables.
> 
> It seems like SetupEventLog would be better structured to check
> existing ACPI tables and look for a log in a TPM2 section.  If found,
> use that, otherwise create a new log area.
> 
> The other wrinkle is that the Tcg2 code is keeping two event logs in
> the two formats.  It seems to me that for TPM2, it would be easier to
> just keep only the newer EFI_TCG2_EVENT_LOG_FORMAT_TCG_2.  If support
> for both is needed, then the EFI_TCG2_EVENT_LOG_FORMAT_TCG_2 one
> should share the same region as the ACPI table.
> 
> Regards,
> Jason
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#93914): https://edk2.groups.io/g/devel/message/93914
Mute This Topic: https://groups.io/mt/93730585/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] Maintainers.txt: Update email address

[Andrew Fish via groups.io]

Reviewed-by: Andrew Fish 

> On Sep 15, 2022, at 9:58 AM, Michael D Kinney  
> wrote:
> 
> Reviewed-by: Michael D Kinney  >
> 
> 
>> -Original Message-
>> From: Nickle Wang mailto:nick...@nvidia.com>>
>> Sent: Wednesday, September 14, 2022 7:20 PM
>> To: devel@edk2.groups.io 
>> Cc: Andrew Fish mailto:af...@apple.com>>; Leif Lindholm 
>> mailto:quic_llind...@quicinc.com>>; Kinney, 
>> Michael D mailto:michael.d.kin...@intel.com>>;
>> Abner Chang mailto:abner.ch...@amd.com>>
>> Subject: [PATCH] Maintainers.txt: Update email address
>> 
>> Update Nickle's email address from csie.io to nvidia.com for those
>> packages which are reviewed by Nickle. Per suggestion from Abner,
>> change Nickle from reviewer to maintainer for RedfishPkg.
>> 
>> Cc: Andrew Fish 
>> Cc: Leif Lindholm 
>> Cc: Michael D Kinney 
>> Cc: Abner Chang 
>> Signed-off-by: Nickle Wang 
>> ---
>> Maintainers.txt | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/Maintainers.txt b/Maintainers.txt
>> index 73ce13126b..390f084c03 100644
>> --- a/Maintainers.txt
>> +++ b/Maintainers.txt
>> @@ -197,7 +197,7 @@ S: Maintained
>> EmulatorPkg: Redfish-related modules
>> F: EmulatorPkg/*Redfish*
>> M: Abner Chang  [changab]
>> -R: Nickle Wang  [nicklela]
>> +M: Nickle Wang  [nicklela]
>> 
>> FatPkg
>> F: FatPkg/
>> @@ -544,7 +544,7 @@ R: Ankit Sinha  [ankit13s]
>> RedfishPkg: Redfish related modules
>> F: RedfishPkg/
>> M: Abner Chang  [changab]
>> -R: Nickle Wang  [nicklela]
>> +M: Nickle Wang  [nicklela]
>> 
>> SecurityPkg
>> F: SecurityPkg/
>> --
>> 2.34.1
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#93854): https://edk2.groups.io/g/devel/message/93854
Mute This Topic: https://groups.io/mt/93694146/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Error building MdeModulePkg.dsc with CLANG38 (clang 11.0.1)

[Andrew Fish via groups.io]

That is a missing EFIAPI.
> On Sep 6, 2022, at 4:46 PM, Rebecca Cran  wrote:
> 
> I noticed that MdeModulePkg/MdeModulePkg.dsc doesn't build with clang 11: I 
> get an error in CapsuleApp:
> 
> 
> build -p MdeModulePkg/MdeModulePkg.dsc -a X64 -t CLANG38 -b DEBUG
> 
> ...
> 
> MdeModulePkg/Application/CapsuleApp/CapsuleDump.c:797:5: error: cast between 
> incompatible calling conventions 'cdecl' and 'ms_abi'; calls through this 
> pointer may abort at runtime [-Werror,-Wcast-calling-convention]
> 
> (SORT_COMPARE)CompareFileNameInAlphabet
> 
> ^~~
> 
> MdeModulePkg/Application/CapsuleApp/CapsuleDump.c:635:1: note: consider 
> defining 'CompareFileNameInAlphabet' with the 'ms_abi' calling convention
> 
> CompareFileNameInAlphabet (
> 
> ^
> 
> EFIAPI
> 
> 1 error generated.
> 
> make: *** [GNUmakefile:361: 
> Build/MdeModule/DEBUG_CLANG38/X64/MdeModulePkg/Application/CapsuleApp/CapsuleApp/OUTPUT/CapsuleDump.obj]
>  Error 1
> 
> -- 
> 
> Rebecca Cran
> 
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#93312): https://edk2.groups.io/g/devel/message/93312
Mute This Topic: https://groups.io/mt/93514380/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] MdePkg: Use ANSI colors to indicate debug message severity

[Andrew Fish via groups.io]

> On Sep 1, 2022, at 4:52 PM, Rebecca Cran  wrote:
> 
> Thanks. I've just sent out a v2 that introduces a
> 
> PcdTerminalSupportsAnsiSequences FeatureFlag.
> 
> Let me know if you'd prefer a different name: I wondered about something like 
> PcdConOutAnsiSeqSupport for example.
> 

Rebecca,

I think this feature flag is going to control the output of edk2 DEBUG. In an 
abstract sense DEBUG is not Terminal or ConOut. It could be mapped to the same 
device, but it does not have to be. 

So maybe PcdDebugAnsiSeqSupport or DebugLibAnsiSeqSupport? 

Thanks,

Andrew Fish

> -- 
> Rebecca Cran
> 
> On 8/29/22 17:29, Kinney, Michael D wrote:
>> Hi Rebecca,
>> 
>> I think this is a good idea to improve readability.
>> 
>> However, I think there is an assumption today that debug
>> message output is just ASCII text with no assumptions on
>> a terminal type and no assumption on screen width or screen
>> height and no support for cursor control.
>> 
>> This change would only make sense if the device the
>> serial messages are sent supports ANSI color codes.
>> 
>> I think we should make this a build time configuration
>> option to add the ANSI sequences.  I suggest a FeatureFlag
>> PCD with a default of disabled to preserve current behavior
>> and platforms can opt into ANSI color coded debug messages
>> in their DSC file.
>> 
>> Thanks,
>> 
>> Mike
>> 
>>> -Original Message-
>>> From: Rebecca Cran 
>>> Sent: Monday, August 29, 2022 3:12 PM
>>> To: devel@edk2.groups.io; Kinney, Michael D ; 
>>> Gao, Liming ; Liu, Zhiguang
>>> 
>>> Cc: Rebecca Cran 
>>> Subject: [PATCH 1/1] MdePkg: Use ANSI colors to indicate debug message 
>>> severity
>>> 
>>> There currently isn't a way to differentiate the different
>>> levels of DEBUG output: DEBUG_ERROR, DEBUG_WARN, DEBUG_INFO
>>> etc.
>>> 
>>> To improve this, wrap DEBUG_ERROR and DEBUG_WARN level
>>> messages in ANSI color code escape sequences. DEBUG_ERROR
>>> messages will be displayed in red text, and DEBUG_WARN
>>> in orange (the escape code is for the yellow color palette
>>> entry, but it gets displayed as orange).
>>> 
>>> Signed-off-by: Rebecca Cran 
>>> ---
>>>  MdePkg/Include/Library/PrintLib.h|  39 ++
>>>  MdePkg/Library/BaseDebugLibSerialPort/DebugLib.c |   2 +
>>>  MdePkg/Library/BasePrintLib/PrintLib.c   | 128 
>>>  MdePkg/Library/UefiDebugLibConOut/DebugLib.c |   2 +
>>>  4 files changed, 171 insertions(+)
>>> 
>>> diff --git a/MdePkg/Include/Library/PrintLib.h 
>>> b/MdePkg/Include/Library/PrintLib.h
>>> index 8d523cac528d..06d9761df897 100644
>>> --- a/MdePkg/Include/Library/PrintLib.h
>>> +++ b/MdePkg/Include/Library/PrintLib.h
>>> @@ -2,6 +2,7 @@
>>>Provides services to print a formatted string to a buffer. All 
>>> combinations of
>>>Unicode and ASCII strings are supported.
>>> 
>>> +Copyright (c) 2022, Qualcomm Innovation Center, Inc. All rights 
>>> reserved.
>>>  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
>>>  SPDX-License-Identifier: BSD-2-Clause-Patent
>>> 
>>> @@ -931,4 +932,42 @@ SPrintLengthAsciiFormat (
>>>IN  VA_LIST  Marker
>>>);
>>> 
>>> +/**
>>> +  Wraps a message with ANSI color escape codes.
>>> +
>>> +  @param String The string to wrap.
>>> +  @param StringLen  The size of the String buffer in characters.
>>> +  @param ErrorLevel The error level.
>>> +
>>> +  @retval RETURN_SUCCESS  The string was successfully updated.
>>> +  @retval RETURN_BUFFER_TOO_SMALL The buffer is too small.
>>> +
>>> +**/
>>> +RETURN_STATUS
>>> +EFIAPI
>>> +AsciiDebugGetColorString (
>>> +  IN OUT CHAR8  *String,
>>> +  IN UINTN  StringLen,
>>> +  IN UINTN  ErrorLevel
>>> +  );
>>> +
>>> +/**
>>> +  Wraps a message with ANSI color escape codes.
>>> +
>>> +  @param String The string to wrap.
>>> +  @param StringLen  The size of the String buffer in Unicode characters.
>>> +  @param ErrorLevel The error level.
>>> +
>>> +  @retval RETURN_SUCCESS  The string was successfully updated.
>>> +  @retval RETURN_BUFFER_TOO_SMALL The buffer is too small.
>>> +
>>> +**/
>>> +RETURN_STATUS
>>> +EFIAPI
>>> +UnicodeDebugGetColorString (
>>> +  IN OUT CHAR16  *String,
>>> +  IN UINTN   StringLen,
>>> +  IN UINTN   ErrorLevel
>>> +  );
>>> +
>>>  #endif
>>> diff --git a/MdePkg/Library/BaseDebugLibSerialPort/DebugLib.c 
>>> b/MdePkg/Library/BaseDebugLibSerialPort/DebugLib.c
>>> index bd5686947712..d599d16f5b7a 100644
>>> --- a/MdePkg/Library/BaseDebugLibSerialPort/DebugLib.c
>>> +++ b/MdePkg/Library/BaseDebugLibSerialPort/DebugLib.c
>>> @@ -125,6 +125,8 @@ DebugPrintMarker (
>>>  AsciiBSPrint (Buffer, sizeof (Buffer), Format, BaseListMarker);
>>>}
>>> 
>>> +  AsciiDebugGetColorString (Buffer, MAX_DEBUG_MESSAGE_LENGTH, ErrorLevel);
>>> +
>>>//
>>>// Send the print string to a Serial Port
>>>//
>>> diff --git a/MdePkg/Library/BasePrintLib/PrintLib.c 
>>> b/MdePkg/Library/BasePrintLib/PrintLib.c
>>> index 

Re: [edk2-devel] How to restrict HTTPS boot to a single address

[Andrew Fish via groups.io]

Rafael,

I’m not sure this matches exactly what you are looking for, but the OVMF 
(Virtual Machine) has some configuration options around HTTPS boot [1]. That 
might be a good place to start. 

[1] https://github.com/tianocore/edk2/blob/master/OvmfPkg/README#L232

Thanks,

Andrew Fish

> On Aug 26, 2022, at 7:15 AM, Rafael Machado 
>  wrote:
> 
> Hello everyone.
> 
> Quick question for the ones that understand better the HTTPBoot architecture 
> at the edk2 structure.
> 
> Suppose I have to restrict HTTPS boot to accept only the download of images 
> from a specific url.
> For example, instead of allowing the download of images from any valid CA 
> certificate address, I would like to restrict HTTPSBoot to allow only 
> downloads from some specific domain I have.
> 
> Probably filtering some information, CN or something like that, from the url 
> certificate.
> 
> What is the best way to do that?
> In which driver/library should this logic be added?
> 
> Thanks
> Rafael
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92869): https://edk2.groups.io/g/devel/message/92869
Mute This Topic: https://groups.io/mt/93270616/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] BaseTools no longer builds on macOS: "error: unknown warning option '-Werror=stringop-overflow'"

[Andrew Fish via groups.io]

Maybe having the check last would be cleaner. 

diff --git a/BaseTools/Source/C/DevicePath/GNUmakefile 
b/BaseTools/Source/C/DevicePath/GNUmakefile
index c217674345b1..17f213879e82 100644
--- a/BaseTools/Source/C/DevicePath/GNUmakefile
+++ b/BaseTools/Source/C/DevicePath/GNUmakefile
@@ -16,10 +16,12 @@ include $(MAKEROOT)/Makefiles/app.makefile
 GCCVERSION = $(shell gcc -dumpversion | awk -F'.' '{print $$1}')
 ifneq ("$(GCCVERSION)", "5")
 ifneq ($(CXX), llvm)
+ifneq ($(DARWIN),Darwin)
 # gcc 12 trips over device path handling
 BUILD_CFLAGS += -Wno-error=stringop-overflow
 endif
 endif
+endif
 
 LIBS = -lCommon
 ifeq ($(CYGWIN), CYGWIN)


Thanks,

Andrew Fish

> On Aug 25, 2022, at 10:45 AM, Andrew Fish via groups.io 
>  wrote:
> 
> Rebecca,
> 
> FYI /usr/bin/gcc has been a redirector into clang for a lot of years. 
> 
> The build picks different default sets of complier flags based on build type. 
> There is already code that assumes gcc == clang here [1]
> 
> I think the issue is the check that is wrapping "BUILD_CFLAGS += 
> -Wno-error=stringop-overflow”. It needs to skip the check on macOS. 
> 
> diff --git a/BaseTools/Source/C/DevicePath/GNUmakefile 
> b/BaseTools/Source/C/DevicePath/GNUmakefile
> index c217674345b1..f3c9739617f2 100644
> --- a/BaseTools/Source/C/DevicePath/GNUmakefile
> +++ b/BaseTools/Source/C/DevicePath/GNUmakefile
> @@ -14,12 +14,14 @@ OBJECTS = DevicePath.o UefiDevicePathLib.o 
> DevicePathFromText.o  DevicePathUtili
>  include $(MAKEROOT)/Makefiles/app.makefile
>  
>  GCCVERSION = $(shell gcc -dumpversion | awk -F'.' '{print $$1}')
> +ifneq ($(DARWIN),Darwin)
>  ifneq ("$(GCCVERSION)", "5")
>  ifneq ($(CXX), llvm)
>  # gcc 12 trips over device path handling
>  BUILD_CFLAGS += -Wno-error=stringop-overflow
>  endif
>  endif
> +endif
>  
>  LIBS = -lCommon
>  ifeq ($(CYGWIN), CYGWIN)
> 
> 
> [1] 
> https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/Makefiles/header.makefile#L83
> 
> Thanks,
> 
> Andrew Fish
> 
>> On Aug 25, 2022, at 9:20 AM, Rebecca Cran  wrote:
>> 
>> BaseTools no longer builds on macOS (12.5.1, Monterey), because 'gcc' in 
>> /usr/bin is really clang.
>> 
>> I tried installing gcc 12 from Homebrew, but the build then failed saying it 
>> couldn't find _stdio.h.
>> 
>> It appears the breakage might have been introduced in this commit back in 
>> March:
>> 
>> commit 22130dcd98b4d4b76ac8d922adb4a2dbc86fa52c
>> Author: Gerd Hoffmann 
>> Date:   Thu Mar 24 20:04:36 2022 +0800
>> 
>> Basetools: turn off gcc12 warning
>> 
>> Running "make -C BaseTools" produces the following error:
>> 
>> 
>> /Library/Developer/CommandLineTools/usr/bin/make -C DevicePath
>> gcc  -c  -I .. -I ../Include/Common -I ../Include/ -I 
>> ../Include/IndustryStandard -I ../Common/ -I .. -I . -I ../Include/X64/ -MD 
>> -fshort-wchar -fno-strict-aliasing -Wall -Werror 
>> -Wno-deprecated-declarations -Wno-self-assign -Wno-unused-result -nostdlib 
>> -g -O2  -Wno-error=stringop-overflow DevicePath.c -o DevicePath.o
>> error: unknown warning option '-Werror=stringop-overflow'; did you mean 
>> '-Werror=shift-overflow'? [-Werror,-Wunknown-warning-option]
>> make[2]: *** [DevicePath.o] Error 1
>> make[1]: *** [DevicePath] Error 2
>> make: *** [Source/C] Error 2
>> 
>> 
>> bcran@procan edk2 % gcc -v
>> Configured with: --prefix=/Library/Developer/CommandLineTools/usr 
>> --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
>> Apple clang version 12.0.5 (clang-1205.0.22.9)
>> Target: x86_64-apple-darwin21.6.0
>> Thread model: posix
>> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>> 
>> bcran@procan edk2 % uname -a
>> Darwin procan.int.bsdio.com 21.6.0 Darwin Kernel Version 21.6.0: Wed Aug 10 
>> 14:25:27 PDT 2022; root:xnu-8020.141.5~2/RELEASE_X86_64 x86_64
>> 
>> -- 
>> Rebecca Cran
>> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92821): https://edk2.groups.io/g/devel/message/92821
Mute This Topic: https://groups.io/mt/93251921/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] BaseTools no longer builds on macOS: "error: unknown warning option '-Werror=stringop-overflow'"

[Andrew Fish via groups.io]

Rebecca,

FYI /usr/bin/gcc has been a redirector into clang for a lot of years. 

The build picks different default sets of complier flags based on build type. 
There is already code that assumes gcc == clang here [1]

I think the issue is the check that is wrapping "BUILD_CFLAGS += 
-Wno-error=stringop-overflow”. It needs to skip the check on macOS. 

diff --git a/BaseTools/Source/C/DevicePath/GNUmakefile 
b/BaseTools/Source/C/DevicePath/GNUmakefile
index c217674345b1..f3c9739617f2 100644
--- a/BaseTools/Source/C/DevicePath/GNUmakefile
+++ b/BaseTools/Source/C/DevicePath/GNUmakefile
@@ -14,12 +14,14 @@ OBJECTS = DevicePath.o UefiDevicePathLib.o 
DevicePathFromText.o  DevicePathUtili
 include $(MAKEROOT)/Makefiles/app.makefile
 
 GCCVERSION = $(shell gcc -dumpversion | awk -F'.' '{print $$1}')
+ifneq ($(DARWIN),Darwin)
 ifneq ("$(GCCVERSION)", "5")
 ifneq ($(CXX), llvm)
 # gcc 12 trips over device path handling
 BUILD_CFLAGS += -Wno-error=stringop-overflow
 endif
 endif
+endif
 
 LIBS = -lCommon
 ifeq ($(CYGWIN), CYGWIN)


[1] 
https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/Makefiles/header.makefile#L83

Thanks,

Andrew Fish

> On Aug 25, 2022, at 9:20 AM, Rebecca Cran  wrote:
> 
> BaseTools no longer builds on macOS (12.5.1, Monterey), because 'gcc' in 
> /usr/bin is really clang.
> 
> I tried installing gcc 12 from Homebrew, but the build then failed saying it 
> couldn't find _stdio.h.
> 
> It appears the breakage might have been introduced in this commit back in 
> March:
> 
> commit 22130dcd98b4d4b76ac8d922adb4a2dbc86fa52c
> Author: Gerd Hoffmann 
> Date:   Thu Mar 24 20:04:36 2022 +0800
> 
> Basetools: turn off gcc12 warning
> 
> Running "make -C BaseTools" produces the following error:
> 
> 
> /Library/Developer/CommandLineTools/usr/bin/make -C DevicePath
> gcc  -c  -I .. -I ../Include/Common -I ../Include/ -I 
> ../Include/IndustryStandard -I ../Common/ -I .. -I . -I ../Include/X64/ -MD 
> -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations 
> -Wno-self-assign -Wno-unused-result -nostdlib -g -O2  
> -Wno-error=stringop-overflow DevicePath.c -o DevicePath.o
> error: unknown warning option '-Werror=stringop-overflow'; did you mean 
> '-Werror=shift-overflow'? [-Werror,-Wunknown-warning-option]
> make[2]: *** [DevicePath.o] Error 1
> make[1]: *** [DevicePath] Error 2
> make: *** [Source/C] Error 2
> 
> 
> bcran@procan edk2 % gcc -v
> Configured with: --prefix=/Library/Developer/CommandLineTools/usr 
> --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
> Apple clang version 12.0.5 (clang-1205.0.22.9)
> Target: x86_64-apple-darwin21.6.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
> 
> bcran@procan edk2 % uname -a
> Darwin procan.int.bsdio.com 21.6.0 Darwin Kernel Version 21.6.0: Wed Aug 10 
> 14:25:27 PDT 2022; root:xnu-8020.141.5~2/RELEASE_X86_64 x86_64
> 
> -- 
> Rebecca Cran
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92820): https://edk2.groups.io/g/devel/message/92820
Mute This Topic: https://groups.io/mt/93251921/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] Mde Pkg: Support for MPAM ACPI Table

[Andrew Fish via groups.io]

Rohit,

FYI I seem to remember when we added the bitfield verbiage to the UEFI Spec it 
was because there was lots of platform code that was using it. We did not 
really want to encourage its use it in public interfaces. 

Given there is lots of code 1st kind of things going on I’d figured I’d mention 
this. 

Thanks,

Andrew Fish

> On Aug 23, 2022, at 2:28 PM, Rohit Mathew  wrote:
> 
> Hi Andrew,
>  
> From: Andrew Fish mailto:af...@apple.com>> 
> Sent: 23 August 2022 21:11
> To: devel@edk2.groups.io ; Rohit Mathew 
> mailto:rohit.mat...@arm.com>>
> Cc: usern...@nvidia.com ; Sami Mujawar 
> mailto:sami.muja...@arm.com>>; Alexei Fedorov 
> mailto:alexei.fedo...@arm.com>>; Mike Kinney 
> mailto:michael.d.kin...@intel.com>>; 
> gaolim...@byosoft.com.cn ; 
> zhiguang@intel.com ; Swatisri Kantamsetti 
> mailto:swatis...@nvidia.com>>; Thomas Abraham 
> mailto:thomas.abra...@arm.com>>; Thanu Rangarajan 
> mailto:thanu.rangara...@arm.com>>; nd 
> mailto:n...@arm.com>>
> Subject: Re: [edk2-devel] [PATCH 1/2] Mde Pkg: Support for MPAM ACPI Table
>  
>  
> 
> 
> On Aug 19, 2022, at 1:26 AM, Rohit Mathew  > wrote:
>  
> Hi Swatisri,
> 
> Thanks for the patch. Please find my comments inline marked [Rohit] -
> 
> 
> -Original Message-
> From: devel@edk2.groups.io  
> mailto:devel@edk2.groups.io>> On Behalf Of Name
> via groups.io 
> Sent: 16 August 2022 21:18
> To: devel@edk2.groups.io ; Sami Mujawar 
> mailto:sami.muja...@arm.com>>;
> Alexei Fedorov mailto:alexei.fedo...@arm.com>>; 
> michael.d.kin...@intel.com ;
> gaolim...@byosoft.com.cn ; 
> zhiguang@intel.com 
> Cc: Swatisri Kantamsetti mailto:swatis...@nvidia.com>>
> Subject: [edk2-devel] [PATCH 1/2] Mde Pkg: Support for MPAM ACPI Table
> 
> From: Swatisri Kantamsetti  >
> 
> Added MPAM table header, MSC and Resource Node info structures
> 
> Signed-off-by: Swatisri Kantamsetti  >
> ---
> MdePkg/Include/IndustryStandard/Acpi64.h |  5 ++
> MdePkg/Include/IndustryStandard/Mpam.h   | 69
> 
> 2 files changed, 74 insertions(+)
> create mode 100644 MdePkg/Include/IndustryStandard/Mpam.h
> 
> diff --git a/MdePkg/Include/IndustryStandard/Acpi64.h
> b/MdePkg/Include/IndustryStandard/Acpi64.h
> index fe5ebfac2b..e54f631186 100644
> --- a/MdePkg/Include/IndustryStandard/Acpi64.h
> +++ b/MdePkg/Include/IndustryStandard/Acpi64.h
> @@ -2952,6 +2952,11 @@ typedef struct {
> ///
> #define
> EFI_ACPI_6_4_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE_STRUCTURE_SI
> GNATURE  SIGNATURE_32('P', 'P', 'T', 'T')
> 
> +///
> +/// "MPAM" Memory System Resource Partitioning And Monitoring Table
> ///
> +#define
> +EFI_ACPI_6_4_MEMORY_SYSTEM_RESOURCE_PARTITIONING_MONITORI
> NG_TABLE_STRUC
> +TURE_SIGNATURE  SIGNATURE_32('M', 'P', 'A', 'M')
> +
> ///
> /// "PSDT" Persistent System Description Table  /// diff --git
> a/MdePkg/Include/IndustryStandard/Mpam.h
> b/MdePkg/Include/IndustryStandard/Mpam.h
> new file mode 100644
> index 00..e0f75f0114
> --- /dev/null
> +++ b/MdePkg/Include/IndustryStandard/Mpam.h
> @@ -0,0 +1,69 @@
> +/** @file
> +  ACPI Memory System Resource Partitioning And Monitoring (MPAM)
> +  as specified in ARM spec DEN0065
> +
> +  Copyright (c) 2022, NVIDIA CORPORATION. All rights reserved.
> +  Copyright (c) 2022, ARM Limited. All rights reserved.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent **/
> +
> +#ifndef _MPAM_H_
> +#define _MPAM_H_
> +
> +#pragma pack(1)
> +
> +///
> +/// Memory System Resource Partitioning and Monitoring Table (MPAM)
> ///
> +typedef struct {
> +  EFI_ACPI_DESCRIPTION_HEADERHeader;
> +  UINT32 NumNodes;
> +  UINT32 NodeOffset;
> +  UINT32 Reserved;
> +}
> +EFI_ACPI_6_4_MEMORY_SYSTEM_RESOURCE_PARTITIONING_MONITORI
> NG_TABLE_HEADE
> +R;
> 
> [Rohit] Shouldn't the header be followed by MSC node body type as defined in 
> MPAM ACPI 1.0, section 2, table 3 - The MPAM table and section 2.1, table 4 - 
> MSC Node body?
> 
> 
> +
> +///
> +/// MPAM Revision (as defined in ACPI 6.4 spec.) /// #define
> +EFI_ACPI_6_4_MEMORY_SYSTEM_RESOURCE_PARTITIONING_MONITORI
> NG_TABLE_REVIS
> +ION  0x01
> +
> +///
> +/// Memory System Controller Node Structure ///
> +
> +typedef struct {
> +  UINT16Length;
> +  UINT16Reserved;
> +  UINT32Identifier;
> +  UINT64BaseAddress;
> +  UINT32MmioSize;
> +  UINT32OverflowInterrupt;
> +  UINT32OverflowInterruptFlags;
> 
> [Rohit] Would it be better to have a type (possibly bitfield struct) instead 
> of a plain UINT32 for Flags? (MPAM ACPI 1.0, section 2.1.1, table 5 - 
> Interrupt flags)
> 
>  
> Probably 

Re: [edk2-devel] [PATCH 1/2] Mde Pkg: Support for MPAM ACPI Table

[Andrew Fish via groups.io]

> On Aug 19, 2022, at 1:26 AM, Rohit Mathew  wrote:
> 
> Hi Swatisri,
> 
> Thanks for the patch. Please find my comments inline marked [Rohit] -
> 
>> -Original Message-
>> From: devel@edk2.groups.io  
>> mailto:devel@edk2.groups.io>> On Behalf Of Name
>> via groups.io 
>> Sent: 16 August 2022 21:18
>> To: devel@edk2.groups.io ; Sami Mujawar 
>> mailto:sami.muja...@arm.com>>;
>> Alexei Fedorov mailto:alexei.fedo...@arm.com>>; 
>> michael.d.kin...@intel.com ;
>> gaolim...@byosoft.com.cn ; 
>> zhiguang@intel.com 
>> Cc: Swatisri Kantamsetti mailto:swatis...@nvidia.com>>
>> Subject: [edk2-devel] [PATCH 1/2] Mde Pkg: Support for MPAM ACPI Table
>> 
>> From: Swatisri Kantamsetti 
>> 
>> Added MPAM table header, MSC and Resource Node info structures
>> 
>> Signed-off-by: Swatisri Kantamsetti 
>> ---
>> MdePkg/Include/IndustryStandard/Acpi64.h |  5 ++
>> MdePkg/Include/IndustryStandard/Mpam.h   | 69
>> 
>> 2 files changed, 74 insertions(+)
>> create mode 100644 MdePkg/Include/IndustryStandard/Mpam.h
>> 
>> diff --git a/MdePkg/Include/IndustryStandard/Acpi64.h
>> b/MdePkg/Include/IndustryStandard/Acpi64.h
>> index fe5ebfac2b..e54f631186 100644
>> --- a/MdePkg/Include/IndustryStandard/Acpi64.h
>> +++ b/MdePkg/Include/IndustryStandard/Acpi64.h
>> @@ -2952,6 +2952,11 @@ typedef struct {
>> ///
>> #define
>> EFI_ACPI_6_4_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE_STRUCTURE_SI
>> GNATURE  SIGNATURE_32('P', 'P', 'T', 'T')
>> 
>> +///
>> +/// "MPAM" Memory System Resource Partitioning And Monitoring Table
>> ///
>> +#define
>> +EFI_ACPI_6_4_MEMORY_SYSTEM_RESOURCE_PARTITIONING_MONITORI
>> NG_TABLE_STRUC
>> +TURE_SIGNATURE  SIGNATURE_32('M', 'P', 'A', 'M')
>> +
>> ///
>> /// "PSDT" Persistent System Description Table  /// diff --git
>> a/MdePkg/Include/IndustryStandard/Mpam.h
>> b/MdePkg/Include/IndustryStandard/Mpam.h
>> new file mode 100644
>> index 00..e0f75f0114
>> --- /dev/null
>> +++ b/MdePkg/Include/IndustryStandard/Mpam.h
>> @@ -0,0 +1,69 @@
>> +/** @file
>> +  ACPI Memory System Resource Partitioning And Monitoring (MPAM)
>> +  as specified in ARM spec DEN0065
>> +
>> +  Copyright (c) 2022, NVIDIA CORPORATION. All rights reserved.
>> +  Copyright (c) 2022, ARM Limited. All rights reserved.
>> +  SPDX-License-Identifier: BSD-2-Clause-Patent **/
>> +
>> +#ifndef _MPAM_H_
>> +#define _MPAM_H_
>> +
>> +#pragma pack(1)
>> +
>> +///
>> +/// Memory System Resource Partitioning and Monitoring Table (MPAM)
>> ///
>> +typedef struct {
>> +  EFI_ACPI_DESCRIPTION_HEADERHeader;
>> +  UINT32 NumNodes;
>> +  UINT32 NodeOffset;
>> +  UINT32 Reserved;
>> +}
>> +EFI_ACPI_6_4_MEMORY_SYSTEM_RESOURCE_PARTITIONING_MONITORI
>> NG_TABLE_HEADE
>> +R;
> 
> [Rohit] Shouldn't the header be followed by MSC node body type as defined in 
> MPAM ACPI 1.0, section 2, table 3 - The MPAM table and section 2.1, table 4 - 
> MSC Node body?
> 
>> +
>> +///
>> +/// MPAM Revision (as defined in ACPI 6.4 spec.) /// #define
>> +EFI_ACPI_6_4_MEMORY_SYSTEM_RESOURCE_PARTITIONING_MONITORI
>> NG_TABLE_REVIS
>> +ION  0x01
>> +
>> +///
>> +/// Memory System Controller Node Structure ///
>> +
>> +typedef struct {
>> +  UINT16Length;
>> +  UINT16Reserved;
>> +  UINT32Identifier;
>> +  UINT64BaseAddress;
>> +  UINT32MmioSize;
>> +  UINT32OverflowInterrupt;
>> +  UINT32OverflowInterruptFlags;
> 
> [Rohit] Would it be better to have a type (possibly bitfield struct) instead 
> of a plain UINT32 for Flags? (MPAM ACPI 1.0, section 2.1.1, table 5 - 
> Interrupt flags)
> 

Probably better NOT to use bitfields in APIs that are produced and consumed by 
different worlds. While the the UEFI does speak to the bit order of or a 
bitfield the rules around packing of bitfields is compiler defined.

I just saw a bug last week with bitfield compatibility that was introduced by 
clang fixing its -mms-bitfields implementation. The GCC rules for packing 
bitfields is different than VC++ so that is why the compiler flag 
-mms-bitfields exists in the 1st place . A clang -mms-bitfields bug  got fixed 
and it broke the code as the extra padding required by VC++ got added to the 
bitfield. 

Thanks,

Andrew Fish

>> +  UINT32Reserved1;
>> +  UINT32OverflowInterruptAff;
>> +  UINT32ErrorInterrupt;
>> +  UINT32ErrorInterruptFlags;
> 
> [Rohit ] Same comment as before above.
> 
>> +  UINT32Reserved2;
>> +  UINT32ErrorInterruptAff;
>> +  UINT32MaxNRdyUsec;
>> +  UINT64LinkedDeviceHwId;
>> +  UINT32LinkedDeviceInstanceHwId;
>> +  UINT32NumResourceNodes;
>> +} EFI_ACPI_6_4_MPAM_MSC_NODE;
>> +
>> +///
>> +/// Resource Node Structure
>> +///
>> +
>> +typedef struct {
>> +  UINT32Identifier;
>> +  UINT8 RisIndex;
>> +  UINT16

Re: [edk2-devel] Building C static Library for UEFI

[Andrew Fish via groups.io]

Did you figure this out?

The per compiler flags come from BaseTools/Conf/tools_def.template. When you do 
the edksetup.sh it gets copied to Conf/tools_def.ttxt and that is what the 
build uses. The rules to generate makefiles come from 
BaseTools/Conf/build_rule.template[2] and gets copied to Conf/build_rule.txt

You can override the generic compiler flags via a [BuildOptions] section in an 
INF [3] of DSC [4]. 

[1] 
https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/tools_def.template
[2] 
https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/build_rule.template
[3] 
https://github.com/tianocore/edk2/blob/master/UnitTestFrameworkPkg/Library/CmockaLib/CmockaLib.inf#L28
 
[4] https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.dsc#L111


Thanks,

Andrew Fish


> On Jul 30, 2022, at 7:25 AM, Ayush Singh  wrote:
> 
> Hello everyone. There are some tests in Rust std that statically link to a C 
> static library to check ffi. Since if Rust is ever used in edk2, it would 
> probably have to integrate with the existing C code. Thus, I thought rather 
> than ignoring these tests, I wanted to make them work.
> 
> What Rust cargo needs is a static C library (`.lib`) to link against. I was 
> not really able to find much about linking in UEFI applications. However, 
> from what I understand [1], edk2 already does do static link for C modules, 
> so it should technically be the same for Rust as well as long as a static 
> library can be generated from C code. I did look at the `build_rules` [2], 
> but I don't know where the flags are defined. I think following rules: 
> `C-Code-File` -> `Object-File` should technically create a static library, 
> but would it work with projects outside edk2? Also, it would be great if 
> someone can also help me with the flags that need to be supplied if it can.
> 
> 
> 
> Yours Sincerely
> 
> Ayush Singh
> 
> 
> 
> [1]: 
> https://edk2-docs.gitbook.io/edk-ii-build-specification/9_build_or_make_stage/95_dynamic_link
> 
> [2]: 
> https://github.com/tianocore/edk2/blob/e9150618ec91f79e70a1719ac8c198bee34a99be/BaseTools/Conf/build_rule.template
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92256): https://edk2.groups.io/g/devel/message/92256
Mute This Topic: https://groups.io/mt/92710725/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Casting i128 into f64 in UEFI Rust pagefaults

[Andrew Fish via groups.io]

gt;>  %rax, %rdx
>> hello_world_std.efi[0x140001b6c]: 48 31 c1 xorq  
>>  %rax, %rcx
>> hello_world_std.efi[0x140001b6f]: 48 31 c2 xorq  
>>  %rax, %rdx
>> hello_world_std.efi[0x140001b72]: 48 be 00 00 00 00 00 00 00 80
>> movabsq $-0x8000, %rsi ; imm = 0x8000 
>> hello_world_std.efi[0x140001b7c]: 4c 21 c6 andq  
>>  %r8, %rsi
>> hello_world_std.efi[0x140001b7f]: e8 5c 55 00 00   callq 
>>  0x1400070e0
>> hello_world_std.efi[0x140001b84]: 48 09 f0 orq   
>>  %rsi, %rax
>> hello_world_std.efi[0x140001b87]: 48 83 c4 20  addq  
>>  $0x20, %rsp
>> hello_world_std.efi[0x140001b8b]: 5e   popq  
>>  %rsi
>> hello_world_std.efi[0x140001b8c]: c3   retq  
>>  
>> 
>> So the faulting function is getting passed a bad pointer as its 1st arg. 
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> On Jul 25, 2022, at 11:45 AM, Andrew Fish  
>>> <mailto:af...@apple.com> wrote:
>>> 
>>> Ops… Looks like your PE/COFF is linked at 0x00014000, so 
>>> 0x140001b60 is the interesting bit.
>>> 
>>> (lldb) dis -s 0x000140001B60 -b
>>> hello_world_std.efi[0x140001b60]: 48 8b 09   movq   
>>> (%rcx), %rcx
>>> hello_world_std.efi[0x140001b63]: 48 01 c1   addq   
>>> %rax, %rcx
>>> hello_world_std.efi[0x140001b66]: 4c 89 c2   movq   
>>> %r8, %rdx
>>> hello_world_std.efi[0x140001b69]: 48 11 c2   adcq   
>>> %rax, %rdx
>>> hello_world_std.efi[0x140001b6c]: 48 31 c1   xorq   
>>> %rax, %rcx
>>> hello_world_std.efi[0x140001b6f]: 48 31 c2   xorq   
>>> %rax, %rdx
>>> hello_world_std.efi[0x140001b72]: 48 be 00 00 00 00 00 00 00 80  movabsq 
>>> $-0x8000, %rsi ; imm = 0x8000 
>>> hello_world_std.efi[0x140001b7c]: 4c 21 c6   andq   
>>> %r8, %rsi
>>> 
>>>  RCX - 
>>> 
>>> So yea that looks like the fault. 
>>> 
>>> I don’t see that pattern in your .s file…. 
>>> 
>>> Can you figure out what function is @ 0x140001b60 in the PE/COFF image. Do 
>>> you have a map file from the linker?
>>> 
>>> Thanks,
>>> 
>>> Andrew Fish
>>> 
>>> PS Again sorry I don’t have anything installed to crack PDB files. 
>>> 
>>> Thanks,
>>> 
>>> Andrew Fish
>>> 
>>>> On Jul 25, 2022, at 10:51 AM, Andrew Fish via groups.io 
>>>>  <mailto:afish=apple@groups.io> wrote:
>>>> 
>>>> Ayush,
>>>> 
>>>> CR2 is the fault address so 0x. Given for EFI Virt == 
>>>> Physical the fault address looks like a bad pointer. 
>>>> 
>>>> Sorry I’ve not used VC++ in a long time so I don’t know how to debug with 
>>>> VC++, but If I was using clang/lldb I’d look at the source and assembly 
>>>> for the fault address. 
>>>> 
>>>> The image base is: 0x0603C000
>>>> The fault PC/RIP is: 0603DB60
>>>> 
>>>> So the faulting code is at 0x1B60 in the image. Given the images are 
>>>> linked at zero you should be able to load the build product into the 
>>>> debugger and look at what code is at offset 0x1B60. The same should work 
>>>> for any tools that dump the binary. 
>>>> 
>>>> Thanks,
>>>> 
>>>> Andrew Fish
>>>> 
>>>>> On Jul 25, 2022, at 10:33 AM, Ayush Singh  
>>>>> <mailto:ayushdevel1...@gmail.com> wrote:
>>>>> 
>>>>> Hello everyone.While running Rust tests in UEFI environment, I have come 
>>>>> across a numeric test that causes a pagefault. A simple reproducible 
>>>>> example for this is given below:
>>>>> 
>>>>> ```rust
>>>>> 
>>>>> fn main() {
>>>>> use std::hint::black_box as b;
>>>>> 
>>>>> let z: i128 = b(1);
>>>>> assert!((-z as f64) < 0.0);
>>>>> }
>>>>> 
>>>>> ```
>>>>> 
>>>>> 
>>>

Re: [edk2-devel] [Patch v3 3/3] Maintainers.txt: Remove reviewer Harry Han

[Andrew Fish via groups.io]

Reviewed-by: Andrew Fish 

> On Jul 21, 2022, at 2:07 PM, Michael D Kinney  
> wrote:
> 
> Cc: Harry Han 
> Cc: Andrew Fish 
> Cc: Leif Lindholm 
> Signed-off-by: Michael D Kinney 
> Reviewed-by: Harry Han 
> ---
> Maintainers.txt | 2 --
> 1 file changed, 2 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index bc7caa12d8d9..0ea6b4041654 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -372,7 +372,6 @@ F: MdeModulePkg/Core/Pei/
> R: Dandan Bi  [dandanbi]
> R: Liming Gao  [lgao4]
> R: Debkumar De  [dde01]
> -R: Harry Han 
> R: Catharine West  [catharine-intl]
> 
> MdeModulePkg: Reset modules
> @@ -603,7 +602,6 @@ UefiCpuPkg: Sec related modules
> F: UefiCpuPkg/SecCore/
> F: UefiCpuPkg/ResetVector/
> R: Debkumar De  [dde01]
> -R: Harry Han 
> R: Catharine West  [catharine-intl]
> 
> UefiPayloadPkg
> -- 
> 2.32.0.windows.1
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#91823): https://edk2.groups.io/g/devel/message/91823
Mute This Topic: https://groups.io/mt/92535867/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v3 0/3] Update Maintainers.txt

[Andrew Fish via groups.io]

Reviewed-by: Andrew Fish 

> On Jul 21, 2022, at 2:07 PM, Michael D Kinney  
> wrote:
> 
> Cc: Anthony Perard 
> Cc: Julien Grall 
> Cc: Daniel Schaefer 
> Cc: Sean Rhodes 
> Cc: Debkumar De 
> Cc: Erdem Aktas 
> Cc: Harry Han 
> Cc: Gary Lin 
> Cc: Andrew Fish 
> Cc: Leif Lindholm 
> Signed-off-by: Michael D Kinney 
> 
> Michael D Kinney (3):
>  Maintainers.txt: Remove OvmfPkg/XenTimerDxe reference
>  Maintainers.txt: Add missing github ids
>  Maintainers.txt: Remove reviewer Harry Han
> 
> Maintainers.txt | 19 ---
> 1 file changed, 8 insertions(+), 11 deletions(-)
> 
> -- 
> 2.32.0.windows.1
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#91822): https://edk2.groups.io/g/devel/message/91822
Mute This Topic: https://groups.io/mt/92535864/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Casting i128 into f64 in UEFI Rust pagefaults

[Andrew Fish via groups.io]

I guess I could at least dump to the end (req)…. Going backwards is a bit 
painful in x86. 

(lldb) dis -s 0x000140001B60 -b -c 30
hello_world_std.efi[0x140001b60]: 48 8b 09   movq   (%rcx), 
%rcx
hello_world_std.efi[0x140001b63]: 48 01 c1   addq   %rax, 
%rcx
hello_world_std.efi[0x140001b66]: 4c 89 c2   movq   %r8, 
%rdx
hello_world_std.efi[0x140001b69]: 48 11 c2   adcq   %rax, 
%rdx
hello_world_std.efi[0x140001b6c]: 48 31 c1   xorq   %rax, 
%rcx
hello_world_std.efi[0x140001b6f]: 48 31 c2   xorq   %rax, 
%rdx
hello_world_std.efi[0x140001b72]: 48 be 00 00 00 00 00 00 00 80  movabsq 
$-0x8000, %rsi ; imm = 0x8000 
hello_world_std.efi[0x140001b7c]: 4c 21 c6   andq   %r8, 
%rsi
hello_world_std.efi[0x140001b7f]: e8 5c 55 00 00 callq  
0x1400070e0
hello_world_std.efi[0x140001b84]: 48 09 f0   orq%rsi, 
%rax
hello_world_std.efi[0x140001b87]: 48 83 c4 20addq   $0x20, 
%rsp
hello_world_std.efi[0x140001b8b]: 5e popq   %rsi
hello_world_std.efi[0x140001b8c]: c3 retq   
hello_world_std.efi[0x140001b8d]: cc int3   
hello_world_std.efi[0x140001b8e]: cc int3   
hello_world_std.efi[0x140001b8f]: cc int3   
hello_world_std.efi[0x140001b90]: e9 db 55 00 00 jmp
0x140007170
hello_world_std.efi[0x140001b95]: cc int3   
…

Then we can guess based on how functions get aligned to find the start….

hello_world_std.efi[0x140001b50]: 56   pushq  
%rsi
hello_world_std.efi[0x140001b51]: 48 83 ec 20  subq   
$0x20, %rsp
hello_world_std.efi[0x140001b55]: 4c 8b 41 08  movq   
0x8(%rcx), %r8
hello_world_std.efi[0x140001b59]: 4c 89 c0 movq   
%r8, %rax
hello_world_std.efi[0x140001b5c]: 48 c1 f8 3f  sarq   
$0x3f, %rax
hello_world_std.efi[0x140001b60]: 48 8b 09 movq   
(%rcx), %rcx
hello_world_std.efi[0x140001b63]: 48 01 c1 addq   
%rax, %rcx
hello_world_std.efi[0x140001b66]: 4c 89 c2 movq   
%r8, %rdx
hello_world_std.efi[0x140001b69]: 48 11 c2 adcq   
%rax, %rdx
hello_world_std.efi[0x140001b6c]: 48 31 c1 xorq   
%rax, %rcx
hello_world_std.efi[0x140001b6f]: 48 31 c2 xorq   
%rax, %rdx
hello_world_std.efi[0x140001b72]: 48 be 00 00 00 00 00 00 00 80movabsq 
$-0x8000, %rsi ; imm = 0x8000 
hello_world_std.efi[0x140001b7c]: 4c 21 c6 andq   
%r8, %rsi
hello_world_std.efi[0x140001b7f]: e8 5c 55 00 00   callq  
0x1400070e0
hello_world_std.efi[0x140001b84]: 48 09 f0 orq
%rsi, %rax
hello_world_std.efi[0x140001b87]: 48 83 c4 20  addq   
$0x20, %rsp
hello_world_std.efi[0x140001b8b]: 5e   popq   
%rsi
hello_world_std.efi[0x140001b8c]: c3   retq   

So the faulting function is getting passed a bad pointer as its 1st arg. 

Thanks,

Andrew Fish

> On Jul 25, 2022, at 11:45 AM, Andrew Fish  wrote:
> 
> Ops… Looks like your PE/COFF is linked at 0x00014000, so 0x140001b60 
> is the interesting bit.
> 
> (lldb) dis -s 0x000140001B60 -b
> hello_world_std.efi[0x140001b60]: 48 8b 09   movq   
> (%rcx), %rcx
> hello_world_std.efi[0x140001b63]: 48 01 c1   addq   %rax, 
> %rcx
> hello_world_std.efi[0x140001b66]: 4c 89 c2   movq   %r8, 
> %rdx
> hello_world_std.efi[0x140001b69]: 48 11 c2   adcq   %rax, 
> %rdx
> hello_world_std.efi[0x140001b6c]: 48 31 c1   xorq   %rax, 
> %rcx
> hello_world_std.efi[0x140001b6f]: 48 31 c2   xorq   %rax, 
> %rdx
> hello_world_std.efi[0x140001b72]: 48 be 00 00 00 00 00 00 00 80  movabsq 
> $-0x8000, %rsi ; imm = 0x8000 
> hello_world_std.efi[0x140001b7c]: 4c 21 c6   andq   %r8, 
> %rsi
> 
>  RCX - 
> 
> So yea that looks like the fault. 
> 
> I don’t see that pattern in your .s file…. 
> 
> Can you figure out what function is @ 0x140001b60 in the PE/COFF image. Do 
> you have a map file from the linker?
> 
> Thanks,
> 
> Andrew Fish
> 
> PS Again sorry I don’t have anything installed to crack PDB files. 
> 
> Thanks,
> 
> Andrew Fish
> 
>> On Jul 25, 2022, at 10:51 AM, Andrew Fish via groups.io 
>>  wrote:

Re: [edk2-devel] Casting i128 into f64 in UEFI Rust pagefaults

[Andrew Fish via groups.io]

Ops… Looks like your PE/COFF is linked at 0x00014000, so 0x140001b60 is 
the interesting bit.

(lldb) dis -s 0x000140001B60 -b
hello_world_std.efi[0x140001b60]: 48 8b 09   movq   (%rcx), 
%rcx
hello_world_std.efi[0x140001b63]: 48 01 c1   addq   %rax, 
%rcx
hello_world_std.efi[0x140001b66]: 4c 89 c2   movq   %r8, 
%rdx
hello_world_std.efi[0x140001b69]: 48 11 c2   adcq   %rax, 
%rdx
hello_world_std.efi[0x140001b6c]: 48 31 c1   xorq   %rax, 
%rcx
hello_world_std.efi[0x140001b6f]: 48 31 c2   xorq   %rax, 
%rdx
hello_world_std.efi[0x140001b72]: 48 be 00 00 00 00 00 00 00 80  movabsq 
$-0x8000, %rsi ; imm = 0x8000 
hello_world_std.efi[0x140001b7c]: 4c 21 c6   andq   %r8, 
%rsi

 RCX - 

So yea that looks like the fault. 

I don’t see that pattern in your .s file…. 

Can you figure out what function is @ 0x140001b60 in the PE/COFF image. Do you 
have a map file from the linker?

Thanks,

Andrew Fish

PS Again sorry I don’t have anything installed to crack PDB files. 

Thanks,

Andrew Fish

> On Jul 25, 2022, at 10:51 AM, Andrew Fish via groups.io 
>  wrote:
> 
> Ayush,
> 
> CR2 is the fault address so 0x. Given for EFI Virt == 
> Physical the fault address looks like a bad pointer. 
> 
> Sorry I’ve not used VC++ in a long time so I don’t know how to debug with 
> VC++, but If I was using clang/lldb I’d look at the source and assembly for 
> the fault address. 
> 
> The image base is: 0x0603C000
> The fault PC/RIP is: 0603DB60
> 
> So the faulting code is at 0x1B60 in the image. Given the images are linked 
> at zero you should be able to load the build product into the debugger and 
> look at what code is at offset 0x1B60. The same should work for any tools 
> that dump the binary. 
> 
> Thanks,
> 
> Andrew Fish
> 
>> On Jul 25, 2022, at 10:33 AM, Ayush Singh  wrote:
>> 
>> Hello everyone.While running Rust tests in UEFI environment, I have come 
>> across a numeric test that causes a pagefault. A simple reproducible example 
>> for this is given below:
>> 
>> ```rust
>> 
>> fn main() {
>> use std::hint::black_box as b;
>> 
>> let z: i128 = b(1);
>> assert!((-z as f64) < 0.0);
>> }
>> 
>> ```
>> 
>> 
>> The exception output is as follows:
>> 
>> ```
>> 
>>  X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID -  
>> ExceptionData -   I:0 R:0 U:0 W:0 P:0 PK:0 SS:0 SGX:0
>> RIP  - 0603DB60, CS  - 0038, RFLAGS - 0246
>> RAX  - , RCX - , RDX - 
>> RBX  - , RSP - 07EDF1D0, RBP - 07EDF4C0
>> RSI  - 07EDF360, RDI - 07EDF3C0
>> R8   - , R9  - 0038, R10 - 
>> R11  - , R12 - 060C6018, R13 - 07EDF520
>> R14  - 07EDF6A8, R15 - 05FA9490
>> DS   - 0030, ES  - 0030, FS  - 0030
>> GS   - 0030, SS  - 0030
>> CR0  - 80010033, CR2 - , CR3 - 07C01000
>> CR4  - 0668, CR8 - 
>> DR0  - , DR1 - , DR2 - 
>> DR3  - , DR6 - 0FF0, DR7 - 0400
>> GDTR - 079DE000 0047, LDTR - 
>> IDTR - 07418018 0FFF,   TR - 
>> FXSAVE_STATE - 07EDEE30
>>  Find image based on IP(0x603DB60) 
>> /var/home/ayush/Documents/Programming/Rust/uefi/hello_world_std/target/x86_64-unknown-uefi/debug/deps/hello_world_std-338028f9369e2d42.pdb
>>  (ImageBase=0603C000, EntryPoint=0603D8C0) 
>> 
>> ```
>> 
>> 
>> From my testing, the exception only occurs when a few conditions are met.
>> 
>> 1. The binary is compiled in Debug mode. No error in Release mode.
>> 
>> 2. `i128` is in a black_box [1]. Does not occur if `black_box` is not 
>> present.
>> 
>> 3. It has to be `i128`. `i64` or something else work fine.
>> 
>> 4. The cast has to be done on `-z`. Doing the same with `+z` is fine.
>> 
>> 
>> I have also been discussing this in the Rust zulipchat [2], so feel free to 
>> chime in there.
>> 
>> 
>> Additionally, here are links for more information about this program:
>> 
>> 1. Assembly: 
>> https://rust-la

Re: [edk2-devel] Casting i128 into f64 in UEFI Rust pagefaults

[Andrew Fish via groups.io]

Ayush,

CR2 is the fault address so 0x. Given for EFI Virt == Physical 
the fault address looks like a bad pointer. 

Sorry I’ve not used VC++ in a long time so I don’t know how to debug with VC++, 
but If I was using clang/lldb I’d look at the source and assembly for the fault 
address. 

The image base is: 0x0603C000
The fault PC/RIP is: 0603DB60

So the faulting code is at 0x1B60 in the image. Given the images are linked at 
zero you should be able to load the build product into the debugger and look at 
what code is at offset 0x1B60. The same should work for any tools that dump the 
binary. 

Thanks,

Andrew Fish

> On Jul 25, 2022, at 10:33 AM, Ayush Singh  wrote:
> 
> Hello everyone.While running Rust tests in UEFI environment, I have come 
> across a numeric test that causes a pagefault. A simple reproducible example 
> for this is given below:
> 
> ```rust
> 
> fn main() {
> use std::hint::black_box as b;
> 
> let z: i128 = b(1);
> assert!((-z as f64) < 0.0);
> }
> 
> ```
> 
> 
> The exception output is as follows:
> 
> ```
> 
>  X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID -  
> ExceptionData -   I:0 R:0 U:0 W:0 P:0 PK:0 SS:0 SGX:0
> RIP  - 0603DB60, CS  - 0038, RFLAGS - 0246
> RAX  - , RCX - , RDX - 
> RBX  - , RSP - 07EDF1D0, RBP - 07EDF4C0
> RSI  - 07EDF360, RDI - 07EDF3C0
> R8   - , R9  - 0038, R10 - 
> R11  - , R12 - 060C6018, R13 - 07EDF520
> R14  - 07EDF6A8, R15 - 05FA9490
> DS   - 0030, ES  - 0030, FS  - 0030
> GS   - 0030, SS  - 0030
> CR0  - 80010033, CR2 - , CR3 - 07C01000
> CR4  - 0668, CR8 - 
> DR0  - , DR1 - , DR2 - 
> DR3  - , DR6 - 0FF0, DR7 - 0400
> GDTR - 079DE000 0047, LDTR - 
> IDTR - 07418018 0FFF,   TR - 
> FXSAVE_STATE - 07EDEE30
>  Find image based on IP(0x603DB60) 
> /var/home/ayush/Documents/Programming/Rust/uefi/hello_world_std/target/x86_64-unknown-uefi/debug/deps/hello_world_std-338028f9369e2d42.pdb
>  (ImageBase=0603C000, EntryPoint=0603D8C0) 
> 
> ```
> 
> 
> From my testing, the exception only occurs when a few conditions are met.
> 
> 1. The binary is compiled in Debug mode. No error in Release mode.
> 
> 2. `i128` is in a black_box [1]. Does not occur if `black_box` is not present.
> 
> 3. It has to be `i128`. `i64` or something else work fine.
> 
> 4. The cast has to be done on `-z`. Doing the same with `+z` is fine.
> 
> 
> I have also been discussing this in the Rust zulipchat [2], so feel free to 
> chime in there.
> 
> 
> Additionally, here are links for more information about this program:
> 
> 1. Assembly: 
> https://rust-lang.zulipchat.com/user_uploads/4715/od51Y9Dkfjahcg9HHcOud8Fm/hello_world_std-338028f9369e2d42.s
> 
> 2. EFI Binary: 
> https://rust-lang.zulipchat.com/user_uploads/4715/CknqtXLR8SaJZmyOnXctQkpL/hello_world_std.efi
> 
> 3. PDB file: 
> https://rust-lang.zulipchat.com/user_uploads/4715/zV4i6DsjgQXotp_gS1naEsU0/hello_world_std-338028f9369e2d42.pdb
> 
> 
> Yours Sincerely,
> 
> Ayush Singh
> 
> 
> [1]: https://doc.rust-lang.org/std/hint/fn.black_box.html
> 
> [2]: 
> https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Casting.20i128.20to.20f64.20in.20black_box.20causes.20exception.20in.20UEFI
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#91819): https://edk2.groups.io/g/devel/message/91819
Mute This Topic: https://groups.io/mt/92610101/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Clarification of Memory management in PEI phase

[Andrew Fish via groups.io]

Brian,

I think all the PEI Allocate Pool does is make a HOB [1]. I don’t think we can 
remove HOBs when memory is freed as that would change  pointers to pool. It may 
be possible to mark a region as free and allocate from that list batch 1st, and 
just over allocate space if needed. It could be as simple as just adding a new 
HOB type to represent free pool. 


[1] 
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/Memory/MemoryServices.c#L878

Thanks,

Andrew Fish

> On Jun 22, 2022, at 12:39 PM, Brian J. Johnson  wrote:
> 
> Sorry for the late response to this thread...
> 
> PEI has grown greatly in complexity, as Andrew pointed out.  Do we (TianoCore 
> community) think it's time to add a real pool manager to PEI?  There's 
> getting to be quite a bit of post-DRAM-initialization PEI code on some 
> platforms.  And really, having a limited amount of pre-DRAM memory available 
> is an even better reason for having an effective pool allocator, so the 
> memory can be freed and reused.
> 
> FWIW we (HPE) needed to add a private pool allocator to manage memory for a 
> proprietary h/w initialization module which needs to run in post-DRAM PEI, 
> and depends on allocating and freeing memory in different phases of its 
> operation.
> 
> Brian J. Johnson
> 
> From: Ayush Singh [mailto:ayushdevel1...@gmail.com 
> ]
> Sent: Friday, June 10, 2022, 12:22 AM
> To: Andrew Fish  
> Cc: devel@edk2.groups.io 
> Subject: [edk2-devel] Clarification of Memory management in PEI phase
> 
>> Thanks for the wonderful answer. 
>> 
>> Ayush Singh
>> 
>> On Thu, Jun 9 2022 at 01:26:58 PM -0700, Andrew Fish  
>>  wrote:
>>> 
>>>  On Jun 9, 2022, at 10:28 AM, Ayush Singh >> wrote:
>>>  
>>>  Hello everyone,
>>>  
>>>  Can anyone help me with understanding dynamic memory management in PEI
>>>  phase? In the UEFI Platform Integration Specification, version 1.7
>>>  Errata A, Section 4.6, PEI Memory services are given which include:
>>>  
>>>  1. InstallPeiMemory()
>>> 
>>> This is basically:
>>> (*PeiServices)->InstallPeiMemory (PeiServices, MemoryBegin, MemoryLength);
>>> 
>>> This is how you tell the PEI Core the location of the memory that will can 
>>> be used in PEI. 
>>> 
>>>  2. AllocatePages()
>>>  3. AllocatePool()
>>>  4. CopyMem()
>>>  5. SetMem()
>>>  6. FreePages()
>>>  
>>>  However, no `FreePool()` service seems to be present. So how is the
>>>  memory allocated using `AllocatePool()` freed?
>>>  
>>> 
>>> It basically gets Freed when you transition to the DXE phase. 
>>> 
>>> To step back for a minute I think it is important to remember that the main 
>>> job of PEI is to initialize DRAM, and deal with S3 (resuming from suspend 
>>> to RAM). So as soon as you have DRAM you are kind done and ready for the 
>>> DXE IPL so you can load the DXE Phase and start up EFI. Remember PEI is Pre 
>>> EFI. The reality is programming DRAM is complex and lots of code got 
>>> written, then lots more code got written and PEI has become large for some 
>>> ports. That was never the intent. PEI is designed as a way to run C code 
>>> when you code is running from ROM and you donā��t have any DRAM. For x86 
>>> not having DRAM means you are using the cache as RAM. For some SoCs there 
>>> is actually an SRAM you can use. Thus the PEI memory allocation scheme is 
>>> designed to deal with this very constrained environment. 
>>> 
>>> You start PEI with a heap and stack. You can also allocate HOBs (Hand Off 
>>> Blocks). A pool allocation in PEI is just a HOB. See [1]. There is no way 
>>> to free a HOB. So the AllocatePool() kind of leaks into DXE too as an entry 
>>> in the HOB list. But when the OS called gBS->ExitBootServices() that frees 
>>> all non runtime memory back to the OS. 
>>> 
>>> If you look a AllocatePages/FreePages you will see AllocatePages creates a 
>>> HOB that points to the memory region, and FreePages just marks that HOB as 
>>> not used. That code is also in this file [1]. 
>>> 
>>> TL;DR there is no pool manager in PEI. 
>>> 
>>> [1] 
>>> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/Memory/MemoryServices.c#L878
>>>  
>>> 
>>> 
>>> 
>>> Thanks,
>>> 
>>> Andrew Fish
>>> 
>>>  Ayush Singh
>>>  
>>>  
>>>  
>>>  
>>>  
>>> 
>> 
>> 
> Brian
> 
> --
>"It's OK to be stuck.  99% of the time in your own [research] work, 
> you're stuck."
>-- Mark Lawrence



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90698): https://edk2.groups.io/g/devel/message/90698
Mute This Topic: https://groups.io/mt/91651322/21656

Re: [edk2-devel] Aurora build failure

[Andrew Fish via groups.io]

I’m guessing all the CI testing is on Python 3.8.x

I noticed one of the CI pipes is asking for Python 3.8 [1]

[1] 
https://github.com/tianocore/edk2/blob/master/.azurepipelines/Ubuntu-PatchCheck.yml

Thanks,

Andrew Fish


> On Jun 22, 2022, at 7:34 AM, Andrew (EFI) Fish  wrote:
> 
> That looks like an issue with using Python 3.9 as it changed tostring to 
> tobyte. 
> 
> Sent from my iPhone
> 
>> On Jun 22, 2022, at 7:25 AM, Shivraj Patil  wrote:
>> 
>> 
>> Hello,
>> I am observing the following failure while trying to build Aurora 
>> AU_LINUX_EMBEDDED_LE.PRODUCT.1.0_TARGET_ALL.01.318.215. Please have a look 
>> and provide a solution for the same.
>>  
>> (Python 3.9.4 on linux) Traceback (most recent call last):
>> |   File 
>> "/local/mnt3/workspace3/shivpati/Aurora/build-qti-distro-xr-debug/tmp-glibc/work/sxrneo-oe-linux/edk2/git-r0/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
>>  line 2596, in Main
>> | MyBuild.Launch()
>> |   File 
>> "/local/mnt3/workspace3/shivpati/Aurora/build-qti-distro-xr-debug/tmp-glibc/work/sxrneo-oe-linux/edk2/git-r0/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
>>  line 2391, in Launch
>> | self._MultiThreadBuildPlatform()
>> |   File 
>> "/local/mnt3/workspace3/shivpati/Aurora/build-qti-distro-xr-debug/tmp-glibc/work/sxrneo-oe-linux/edk2/git-r0/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
>>  line 2271, in _MultiThreadBuildPlatform
>> | self.CreateAsBuiltInf()
>> |   File 
>> "/local/mnt3/workspace3/shivpati/Aurora/build-qti-distro-xr-debug/tmp-glibc/work/sxrneo-oe-linux/edk2/git-r0/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
>>  line 2401, in CreateAsBuiltInf
>> | Module.CreateAsBuiltInf()
>> |   File 
>> "/local/mnt3/workspace3/shivpati/Aurora/build-qti-distro-xr-debug/tmp-glibc/work/sxrneo-oe-linux/edk2/git-r0/edk2/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py",
>>  line 1503, in CreateAsBuiltInf
>> | PatchList = parsePcdInfoFromMapFile(
>> |   File 
>> "/local/mnt3/workspace3/shivpati/Aurora/build-qti-distro-xr-debug/tmp-glibc/work/sxrneo-oe-linux/edk2/git-r0/edk2/BaseTools/Source/Python/GenPatchPcdTable/GenPatchPcdTable.py",
>>  line 56, in parsePcdInfoFromMapFile
>> | return _parseForGCC(lines, efifilepath)
>> |   File 
>> "/local/mnt3/workspace3/shivpati/Aurora/build-qti-distro-xr-debug/tmp-glibc/work/sxrneo-oe-linux/edk2/git-r0/edk2/BaseTools/Source/Python/GenPatchPcdTable/GenPatchPcdTable.py",
>>  line 113, in _parseForGCC
>> | efisecs = PeImageClass(efifilepath).SectionHeaderList
>> |   File 
>> "/local/mnt3/workspace3/shivpati/Aurora/build-qti-distro-xr-debug/tmp-glibc/work/sxrneo-oe-linux/edk2/git-r0/edk2/BaseTools/Source/Python/Common/Misc.py",
>>  line 1638, in __init__
>> | if ByteArray.tostring() != b'PE\0\0':
>> | AttributeError: 'array.array' object has no attribute 'tostring'
>>  
>>  
>> Thanks & Regards,
>> Shivraj Patil
>> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90697): https://edk2.groups.io/g/devel/message/90697
Mute This Topic: https://groups.io/mt/91922911/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] BaseTools: Suppress read only relocs errors on XCODE5 X64 toolchain

[Andrew Fish via groups.io]

> On Jun 22, 2022, at 10:43 AM, Marvin Häuser  wrote:
> 
> Hey Andrew,
> 
> thanks for verifying! If my last mail was not clear, this is already done for 
> IA32 builds, by the way. I suspect more trouble appeared there due to the 
> lack of IP-relative addressing.
> 

I though the issue was on x86_64 since by default that does not support 
relocations in .text sections. The maintainer mentioned this should work for 
x86_64 but is not really tested. If it works in our case we should be good to 
go. The compiler always generates RIP relative addressing in the text section. 
It is humans that generate absolution addressing by trying to access labels 
directly. 

I tested the change the flags on some some existing code bases and booted on 
real hardware and in a VM. I did not force a relocation into a text section, I 
just tested existing platforms as is.

Historically what would happen is any assembler that generated a relocation in 
the .text section would fail to link with Xcode and we would have to convert it 
to RIP relative addressing after the fact. 

Thanks,

Andrew Fish

> Theo wanted to prepare a V2 with an enhanced commit message and a 2nd patch 
> to remove the related hacks, I believe.
> 
> Best regards,
> Marvin
> 
>> On 22. Jun 2022, at 19:22, Andrew Fish  wrote:
>> 
>> I reached out to the Xcode ld64 maintainer to make sure it is safe to use 
>> -read_only_relocs suppress this way. 
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> On Jun 18, 2022, at 8:19 PM, Andrew Fish via groups.io 
>>>  wrote:
>>> 
>>> Marvin,
>>> 
>>> I’ll look into this.
>>> 
>>> The history here is the original ld64 flags are what was required for 
>>> proper function. I got them
>>> directly from the main ld64 maintainer. 
>>> 
>>> Big picture ld64 is the macOS and iOS linker, and it does not have official 
>>> support for other targets, especially embedded. So the combination of flags 
>>> are what was required for correctness as not all combination of possible 
>>> ld64 flags are actually supported.
>>> 
>>> Back in the day we made clang open source contributions to get EFIABI 
>>> supported in clang, but we have always used the stock ld64, with help from 
>>> the author.
>>>>> On Jun 18, 2022, at 8:03 PM, Marvin Häuser  wrote:
>>>> 
>>>> CC Andrew, Rebecca, mentors
>>>> 
>>>> Hey all,
>>>> 
>>>> The patch itself looks good to me. The description doesn't really capture 
>>>> the issue, nor why this is an adequate solution. This should also remove 
>>>> the mentioned XCODE5-specific code as part of a single series [1] to 
>>>> confirm the issue has been resolved without regressions.
>>>> 
>>>> TL;dr for the rest: Apple ld64 complains because there are relocations to 
>>>> read-only segments in a PIE executable. As Mach-O allows mapping read-only 
>>>> segments of PIEs to multiple virtual addresses (in different processes), 
>>>> this is prohibited right at link-time for obvious reasons. PE/COFF doesn't 
>>>> really have such a feature (I think Windows used to use static addresses 
>>>> and now uses CoW with traditional relocs?) and UEFI has no concept of page 
>>>> sharing anyway. Hence, it is safe to allow such relocs and silence the 
>>>> warning. All other toolchains should already work this way.
>>>> 
>>>> Andrew, Rebecca, if I remember correctly, you pretty much maintain XCODE5. 
>>>> I had a conversation with Andrew about related topics before, too. Are you 
>>>> fine with this approach? It seems like it has previously been applied to 
>>>> IA32 builds already anyway (right from import).
>>>> 
>>>> Maybe PIE could be dropped as a whole somehow in the future? For UEFI, it 
>>>> basically only adds overhead (or are there blockers to this?).
>>>> 
>>>> Best regards,
>>>> Marvin
>>>> 
>>>> [1] 
>>>> https://github.com/tianocore/edk2/tree/cc2db6ebfb6d9d85ba4c7b35fba1fa37fffc0bc2/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Xcode5ExceptionHandlerAsm.nasm
>>>> 
>>>>> On 18. Jun 2022, at 15:21, Théo Jehl  wrote:
>>>>> 
>>>>> From: Theo Jehl 
>>>>> 
>>>>> Added -read_only_relocs suppress for XCODE5 X64 toolchain
>>>>> This remove the needs for XCODE5 specific source with relocation fixes
>>>>> 
>>>>> Cc: Bob Feng 
>>>>> 

Re: [edk2-devel] [PATCH v1 1/1] BaseTools: Suppress read only relocs errors on XCODE5 X64 toolchain

[Andrew Fish via groups.io]

I reached out to the Xcode ld64 maintainer to make sure it is safe to use 
-read_only_relocs suppress this way. 

Thanks,

Andrew Fish

> On Jun 18, 2022, at 8:19 PM, Andrew Fish via groups.io 
>  wrote:
> 
> Marvin,
> 
> I’ll look into this.
> 
> The history here is the original ld64 flags are what was required for proper 
> function. I got them
> directly from the main ld64 maintainer. 
> 
> Big picture ld64 is the macOS and iOS linker, and it does not have official 
> support for other targets, especially embedded. So the combination of flags 
> are what was required for correctness as not all combination of possible ld64 
> flags are actually supported.
> 
> Back in the day we made clang open source contributions to get EFIABI 
> supported in clang, but we have always used the stock ld64, with help from 
> the author.
>> On Jun 18, 2022, at 8:03 PM, Marvin Häuser  wrote:
>> 
>> CC Andrew, Rebecca, mentors
>> 
>> Hey all,
>> 
>> The patch itself looks good to me. The description doesn't really capture 
>> the issue, nor why this is an adequate solution. This should also remove the 
>> mentioned XCODE5-specific code as part of a single series [1] to confirm the 
>> issue has been resolved without regressions.
>> 
>> TL;dr for the rest: Apple ld64 complains because there are relocations to 
>> read-only segments in a PIE executable. As Mach-O allows mapping read-only 
>> segments of PIEs to multiple virtual addresses (in different processes), 
>> this is prohibited right at link-time for obvious reasons. PE/COFF doesn't 
>> really have such a feature (I think Windows used to use static addresses and 
>> now uses CoW with traditional relocs?) and UEFI has no concept of page 
>> sharing anyway. Hence, it is safe to allow such relocs and silence the 
>> warning. All other toolchains should already work this way.
>> 
>> Andrew, Rebecca, if I remember correctly, you pretty much maintain XCODE5. I 
>> had a conversation with Andrew about related topics before, too. Are you 
>> fine with this approach? It seems like it has previously been applied to 
>> IA32 builds already anyway (right from import).
>> 
>> Maybe PIE could be dropped as a whole somehow in the future? For UEFI, it 
>> basically only adds overhead (or are there blockers to this?).
>> 
>> Best regards,
>> Marvin
>> 
>> [1] 
>> https://github.com/tianocore/edk2/tree/cc2db6ebfb6d9d85ba4c7b35fba1fa37fffc0bc2/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Xcode5ExceptionHandlerAsm.nasm
>> 
>>> On 18. Jun 2022, at 15:21, Théo Jehl  wrote:
>>> 
>>> From: Theo Jehl 
>>> 
>>> Added -read_only_relocs suppress for XCODE5 X64 toolchain
>>> This remove the needs for XCODE5 specific source with relocation fixes
>>> 
>>> Cc: Bob Feng 
>>> Cc: Liming Gao 
>>> Cc: Yuwei Chen 
>>> Cc: Marvin Häuser 
>>> Cc: Vitaly Cheptsov 
>>> 
>>> Signed-off-by: Theo Jehl 
>>> ---
>>> BaseTools/Conf/tools_def.template | 6 +++---
>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>> 
>>> diff --git a/BaseTools/Conf/tools_def.template 
>>> b/BaseTools/Conf/tools_def.template
>>> index 5ed19810b727..be35094cecc3 100755
>>> --- a/BaseTools/Conf/tools_def.template
>>> +++ b/BaseTools/Conf/tools_def.template
>>> @@ -2977,9 +2977,9 @@ RELEASE_XCODE5_IA32_CC_FLAGS   = -arch i386 -c-Os 
>>>   -Wall -Werror -inclu
>>> ##
>>> # X64 definitions
>>> ##
>>> -  DEBUG_XCODE5_X64_DLINK_FLAGS  = -arch x86_64 -u 
>>> _$(IMAGE_ENTRY_POINT) -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20  
>>> -pie -all_load -dead_strip -seg1addr 0x240 -map 
>>> $(DEST_DIR_DEBUG)/$(BASE_NAME).map
>>> -  NOOPT_XCODE5_X64_DLINK_FLAGS  = -arch x86_64 -u 
>>> _$(IMAGE_ENTRY_POINT) -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20  
>>> -pie -all_load -dead_strip -seg1addr 0x240 -map 
>>> $(DEST_DIR_DEBUG)/$(BASE_NAME).map
>>> -RELEASE_XCODE5_X64_DLINK_FLAGS  = -arch x86_64 -u 
>>> _$(IMAGE_ENTRY_POINT) -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20  
>>> -pie -all_load -dead_strip -seg1addr 0x240 -map 
>>> $(DEST_DIR_DEBUG)/$(BASE_NAME).map
>>> +  DEBUG_XCODE5_X64_DLINK_FLAGS  = -arch x86_64 -u 
>>> _$(IMAGE_ENTRY_POINT) -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20  
>>> -pie -all_load -dead_strip -seg1addr 0x240 -read_only_relocs suppress -map 
>>> $(DEST_DIR_DEBUG)/$(BASE_

Re: [edk2-devel] Aurora build failure

[Andrew Fish via groups.io]

That looks like an issue with using Python 3.9 as it changed tostring to 
tobyte. 
> On Jun 22, 2022, at 7:25 AM, Shivraj Patil  wrote:
> 
> 
> Hello,
> I am observing the following failure while trying to build Aurora 
> AU_LINUX_EMBEDDED_LE.PRODUCT.1.0_TARGET_ALL.01.318.215. Please have a look 
> and provide a solution for the same.
>  
> (Python 3.9.4 on linux) Traceback (most recent call last):
> |   File 
> "/local/mnt3/workspace3/shivpati/Aurora/build-qti-distro-xr-debug/tmp-glibc/work/sxrneo-oe-linux/edk2/git-r0/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
>  line 2596, in Main
> | MyBuild.Launch()
> |   File 
> "/local/mnt3/workspace3/shivpati/Aurora/build-qti-distro-xr-debug/tmp-glibc/work/sxrneo-oe-linux/edk2/git-r0/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
>  line 2391, in Launch
> | self._MultiThreadBuildPlatform()
> |   File 
> "/local/mnt3/workspace3/shivpati/Aurora/build-qti-distro-xr-debug/tmp-glibc/work/sxrneo-oe-linux/edk2/git-r0/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
>  line 2271, in _MultiThreadBuildPlatform
> | self.CreateAsBuiltInf()
> |   File 
> "/local/mnt3/workspace3/shivpati/Aurora/build-qti-distro-xr-debug/tmp-glibc/work/sxrneo-oe-linux/edk2/git-r0/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
>  line 2401, in CreateAsBuiltInf
> | Module.CreateAsBuiltInf()
> |   File 
> "/local/mnt3/workspace3/shivpati/Aurora/build-qti-distro-xr-debug/tmp-glibc/work/sxrneo-oe-linux/edk2/git-r0/edk2/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py",
>  line 1503, in CreateAsBuiltInf
> | PatchList = parsePcdInfoFromMapFile(
> |   File 
> "/local/mnt3/workspace3/shivpati/Aurora/build-qti-distro-xr-debug/tmp-glibc/work/sxrneo-oe-linux/edk2/git-r0/edk2/BaseTools/Source/Python/GenPatchPcdTable/GenPatchPcdTable.py",
>  line 56, in parsePcdInfoFromMapFile
> | return _parseForGCC(lines, efifilepath)
> |   File 
> "/local/mnt3/workspace3/shivpati/Aurora/build-qti-distro-xr-debug/tmp-glibc/work/sxrneo-oe-linux/edk2/git-r0/edk2/BaseTools/Source/Python/GenPatchPcdTable/GenPatchPcdTable.py",
>  line 113, in _parseForGCC
> | efisecs = PeImageClass(efifilepath).SectionHeaderList
> |   File 
> "/local/mnt3/workspace3/shivpati/Aurora/build-qti-distro-xr-debug/tmp-glibc/work/sxrneo-oe-linux/edk2/git-r0/edk2/BaseTools/Source/Python/Common/Misc.py",
>  line 1638, in __init__
> | if ByteArray.tostring() != b'PE\0\0':
> | AttributeError: 'array.array' object has no attribute 'tostring'
>  
>  
> Thanks & Regards,
> Shivraj Patil
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90683): https://edk2.groups.io/g/devel/message/90683
Mute This Topic: https://groups.io/mt/91922911/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] BaseTools: Suppress read only relocs errors on XCODE5 X64 toolchain

[Andrew Fish via groups.io]

Marvin,

I’ll look into this.

The history here is the original ld64 flags are what was required for proper 
function. I got them
directly from the main ld64 maintainer. 

Big picture ld64 is the macOS and iOS linker, and it does not have official 
support for other targets, especially embedded. So the combination of flags are 
what was required for correctness as not all combination of possible ld64 flags 
are actually supported.

Back in the day we made clang open source contributions to get EFIABI supported 
in clang, but we have always used the stock ld64, with help from the author.
> On Jun 18, 2022, at 8:03 PM, Marvin Häuser  wrote:
> 
> CC Andrew, Rebecca, mentors
> 
> Hey all,
> 
> The patch itself looks good to me. The description doesn't really capture the 
> issue, nor why this is an adequate solution. This should also remove the 
> mentioned XCODE5-specific code as part of a single series [1] to confirm the 
> issue has been resolved without regressions.
> 
> TL;dr for the rest: Apple ld64 complains because there are relocations to 
> read-only segments in a PIE executable. As Mach-O allows mapping read-only 
> segments of PIEs to multiple virtual addresses (in different processes), this 
> is prohibited right at link-time for obvious reasons. PE/COFF doesn't really 
> have such a feature (I think Windows used to use static addresses and now 
> uses CoW with traditional relocs?) and UEFI has no concept of page sharing 
> anyway. Hence, it is safe to allow such relocs and silence the warning. All 
> other toolchains should already work this way.
> 
> Andrew, Rebecca, if I remember correctly, you pretty much maintain XCODE5. I 
> had a conversation with Andrew about related topics before, too. Are you fine 
> with this approach? It seems like it has previously been applied to IA32 
> builds already anyway (right from import).
> 
> Maybe PIE could be dropped as a whole somehow in the future? For UEFI, it 
> basically only adds overhead (or are there blockers to this?).
> 
> Best regards,
> Marvin
> 
> [1] 
> https://github.com/tianocore/edk2/tree/cc2db6ebfb6d9d85ba4c7b35fba1fa37fffc0bc2/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Xcode5ExceptionHandlerAsm.nasm
> 
>> On 18. Jun 2022, at 15:21, Théo Jehl  wrote:
>> 
>> From: Theo Jehl 
>> 
>> Added -read_only_relocs suppress for XCODE5 X64 toolchain
>> This remove the needs for XCODE5 specific source with relocation fixes
>> 
>> Cc: Bob Feng 
>> Cc: Liming Gao 
>> Cc: Yuwei Chen 
>> Cc: Marvin Häuser 
>> Cc: Vitaly Cheptsov 
>> 
>> Signed-off-by: Theo Jehl 
>> ---
>> BaseTools/Conf/tools_def.template | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>> 
>> diff --git a/BaseTools/Conf/tools_def.template 
>> b/BaseTools/Conf/tools_def.template
>> index 5ed19810b727..be35094cecc3 100755
>> --- a/BaseTools/Conf/tools_def.template
>> +++ b/BaseTools/Conf/tools_def.template
>> @@ -2977,9 +2977,9 @@ RELEASE_XCODE5_IA32_CC_FLAGS   = -arch i386 -c-Os  
>>  -Wall -Werror -inclu
>> ##
>> # X64 definitions
>> ##
>> -  DEBUG_XCODE5_X64_DLINK_FLAGS  = -arch x86_64 -u _$(IMAGE_ENTRY_POINT) 
>> -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20  -pie -all_load -dead_strip 
>> -seg1addr 0x240 -map $(DEST_DIR_DEBUG)/$(BASE_NAME).map
>> -  NOOPT_XCODE5_X64_DLINK_FLAGS  = -arch x86_64 -u _$(IMAGE_ENTRY_POINT) 
>> -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20  -pie -all_load -dead_strip 
>> -seg1addr 0x240 -map $(DEST_DIR_DEBUG)/$(BASE_NAME).map
>> -RELEASE_XCODE5_X64_DLINK_FLAGS  = -arch x86_64 -u _$(IMAGE_ENTRY_POINT) 
>> -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20  -pie -all_load -dead_strip 
>> -seg1addr 0x240 -map $(DEST_DIR_DEBUG)/$(BASE_NAME).map
>> +  DEBUG_XCODE5_X64_DLINK_FLAGS  = -arch x86_64 -u _$(IMAGE_ENTRY_POINT) 
>> -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20  -pie -all_load -dead_strip 
>> -seg1addr 0x240 -read_only_relocs suppress -map 
>> $(DEST_DIR_DEBUG)/$(BASE_NAME).map
>> +  NOOPT_XCODE5_X64_DLINK_FLAGS  = -arch x86_64 -u _$(IMAGE_ENTRY_POINT) 
>> -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20  -pie -all_load -dead_strip 
>> -seg1addr 0x240 -read_only_relocs suppress -map 
>> $(DEST_DIR_DEBUG)/$(BASE_NAME).map
>> +RELEASE_XCODE5_X64_DLINK_FLAGS  = -arch x86_64 -u _$(IMAGE_ENTRY_POINT) 
>> -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20  -pie -all_load -dead_strip 
>> -seg1addr 0x240 -read_only_relocs suppress -map 
>> $(DEST_DIR_DEBUG)/$(BASE_NAME).map
>> 
>> *_XCODE5_X64_SLINK_FLAGS  = -static -o
>>  DEBUG_XCODE5_X64_ASM_FLAGS  = -arch x86_64 -g
>> -- 
>> 2.32.1 (Apple Git-133)
>> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90601): https://edk2.groups.io/g/devel/message/90601
Mute This Topic: https://groups.io/mt/91840126/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Windows 10 build failing

[Andrew Fish via groups.io]

> On Jun 17, 2022, at 9:55 AM, M.T.  wrote:
> 
> I think I'm getting somewhere now.
> 
> I set everything up and I started getting a consistent error (see logfile 
> from my last email)
> I had to comment out BrDummyMalloc from BrotliDecUefiSupport.h, and now I am 
> able to build MdeModulePkg.
> 
> Now one other error I'm dealing with:
> error 4000: Instance of library class [RegisterFilterLib] is not found
> in 
> [c:\users\maciej\uefi\edk2\MdePkg\Library\BaseIoLibIntrinsic\BaseIoLibIntrinsic.inf
> 

That library dependency should be resolved by including MdePkg/MdeLibs.dsc.inc 
in the dSC file?

/Volumes/Case/edk2(master)>git grep "MdePkg/MdeLibs.dsc.inc"
ArmPkg/ArmPkg.dsc:36:!include MdePkg/MdeLibs.dsc.inc
ArmPlatformPkg/ArmPlatformPkg.dsc:36:!include MdePkg/MdeLibs.dsc.inc
ArmVirtPkg/ArmVirtCloudHv.dsc:60:!include MdePkg/MdeLibs.dsc.inc
ArmVirtPkg/ArmVirtKvmTool.dsc:39:!include MdePkg/MdeLibs.dsc.inc
ArmVirtPkg/ArmVirtQemu.dsc:53:!include MdePkg/MdeLibs.dsc.inc
ArmVirtPkg/ArmVirtQemuKernel.dsc:51:!include MdePkg/MdeLibs.dsc.inc
ArmVirtPkg/ArmVirtXen.dsc:28:!include MdePkg/MdeLibs.dsc.inc
CryptoPkg/CryptoPkg.dsc:56:!include MdePkg/MdeLibs.dsc.inc
DynamicTablesPkg/DynamicTablesPkg.dsc:23:!include MdePkg/MdeLibs.dsc.inc
EmbeddedPkg/EmbeddedPkg.dsc:44:!include MdePkg/MdeLibs.dsc.inc
EmulatorPkg/EmulatorPkg.dsc:47:!include MdePkg/MdeLibs.dsc.inc
FatPkg/FatPkg.dsc:29:!include MdePkg/MdeLibs.dsc.inc
FmpDevicePkg/FmpDevicePkg.dsc:41:!include MdePkg/MdeLibs.dsc.inc
IntelFsp2Pkg/IntelFsp2Pkg.dsc:19:!include MdePkg/MdeLibs.dsc.inc
IntelFsp2Pkg/Tools/Tests/QemuFspPkg.dsc:75:!include MdePkg/MdeLibs.dsc.inc
IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc:19:!include MdePkg/MdeLibs.dsc.inc
MdeModulePkg/MdeModulePkg.dsc:22:!include MdePkg/MdeLibs.dsc.inc
MdePkg/MdeLibs.dsc.inc:5:# by using "!include MdePkg/MdeLibs.dsc.inc" to 
specify the library instances
MdePkg/MdePkg.dsc:24:!include MdePkg/MdeLibs.dsc.inc
NetworkPkg/NetworkPkg.dsc:23:!include MdePkg/MdeLibs.dsc.inc
OvmfPkg/AmdSev/AmdSevX64.dsc:110:!include MdePkg/MdeLibs.dsc.inc
OvmfPkg/Bhyve/BhyveX64.dsc:116:!include MdePkg/MdeLibs.dsc.inc
OvmfPkg/CloudHv/CloudHvX64.dsc:126:!include MdePkg/MdeLibs.dsc.inc
OvmfPkg/IntelTdx/IntelTdxX64.dsc:108:!include MdePkg/MdeLibs.dsc.inc
OvmfPkg/Microvm/MicrovmX64.dsc:124:!include MdePkg/MdeLibs.dsc.inc
OvmfPkg/OvmfPkgIa32.dsc:122:!include MdePkg/MdeLibs.dsc.inc
OvmfPkg/OvmfPkgIa32X64.dsc:126:!include MdePkg/MdeLibs.dsc.inc
OvmfPkg/OvmfPkgX64.dsc:139:!include MdePkg/MdeLibs.dsc.inc
OvmfPkg/OvmfXen.dsc:116:!include MdePkg/MdeLibs.dsc.inc
PcAtChipsetPkg/PcAtChipsetPkg.dsc:21:!include MdePkg/MdeLibs.dsc.inc
RedfishPkg/RedfishPkg.dsc:21:!include MdePkg/MdeLibs.dsc.inc
SecurityPkg/SecurityPkg.dsc:20:!include MdePkg/MdeLibs.dsc.inc
ShellPkg/ShellPkg.dsc:22:!include MdePkg/MdeLibs.dsc.inc
SignedCapsulePkg/SignedCapsulePkg.dsc:20:!include MdePkg/MdeLibs.dsc.inc
SourceLevelDebugPkg/SourceLevelDebugPkg.dsc:26:!include MdePkg/MdeLibs.dsc.inc
StandaloneMmPkg/StandaloneMmPkg.dsc:36:!include MdePkg/MdeLibs.dsc.inc
UefiCpuPkg/UefiCpuPkg.dsc:24:!include MdePkg/MdeLibs.dsc.inc
UefiPayloadPkg/UefiPayloadPkg.dsc:150:!include MdePkg/MdeLibs.dsc.inc
UnitTestFrameworkPkg/UnitTestFrameworkPkg.dsc:22:!include MdePkg/MdeLibs.dsc.inc

/Volumes/Case/edk2(master)>cat MdePkg/MdeLibs.dsc.inc
## @file
# Mde DSC include file for [LibraryClasses*] section of all Architectures.
#
# This file can be included to the [LibraryClasses*] section(s) of a platform 
DSC file
# by using "!include MdePkg/MdeLibs.dsc.inc" to specify the library instances
# of some EDKII basic/common library classes.
#
# Copyright (c) 2021 - 2022, Intel Corporation. All rights reserved.
#
#SPDX-License-Identifier: BSD-2-Clause-Patent
#
##

[LibraryClasses]
  
RegisterFilterLib|MdePkg/Library/RegisterFilterLibNull/RegisterFilterLibNull.inf
  CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
  
SmmCpuRendezvousLib|MdePkg/Library/SmmCpuRendezvousLibNull/SmmCpuRendezvousLibNull.inf


Thanks,

Andrew Fish

> I saw some posts that this was resolved back in 2021, yet I'm still getting 
> hit with it.
> Any advice on how to resolve this?
> 
> Thank you
> xp
> 
> 
> 
> On Fri, Jun 17, 2022 at 9:58 AM M.T. via groups.io  
> mailto:gmail@groups.io>> wrote:
> I tried all your suggestions, but it looks like still no cigar.
> 
> I deleted and recloned the repo with --recursive, built emulatorPkg, which 
> worked fine, then tried MdeModulePkg
> I get the same error on both my setups, real and VM.
> I ran the build with -n 1 and -j after deleting the Build directory, please 
> find the log file attached.
> 
> Command history is as follows:
> git clone --recursive https://github.com/tianocore/edk2.git 
> 
> cd edk2
> git submodule update --init
> edksetup.bat Rebuild
> // edit target.txt and change to VS2017, X64 and MdeModulePkg/MdeModulePkg.dsc
> build -n 1 -j logfile.txt
> 
> Thank you
> xp
> 
> 
> On Thu, Jun 16, 2022 at 11:05 PM 

Re: [edk2-devel] Running OVMF on crosvm

[Andrew Fish via groups.io]

Mike,

FYI you are not subscribed to the mailing list so all your posts require a 
humans approval, so that is the delay in them showing up..

> On Jun 16, 2022, at 4:29 PM, Mike Gerow via groups.io 
>  wrote:
> 
> Hi Folks,
> 
> For the last few months I've been using OVMF with crosvm 
> 
>  to give it the ability to boot a UEFI OS image in a UEFI environment, and 
> it's been working fantastically! Eventually I'd like to get secure boot 
> working, but I haven't fully begun exploring that yet. I just wanted to post 
> here to figure out how I might go about making crosvm properly supported 
> within OVMF.
> 
> As you might guess, OVMF didn't boot out of the box and I had to do quite a 
> few hacks to get it to work. All the changes are attached as a diff, but I'll 
> list the main points out here:
> 
> * Switch TimerLib from the ACPI-based ones like 
> OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf to 
> MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf since crosvm 
> doesn't provide these methods
> * Hack out the RTC dependency completely, since for reasons I haven't yet 
> figured out crosvm hangs OVMF tries to access it
> * Disable bus enumeration since crosvm doesn't support moving PCI BARs 
> around, which causes it to hang
> * Remove VirtioFsDxe dependency as crosvm seems to choke on certain things 
> it's doing too

I hit something like this in another context. I root caused it to the 
VirtioFsDxe being coded to a recent version of the VirtIo Spec (it is a newer 
EFI driver) and my VM was on an older version. So some things did not work 
properly. 

Thanks,

Andrew Fish

> * Manually searching for ACPI tables instead of using PVH
> 
> And one major theme of some of the other changes: removing conditionals that 
> checked if we're cloud-hypervisor and just doing things the cloud-hypervisor 
> way (which happens to work under crosvm, for reasons that are readily 
> apparent given the nature of cloud-hypervisor and crosvm).
> 
> Clearly this isn't upstreamable at this point, but I'd like eventually go 
> that direction. I think a lot of these are just bugs in crosvm that'll need 
> to be fixed, but for the cloud-hypervisor conditionals case I'd need to teach 
> OVMF to detect when we're running under crosvm and act appropriately.
> 
> In either case, I appreciate your attention and any feedback you might have 
> on what I'm trying to do here.
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90565): https://edk2.groups.io/g/devel/message/90565
Mute This Topic: https://groups.io/mt/91811743/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Does edk2 also link to crt0-efi like GNU-EFI *

[Andrew Fish via groups.io]

> On Jun 16, 2022, at 1:17 PM, Ayush Singh  wrote:
> 
> Thanks for the great answer. After some discussion in the zulip [1], I
> have some approaches that I will try first.
> 
> As for calling C, EFIABI from Rust, yes, it is quite well supported.
> Rust also has a specific EFIABI now, since some EFI platforms don't
> use C calling conventions.
> 
> As for the entry point, llvm has an `-entry:efi_main` that can be used
> to define the entry function for UEFI targets. I just was not sure I
> could integrate it with the actual `main()` function.
> 

For the C builds the tools_def.txt file uses  $(IMAGE_ENTRY_POINT). The build 
maps that over to the _ModelEntryPoint label I mentioned. It would probably be 
good to sue the same symbol. 

The C we have is free standing so there is nothing that is setup for the C 
language, other that libs the user asked for.

> In normal Rust, the control flow is somewhat like this: crt0 -> libc
> main -> rust lang_start -> rust lang_start_internal -> rust main
> 
> In UEFI, I would have to do something like this: efi_main -> rust
> lang_start -> rust lang_start_internal -> rust main
> 

The edk2 way to do this seems to me is to create an edk2 RustEntryPoint lib 
that models the edk2 *EntryPointLib [1]. The entry point would be  
_ModelEntryPoint.

I’m not 100% clear on all the dependencies but the big picture is for C edk2 
injects code between the entry point and the main function. I think you will 
want that in your Rust world.

The other thing you need to manage is the entry point hands-off  the only way 
to bind to all the EFI Services so that needs to make it into your Rust world. 

EFI_STATUS
EFIAPI
_ModuleEntryPoint (
  IN EFI_HANDLEImageHandle,
  IN EFI_SYSTEM_TABLE  *SystemTable
  )
The Apps need access to SystemTable to do just about anything. The ImageHandle 
lets them get access to args and info on how the driver/app was loaded. 

We have different flavors of these entry point libs as the handoff, and 
sometimes entry exit behavior are different:
$ git grep 'EntryPoint|' -- \*.inf | grep LIBRARY_CLASS
MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf:18:  LIBRARY_CLASS   
   = DxeCoreEntryPoint|DXE_CORE
MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf:18:  LIBRARY_CLASS   
   = PeiCoreEntryPoint|PEI_CORE
MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf:18:  LIBRARY_CLASS 
 = PeimEntryPoint|PEIM
MdePkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.inf:21:
  LIBRARY_CLASS  = StandaloneMmDriverEntryPoint|MM_STANDALONE
MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf:18:  
LIBRARY_CLASS  = UefiApplicationEntryPoint|UEFI_APPLICATION
MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf:18:  LIBRARY_CLASS 
 = UefiDriverEntryPoint|DXE_DRIVER DXE_RUNTIME_DRIVER 
UEFI_DRIVER SMM_CORE DXE_SMM_DRIVER
StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf:18:
  LIBRARY_CLASS  = StandaloneMmCoreEntryPoint|MM_CORE_STANDALONE

I think what this means from a practical point after reading your Rust thread 
is:
1) Have some custom code, per driver type, to maybe convert the EFI/PEI/edk2 
define entry point arguments maybe into standard Rust args. 
  argc = 2
  argv[0] = ImageHandle
  argv[1] =  *SystemTable

2) Then you can call the common Rust init flow from your link. 

3) rt_entry() is custom for edk2. It would basically do the same things as the 
edk2 C *EntryPoint libs _ModuleEntryPoint() functions. Call the auto generated 
lib constructor functions, call the auto generated entry point function that 
calls the function in the users Rust code. Call the lib destructor. Also 
provide support for the Exit function. 

You can kind of hard code bits to get started, but If you think about it this 
way I think it will be easier to layer in edk2 like build features as we grow 
the Rust support. 

You could get really fancy and pass the mode BASE/PEIM/DXE in argv[0], and the 
args in args[1], …. By doing that you might need small stubs that are mode 
specific to capture the different entry point APIs, but all the other lib 
infrastructure could be common. The little tiny entry stub libs could depend on 
the common lib so the INF files would only need to specify the entry point stub 
lib.

[1] 
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/UefiApplicationEntryPoint/ApplicationEntryPoint.c

Thanks,

Andrew Fish

> The problem was that I couldn't find a way to go from `efi_main ->
> rust lang_start` earlier. After all, it is such a low-level detail
> that there is almost no documentation for anything that happens before
> `rust lang_start`. Still, I do have some idea now, so will see how it
> goes.
> 
> Ayush Singh
> 
> [1]: 
> (https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Run.20a.20function.20before.20.60lang_start.60/near/286376012)
> 
> On 

Re: [edk2-devel] Does edk2 also link to crt0-efi like GNU-EFI

[Andrew Fish via groups.io]

> On Jun 16, 2022, at 7:20 AM, Ayush Singh  wrote:
> 
> Hello everyone, I wanted to ask if the edk2 build system also links to
> crt0-efi, like GNU-EFI?
> 
> If yes, I would also like to see how that is actually implemented. If
> not, how does edk2 support custom entry functions? It is possible with
> llvm backend but I am not sure how it is done in GCC and am curious,
> 

The general answer for edk2 is and library that a `CONSTRUCTOR =` statement in 
its INF that lib constructor will get called when the Driver/App is started. 

The actually entry point for a Driver/App is _ModuleEntryPoint(). The typical 
way it is done is this is implemented in a phase specific library[1]. This 
phase specific basically calls 3 C functions that got generated by the build: 
ProcessLibraryConstructorList(), ProcessModuleEntryPointList(), and 
ProcessLibraryDestructorList(). The library constructor/destructors functions 
call the lib  constructor/destructors function based in the sequence of the 
dependency graph of the libraries that get pulled in. 

> Currently, rust does not support the custom implementation of
> `lang_start` (which is started by crt0 in most platforms), so I was
> trying to find ways to be able to use custom crt0 which sets up
> `SystemTable` and `SystemHandler` and start the `lang_start` from it.
> This way, the user will be able to call the normal `main` function
> rather than using the `no_main` feature.
> 

If you look in the build output of an edk2 C driver/app you will see an 
AutoGen.h and AutoGen.c file. This was the C code the build system 
autogenerated to glue everything together. It manages gluing in the libs, 
abstracting the PCD implementation, and adding C constants for EFI_GUID values. 

Sorry I don’t know Rust yet. Is it possible to call C, EFIABI, from Rust code? 
If yes maybe what you need is a Rust ModuleEntryPoint that can call the C 
library constructor and a C EFIABI entry function for your Rust. I’m not sure 
how you manage dealing with C includes in Rust? With C++ you can just decorate 
them. 

I guess the other 100% Rust option is to know the INF is building Rust (INF has 
Code.rs files) and build Rust (or Rust compatible) AutoGen 

> My blog post [1] shows how we currently use the `efi_main` function.
> 
> Yours sincerely,
> Ayush Singh
> 
> [1]: (https://www.programmershideaway.xyz/post5/)
> 
> 

[1] 
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/UefiApplicationEntryPoint/ApplicationEntryPoint.c

Thanks,

Andrew Fish


> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90554): https://edk2.groups.io/g/devel/message/90554
Mute This Topic: https://groups.io/mt/91800012/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Clarification of Memory management in PEI phase

[Andrew Fish via groups.io]

> On Jun 9, 2022, at 10:28 AM, Ayush Singh  wrote:
> 
> Hello everyone,
> 
> Can anyone help me with understanding dynamic memory management in PEI
> phase? In the UEFI Platform Integration Specification, version 1.7
> Errata A, Section 4.6, PEI Memory services are given which include:
> 
> 1. InstallPeiMemory()

This is basically:
(*PeiServices)->InstallPeiMemory (PeiServices, MemoryBegin, MemoryLength);

This is how you tell the PEI Core the location of the memory that will can be 
used in PEI. 

> 2. AllocatePages()
> 3. AllocatePool()
> 4. CopyMem()
> 5. SetMem()
> 6. FreePages()
> 
> However, no `FreePool()` service seems to be present. So how is the
> memory allocated using `AllocatePool()` freed?
> 

It basically gets Freed when you transition to the DXE phase. 

To step back for a minute I think it is important to remember that the main job 
of PEI is to initialize DRAM, and deal with S3 (resuming from suspend to RAM). 
So as soon as you have DRAM you are kind done and ready for the DXE IPL so you 
can load the DXE Phase and start up EFI. Remember PEI is Pre EFI. The reality 
is programming DRAM is complex and lots of code got written, then lots more 
code got written and PEI has become large for some ports. That was never the 
intent. PEI is designed as a way to run C code when you code is running from 
ROM and you don’t have any DRAM. For x86 not having DRAM means you are using 
the cache as RAM. For some SoCs there is actually an SRAM you can use. Thus the 
PEI memory allocation scheme is designed to deal with this very constrained 
environment. 

You start PEI with a heap and stack. You can also allocate HOBs (Hand Off 
Blocks). A pool allocation in PEI is just a HOB. See [1]. There is no way to 
free a HOB. So the AllocatePool() kind of leaks into DXE too as an entry in the 
HOB list. But when the OS called gBS->ExitBootServices() that frees all non 
runtime memory back to the OS. 

If you look a AllocatePages/FreePages you will see AllocatePages creates a HOB 
that points to the memory region, and FreePages just marks that HOB as not 
used. That code is also in this file [1]. 

TL;DR there is no pool manager in PEI. 

[1] 
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/Memory/MemoryServices.c#L878


Thanks,

Andrew Fish

> Ayush Singh
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90419): https://edk2.groups.io/g/devel/message/90419
Mute This Topic: https://groups.io/mt/91651322/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] ovmf miscompiles with gcc-12

[Andrew Fish via groups.io]

Mike,

This sounds like a conversation we had years ago? I think we concluded we 
needed to write stuff in assembler and not depend on implementation choices of 
the compiler with regard to registers usage? I want to say something broke with 
Xcode clang. I think it might have been the Emulator code 
TemporaryRamMigration, so that was probably similar to this case?

I’m a little unclear why this code is not using SwitchStack()[1]? I thought one 
of the points of jumping to the new function was giving up of old RBP usage? 
Also calling assembler and the indirect procedure call 
(SWITCH_STACK_ENTRY_POINT) force the complier to serialize to the ABI and thus 
greatly reduce the exposure to compiler optimization choices. Not sure if there 
is something I’m missing and SwitchStack() can’t work? Doh just realized to use 
SwitchStack the TemporaryRamMigration API would need to pass in the function to 
return too like SwitchStack. So that is a big NO GO. 

OK so this is like the Emulator case when the OS uses SYS V ABI and EFI does 
not. OK I think the only pedantic way to fix this is to make the public API 
call an assembler shim that calls the C code. Then the C code becomes..

EFI_STATUS
EFIAPI
TemporaryRamMigration (
  IN CONST EFI_PEI_SERVICES  **PeiServices,
  IN EFI_PHYSICAL_ADDRESSTemporaryMemoryBase,
  IN EFI_PHYSICAL_ADDRESSPermanentMemoryBase,
  IN UINTN   CopySize
  IN OUT UINTN.*Rsp,
  IN OUT UINTN.*Rbp,
  OUT BOOLEAN   *DebugTimerStatus
  )

The assembler shim can capture the actual RSP/RBP on entry and just fix them 
them on exit. The stub may need to call SaveAndSetDebugTimerInterrupt 
(DebugTimerStatus); prior to exit.

Then the existing SetJump/LongJump code becomes;
*Rsp += DebugAgentContext.StackMigrateOffset;
*Rbp += DebugAgentContext.StackMigrateOffset;
return EFI_SUCCESS;

The SaveAndSetDebugTimerInterrupt (OldStatus); call gets moved to the assembler 
code after the stack shift. 

The tricky bit would seem to be the storage used for *Rsp, Rbp, and 
*DebugTimerStauts. I guess worst case the C code could return 
DebugAgentContext.StackMigrateOffset and the assembly could “adjust”. Then the 
assembler code just hard codes a EFI_SUCCESS return;

[1] 
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/X64/SwitchStack.nasm#L35

/**
  Transfers control to a function starting with a new stack.

  Transfers control to the function specified by EntryPoint using the
  new stack specified by NewStack and passing in the parameters specified
  by Context1 and Context2.  Context1 and Context2 are optional and may
  be NULL.  The function EntryPoint must never return.  This function
  supports a variable number of arguments following the NewStack parameter.
  These additional arguments are ignored on IA-32, x64, and EBC.
  IPF CPUs expect one additional parameter of type VOID * that specifies
  the new backing store pointer.

  If EntryPoint is NULL, then ASSERT().
  If NewStack is NULL, then ASSERT().

  @param  EntryPoint  A pointer to function to call with the new stack.
  @param  Context1A pointer to the context to pass into the EntryPoint
  function.
  @param  Context2A pointer to the context to pass into the EntryPoint
  function.
  @param  NewStackA pointer to the new stack to use for the EntryPoint
  function.
  @param  ... This variable argument list is ignored for IA32, x64, and 
EBC.
  For IPF, this variable argument list is expected to 
contain
  a single parameter of type VOID * that specifies the new 
backing
  store pointer.


**/
VOID
EFIAPI
SwitchStack (
  IN  SWITCH_STACK_ENTRY_POINT  EntryPoint,
  IN  VOID  *Context1   OPTIONAL,
  IN  VOID  *Context2   OPTIONAL,
  IN  VOID  *NewStack,
  ...
  )


Thanks,

Andrew Fish

PS The Xcode clang always emits the frame pointer to enable stack walks.

> On Jun 7, 2022, at 4:14 AM, Jiri Slaby  wrote:
> 
> On 07. 06. 22, 13:07, Gerd Hoffmann wrote:
>> On Tue, Jun 07, 2022 at 12:38:46PM +0200, Jiri Slaby wrote:
>>> Hi,
>>> 
>>> On 07. 06. 22, 12:31, Gerd Hoffmann wrote:
> The reason is TemporaryRamMigration() overwrites rbp unconditionally -- it
> adds an offset to rbp even if rbp is NOT used as a frame pointer
 
> Now, what is the right way to fix this? Do the SetJump/LongJump in 
> assembly
> and wrap it into push rbp/pop rbp?
 
 push/pop rbp will break in case frame pointers are used, no?
>>> 
>>> Yes, see the downstream bug at:
>>> 
>>> https://bugzilla.suse.com/show_bug.cgi?id=1199597#c45
>>> 
>>> and read further.
>>> 
 I think essentially the code needs to know whenever frame pointers are
 used or not and then update (or not) rbp depending on that.  Update
 compiler flags to explicitly set -f(no-)omit-frame-pointer, also add

[edk2-devel] [ArmVirtPkg] So in 2014 would could not start an ARM FV @ address 0x00000000, why is that still true today?

[Andrew Fish via groups.io]

I’m a little confused on why we can’t put an ARM FV at address 0x [1]? 
Obviously the zero vector for the FV is getting patch as this ARM code is 
jumping to the 1st byte of the FV when it is present at 0x1000. I don’t know of 
any generic limitation in our tools. This kind of feels like an 8 year old bug 
that got fixed at some point? Anyone know the history here? Do we need to file 
a BZ to get something fixed?

[1] https://github.com/tianocore/edk2/blob/master/ArmVirtPkg/ArmVirtQemu.fdf#L56

#
# UEFI has trouble dealing with FVs that reside at physical address 0x0.
# So instead, put a hardcoded 'jump to 0x1000' at offset 0x0, and put the
# real FV at offset 0x1000
#
0x|0x1000
DATA = {
!if $(ARCH) == AARCH64
  0x00, 0x04, 0x00, 0x14   # 'b 0x1000' in AArch64 ASM
!else
  0xfe, 0x03, 0x00, 0xea   # 'b 0x1000' in AArch32 ASM
!endif
}

0x1000|$(FVMAIN_COMPACT_SIZE)
gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
FV = FVMAIN_COMPACT

Thanks,

Andrew Fish

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90206): https://edk2.groups.io/g/devel/message/90206
Mute This Topic: https://groups.io/mt/91536245/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] including redfish libs results in multiple definitions of symbols

[Andrew Fish via groups.io]

In edk2 speak Base just means does not depend on any phase of boot, so 
basically standalone code. So you can pull a Base lib into SEC, PEI, DXE, SMM, 
etc. 

We never interned different Class Names for libs to map to the same library 
class when we designed the build system. 

One of the driving factors for the library classes was to not have to change 
your vendors driver INF file id you wanted to use a different instance of the 
DebugLib etc.

Thanks,

Andrew Fish

> On May 25, 2022, at 9:07 PM, Ethin Probst  wrote:
> 
> aren't the Base*Libs there in case you want to override existing 
> implementations or implement custom versions of them? I'm pretty sure that's 
> the logic behind it -- its a hack of sorts to try to get OOP out of a purely 
> procedural language. It works, but I don't think its necessarily ideal. But 
> there really isn't much of an alternative. Then again, I might be wrong, 
> too...
> 
> On 5/25/22 23:04, Andrew Fish via groups.io wrote:
>>> On May 25, 2022, at 9:23 AM, M.T. >> <mailto:xzavierpo...@gmail.com>> wrote:
>>> 
>>> Hello
>>> 
>>> I'm working on a small UEFI shell app.
>>> I was hoping to make use of the JsonLib found in the Redfish Package.
>>> 
>>> When I include the Redfish JsonLib and it's dependencies:
>>> JsonLib|RedfishPkg/Library/JsonLib/JsonLib.inf
>>> Ucs2Utf8Lib|RedfishPkg/Library/BaseUcs2Utf8Lib/BaseUcs2Utf8Lib.inf
>>> RedfishCrtLib|RedfishPkg/PrivateLibrary/RedfishCrtLib/RedfishCrtLib.inf
>>> BaseSortLib|MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf
>>> 
>>> BaseSortLib has symbol clashes with SortLib resulting in the following:
>>> 
>> It looks like BaseSortLib and and SortLib are the same library class so you 
>> should only have one.
>> /Volumes/Case/edk2(master)*>*git grep --recurse-submodules SortLib  -- 
>> \*.inf | grep LIBRARY_CLASS
>> MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf:18:  LIBRARY_CLASS  
>>  = SortLib
>> MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf:18:  LIBRARY_CLASS  
>>  = SortLib|UEFI_APPLICATION UEFI_DRIVER UEFI_DRIVER 
>> DXE_RUNTIME_DRIVER DXE_DRIVER
>> /Volumes/Case/edk2(master)*>*git grep --recurse-submodules BaseSortLib  -- 
>> \*.inc
>> RedfishPkg/RedfishLibs.dsc.inc:16:*BaseSortLib*|MdeModulePkg/Library/*BaseSortLib*/*BaseSortLib*.inf
>> OK bingo bingo bingo….
>> The way the edk2 works is you have a library class that maps to the include 
>> file. This is the name in the INF file that resolves linking. You can have 
>> as many instances of the library class as you like. This is why the DSC 
>> files have the | syntax as you are 
>> letting the build pick which instance of the library to use. You can control 
>> this per driver/app if you want.
>> It looks to me like BaseSortLib is an alias for SortLib and that is a bit of 
>> hack.
>> You could try making sure that BaseSortLib and SortLib point to the same 
>> library instance
>> The other option would be to edit RedfishCrtLib.inf and make BaseSortLib 
>> SortLib
>> /Volumes/Case/edk2(master)*>*git grep --recurse-submodules BaseSortLib  -- 
>> \*.inf
>> MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf:13:  BASE_NAME  
>>  = *BaseSortLib*
>> MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf:14:  MODULE_UNI_FILE
>>  = *BaseSortLib*.uni
>> MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf:25:*BaseSortLib*.c
>> RedfishPkg/PrivateLibrary/RedfishCrtLib/RedfishCrtLib.inf:28:*BaseSortLib*
>> I’m note sure why this fake BaseSortLib exists. Looks like we would need to 
>> ask Abner?
>> *
>> *
>> commit 6e9233f968735219b2038c5dd23a46be2c021807
>> Author: Abner Chang mailto:abner.ch...@hpe.com>>
>> Date:   Fri Dec 4 12:30:05 2020 +0800
>> RedfishPkg/RedfishCrtLib: Redfish C runtime library
>> Redfish CRT library is currently used by edk2 JsonLib
>> (open source jansson project) and edk2 RedfishLib
>> (libredfish open source project). Redfish CrtLib library
>> provides the necessary C runtime equivalent edk2 functions
>> for open source projects.
>> Signed-off-by: Abner Chang > <mailto:abner.ch...@hpe.com>>
>> Cc: Leif Lindholm mailto:l...@nuviainc.com>>
>> Cc: Nickle Wang mailto:nickle.w...@hpe.com>>
>> Cc: Peter O'Hanley mailto:peter.ohan...@hpe.com>>
>> Reviewed-by: Nickle Wang > <mailto:nickle.w...@hpe.com>>
>> Acked-by: Leif Lindholm mailto:l...@nuviainc.com>>
>> Reviewed-by: Michael D Kinney > <mai

Re: [edk2-devel] including redfish libs results in multiple definitions of symbols

[Andrew Fish via groups.io]

> On May 25, 2022, at 9:23 AM, M.T.  wrote:
> 
> Hello
> 
> I'm working on a small UEFI shell app.
> I was hoping to make use of the JsonLib found in the Redfish Package.
> 
> When I include the Redfish JsonLib and it's dependencies:
> JsonLib|RedfishPkg/Library/JsonLib/JsonLib.inf
> Ucs2Utf8Lib|RedfishPkg/Library/BaseUcs2Utf8Lib/BaseUcs2Utf8Lib.inf
> RedfishCrtLib|RedfishPkg/PrivateLibrary/RedfishCrtLib/RedfishCrtLib.inf
> BaseSortLib|MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf
> 
> BaseSortLib has symbol clashes with SortLib resulting in the following:
> 

It looks like BaseSortLib and and SortLib are the same library class so you 
should only have one. 

/Volumes/Case/edk2(master)>git grep --recurse-submodules SortLib  -- \*.inf | 
grep LIBRARY_CLASS 
MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf:18:  LIBRARY_CLASS 
 = SortLib
MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf:18:  LIBRARY_CLASS 
 = SortLib|UEFI_APPLICATION UEFI_DRIVER UEFI_DRIVER DXE_RUNTIME_DRIVER 
DXE_DRIVER


/Volumes/Case/edk2(master)>git grep --recurse-submodules BaseSortLib  -- \*.inc
RedfishPkg/RedfishLibs.dsc.inc:16:  
BaseSortLib|MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf

OK bingo bingo bingo….

The way the edk2 works is you have a library class that maps to the include 
file. This is the name in the INF file that resolves linking. You can have as 
many instances of the library class as you like. This is why the DSC files have 
the | syntax as you are letting the build 
pick which instance of the library to use. You can control this per driver/app 
if you want.

It looks to me like BaseSortLib is an alias for SortLib and that is a bit of 
hack. 

You could try making sure that BaseSortLib and SortLib point to the same 
library instance 

The other option would be to edit RedfishCrtLib.inf and make BaseSortLib SortLib

/Volumes/Case/edk2(master)>git grep --recurse-submodules BaseSortLib  -- \*.inf
MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf:13:  BASE_NAME 
 = BaseSortLib
MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf:14:  MODULE_UNI_FILE   
 = BaseSortLib.uni
MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf:25:  BaseSortLib.c
RedfishPkg/PrivateLibrary/RedfishCrtLib/RedfishCrtLib.inf:28:  BaseSortLib

I’m note sure why this fake BaseSortLib exists. Looks like we would need to ask 
Abner?

commit 6e9233f968735219b2038c5dd23a46be2c021807
Author: Abner Chang 
Date:   Fri Dec 4 12:30:05 2020 +0800

RedfishPkg/RedfishCrtLib: Redfish C runtime library

Redfish CRT library is currently used by edk2 JsonLib
(open source jansson project) and edk2 RedfishLib
(libredfish open source project). Redfish CrtLib library
provides the necessary C runtime equivalent edk2 functions
for open source projects.

Signed-off-by: Abner Chang 

Cc: Leif Lindholm 
Cc: Nickle Wang 
Cc: Peter O'Hanley 
Reviewed-by: Nickle Wang 
Acked-by: Leif Lindholm 
Reviewed-by: Michael D Kinney 


Thanks,

Andrew Fish

> /usr/bin/ld: UefiSortLib.obj (symbol from plugin): in function 
> `PerformQuickSort':
> (.text+0x0): multiple definition of `PerformQuickSort'; BaseSortLib.obj 
> (symbol from plugin):(.text+0x0): first defined here
> /usr/bin/ld: UefiSortLib.obj (symbol from plugin): in function 
> `PerformQuickSort':
> (.text+0x0): multiple definition of `DevicePathCompare'; BaseSortLib.obj 
> (symbol from plugin):(.text+0x0): first defined here
> /usr/bin/ld: UefiSortLib.obj (symbol from plugin): in function 
> `PerformQuickSort':
> (.text+0x0): multiple definition of `StringNoCaseCompare'; BaseSortLib.obj 
> (symbol from plugin):(.text+0x0): first defined here
> /usr/bin/ld: UefiSortLib.obj (symbol from plugin): in function 
> `PerformQuickSort':
> (.text+0x0): multiple definition of `StringCompare'; BaseSortLib.obj (symbol 
> from plugin):(.text+0x0): first defined here
> 
> I need SortLib for UEFIShell dependencies, and I need BaseSortLib for JsonLib.
> Is there some way around this?  Or is Redfish meant to be standalone?
> 
> Thank you in advance
> xp
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90033): https://edk2.groups.io/g/devel/message/90033
Mute This Topic: https://groups.io/mt/91336682/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2] [PATCH v1 1/1] OvmfPkg/TdxDxe: Remove AsmRelocateApMailBoxLoopStart prefix at call

[Andrew Fish via groups.io]

I think we need to -D OPENSSL_NO_APPLE_CRYPTO_RANDOM in the INF.

Thanks,

Andrew Fish

> On May 25, 2022, at 7:39 PM, Rebecca Cran  wrote:
> 
> It's Library/OpensslLib/openssl/include/crypto/rand.h
> 
> # include 
> 
> # if defined(__APPLE__) && !defined(OPENSSL_NO_APPLE_CRYPTO_RANDOM)
> #  include 
> #  if (defined(__MAC_OS_X_VERSION_MIN_REQUIRED) && 
> __MAC_OS_X_VERSION_MIN_REQUIRED >= 101200) || \
>  (defined(__IPHONE_OS_VERSION_MIN_REQUIRED) && 
> __IPHONE_OS_VERSION_MIN_REQUIRED >= 8)
> #   define OPENSSL_APPLE_CRYPTO_RANDOM 1
> #   include 
> #   include 
> #  endif
> # endif
> 
> 
> -- 
> Rebecca Cran
> 
> On 5/25/22 20:22, Andrew (EFI) Fish wrote:
>> What is pulling in Availability.h? That sound more like and #ifdef issue in 
>> some 3rd party header?
>> 
>> I think I might have seen that in SSL headers?
>> 
>> Sent from my iPhone
>> 
>>> On May 25, 2022, at 6:26 PM, Rebecca Cran  wrote:
>>> 
>>> Reviewed-by: Rebecca Cran 
>>> Tested-by: Rebecca Cran 
>>> 
>>> This lets the build get further, before it runs into Availability.h not 
>>> being found.
>>> 
>>> If I download 
>>> http://opensource.apple.com/source/CarbonHeaders/CarbonHeaders-18.1/Availability.h
>>>  and
>>> http://opensource.apple.com/source/CarbonHeaders/CarbonHeaders-18.1/AvailabilityInternal.h
>>>  into MdePkg/Include
>>> (which is very much a hack) then the DEBUG and RELEASE builds succeed.
>>> 
>>> However, NOOPT fails with code generating a call to _memcpy:
>>> 
>>> Undefined symbols for architecture x86_64:
>>>   "_memcpy", referenced from:
>>>   _ValidateHobList in PlatformInitLib.lib(IntelTdx.obj)
>>> ld: symbol(s) not found for architecture x86_64
>>> "libtool" -static -o 
>>> /Users/bcran/src/uefi/edk2/Build/OvmfX64/NOOPT_XCODE5/X64/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe/OUTPUT/CapsuleRuntimeDxe.lib
>>>  -filelist 
>>> /Users/bcran/src/uefi/edk2/Build/OvmfX64/NOOPT_XCODE5/X64/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe/OUTPUT/object_files.lst
>>> make: *** 
>>> [/Users/bcran/src/uefi/edk2/Build/OvmfX64/NOOPT_XCODE5/X64/OvmfPkg/Sec/SecMain/DEBUG/SecMain.dll]
>>>  Error 1
>>> 
>>> 
>>> build.py...
>>>  : error 7000: Failed to execute command
>>> make tbuild 
>>> [/Users/bcran/src/uefi/edk2/Build/OvmfX64/NOOPT_XCODE5/X64/OvmfPkg/Sec/SecMain]
>>> 
>>> 
>>> build.py...
>>>  : error F002: Failed to build module
>>> /Users/bcran/src/uefi/edk2/OvmfPkg/Sec/SecMain.inf [X64, XCODE5, NOOPT]
>>> 
>>> 
>>> 
 On 5/25/22 17:54, Théo Jehl wrote:
 From: Theo Jehl 
 
 Removed prefix to match AsmRelocateApMailBoxLoopStart declaration.
 This fixes a compilation issue.
 
 Cc: Ard Biesheuvel 
 Cc: Jiewen Yao 
 Cc: Jordan Justen 
 Cc: Gerd Hoffmann 
 Signed-off-by: Jehl Theo 
 ---
  OvmfPkg/TdxDxe/X64/ApRunLoop.nasm | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/OvmfPkg/TdxDxe/X64/ApRunLoop.nasm 
 b/OvmfPkg/TdxDxe/X64/ApRunLoop.nasm
 index a859375fb819..52fb3b4944bf 100644
 --- a/OvmfPkg/TdxDxe/X64/ApRunLoop.nasm
 +++ b/OvmfPkg/TdxDxe/X64/ApRunLoop.nasm
 @@ -83,7 +83,7 @@ AsmRelocateApMailBoxLoopEnd:
  
 ;-
  global ASM_PFX(AsmGetRelocationMap)
  ASM_PFX(AsmGetRelocationMap):
 -learax, [ASM_PFX(AsmRelocateApMailBoxLoopStart)]
 +learax, [AsmRelocateApMailBoxLoopStart]
  movqword [rcx], rax
  movqword [rcx +  8h], AsmRelocateApMailBoxLoopEnd - 
 AsmRelocateApMailBoxLoopStart
  ret
>>> 
>>> 
>>> 
>>> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90031): https://edk2.groups.io/g/devel/message/90031
Mute This Topic: https://groups.io/mt/91344827/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2] [PATCH v1 1/1] OvmfPkg/TdxDxe: Remove AsmRelocateApMailBoxLoopStart prefix at call

[Andrew Fish via groups.io]

What is pulling in Availability.h? That sound more like and #ifdef issue in 
some 3rd party header?

I think I might have seen that in SSL headers?
> On May 25, 2022, at 6:26 PM, Rebecca Cran  wrote:
> 
> Reviewed-by: Rebecca Cran 
> Tested-by: Rebecca Cran 
> 
> This lets the build get further, before it runs into Availability.h not being 
> found.
> 
> If I download 
> http://opensource.apple.com/source/CarbonHeaders/CarbonHeaders-18.1/Availability.h
>  and
> http://opensource.apple.com/source/CarbonHeaders/CarbonHeaders-18.1/AvailabilityInternal.h
>  into MdePkg/Include
> (which is very much a hack) then the DEBUG and RELEASE builds succeed.
> 
> However, NOOPT fails with code generating a call to _memcpy:
> 
> Undefined symbols for architecture x86_64:
>   "_memcpy", referenced from:
>   _ValidateHobList in PlatformInitLib.lib(IntelTdx.obj)
> ld: symbol(s) not found for architecture x86_64
> "libtool" -static -o 
> /Users/bcran/src/uefi/edk2/Build/OvmfX64/NOOPT_XCODE5/X64/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe/OUTPUT/CapsuleRuntimeDxe.lib
>  -filelist 
> /Users/bcran/src/uefi/edk2/Build/OvmfX64/NOOPT_XCODE5/X64/MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe/OUTPUT/object_files.lst
> make: *** 
> [/Users/bcran/src/uefi/edk2/Build/OvmfX64/NOOPT_XCODE5/X64/OvmfPkg/Sec/SecMain/DEBUG/SecMain.dll]
>  Error 1
> 
> 
> build.py...
>  : error 7000: Failed to execute command
> make tbuild 
> [/Users/bcran/src/uefi/edk2/Build/OvmfX64/NOOPT_XCODE5/X64/OvmfPkg/Sec/SecMain]
> 
> 
> build.py...
>  : error F002: Failed to build module
> /Users/bcran/src/uefi/edk2/OvmfPkg/Sec/SecMain.inf [X64, XCODE5, NOOPT]
> 
> 
> 
>> On 5/25/22 17:54, Théo Jehl wrote:
>> From: Theo Jehl 
>> 
>> Removed prefix to match AsmRelocateApMailBoxLoopStart declaration.
>> This fixes a compilation issue.
>> 
>> Cc: Ard Biesheuvel 
>> Cc: Jiewen Yao 
>> Cc: Jordan Justen 
>> Cc: Gerd Hoffmann 
>> Signed-off-by: Jehl Theo 
>> ---
>>  OvmfPkg/TdxDxe/X64/ApRunLoop.nasm | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/OvmfPkg/TdxDxe/X64/ApRunLoop.nasm 
>> b/OvmfPkg/TdxDxe/X64/ApRunLoop.nasm
>> index a859375fb819..52fb3b4944bf 100644
>> --- a/OvmfPkg/TdxDxe/X64/ApRunLoop.nasm
>> +++ b/OvmfPkg/TdxDxe/X64/ApRunLoop.nasm
>> @@ -83,7 +83,7 @@ AsmRelocateApMailBoxLoopEnd:
>>  
>> ;-
>>  global ASM_PFX(AsmGetRelocationMap)
>>  ASM_PFX(AsmGetRelocationMap):
>> -learax, [ASM_PFX(AsmRelocateApMailBoxLoopStart)]
>> +learax, [AsmRelocateApMailBoxLoopStart]
>>  movqword [rcx], rax
>>  movqword [rcx +  8h], AsmRelocateApMailBoxLoopEnd - 
>> AsmRelocateApMailBoxLoopStart
>>  ret
> 
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90029): https://edk2.groups.io/g/devel/message/90029
Mute This Topic: https://groups.io/mt/91344827/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Can you create a PCI Option ROM and place it in an FV in a single build?

[Andrew Fish via groups.io]

I realize I can use syntax like this to control the construction of an option 
ROM from an FDF file.

1
[OptionRom.AtapiPassThru]
2
  INF USE = IA32 OptionRomPkg/AtapiPassThruDxe/AtapiPassThruDxe.inf {
3
PCI_REVISION = 0x0020
4
PCI_DEVICE_ID = 0x0A03 0x0B03
5
  }
6
  INF USE = EBC OptionRomPkg/AtapiPassThruDxe/AtapiPassThruDxe.inf


What I can’t figure out is how to get that PCI ROM in the FV?

Thanks,

Andrew Fish

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89989): https://edk2.groups.io/g/devel/message/89989
Mute This Topic: https://groups.io/mt/91322630/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Question about PCD and FW_BASE_ADDRESS

[Andrew Fish via groups.io]

> On May 9, 2022, at 2:42 AM, Boeuf, Sebastien  
> wrote:
> 
> Hi,
> 
> I have a question related to the MMIO accesses performed by OVMF that I
> can see are happening whenever PcdGet() is invoked. Could you tell me
> how PCD works that can explain why I can see some MMIO read accesses on
> address 0xFFFD5A24?
> 

Sebastien,

The PCD’s end up being build configurable. They can get compiled into 
constants, call a database. The database entries can get set by code, or mapped 
to NVRAM variables etc. Some of the PCD values are set as constants from the 
DSC file [Pcds*] sections. Also the name of the [Pcds*] in the DSC  maps for 
this platform what form the PCD takes. There are also PCDs in the FDF file that 
get setup base on the Flash Layout. There is a write up here: 
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/PCD/Pei/Pcd.inf

There is a PCD PEIM and it has a database that is build in and it provides a 
service. It pass info up in a HOB to the DXE version of the driver. 
https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Universal/PCD/Pei

How far did you get in the boot? What do you have on serial?

That address looks like it could be NVRAM or ROM. You can use a build report to 
figure out NVRAM addresses. The early code is XIP and it gets relocated to the 
FLASH address when it gets placed in the FV. You can figure these addresses out 
from the build map files. Examples for OVMF:
Build/OvmfX64/DEBUG_XCODE5/FV/SECFV.Fv.map
Build/OvmfX64/DEBUG_XCODE5/FV/PEIFV.Fv.map

> Also, I'm using the CloudHv target, meaning it's loaded as a PVH ELF
> binary, and therefore it's not loaded at address 0xFFC0. Instead
> it's loaded at address 0x4FFFD0. I did modify the FW_BASE_ADDRESS in
> OvmfPkgDefines.fdf.inc but I'm not sure that's the correct approach.
> What do you think about it?
> 

One “Pro Tip” is to pass --report-file=REPORTFILE to the build command. That 
build report is very useful debugging things. For example it will show you how 
the PCD values got set. 

So you modified the FW_BASE_ADDRESS under the !if $(FD_SIZE_IN_KB) == 4096? I 
think a some of those values are chained together? Also notice the NVRAM starts 
at the beginning of the ROM [1]. See FW_BASE_ADDRESS and CODE_BASE_ADDRESS. 

!if $(FD_SIZE_IN_KB) == 4096
DEFINE VARS_SIZE = 0x84000
DEFINE VARS_BLOCKS   = 0x84
DEFINE VARS_LIVE_SIZE= 0x4
DEFINE VARS_SPARE_SIZE   = 0x42000

DEFINE FW_BASE_ADDRESS   = 0xFFC0
DEFINE FW_SIZE   = 0x0040
DEFINE FW_BLOCKS = 0x400
DEFINE CODE_BASE_ADDRESS = 0xFFC84000
DEFINE CODE_SIZE = 0x0037C000
DEFINE CODE_BLOCKS   = 0x37C
DEFINE FVMAIN_SIZE   = 0x00348000
DEFINE SECFV_OFFSET  = 0x003CC000
DEFINE SECFV_SIZE= 0x34000
!endif


[1] https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgDefines.fdf.inc

Thanks,

Andrew Fish

PS Note sometimes I configure my builds to place this in the Build generated 
directories so it is ignored by git and always available per platform build. 
vmfPkg/build.sh -p OvmfPkg/CloudHv/CloudHvX64.dsc -a X64 -b DEBUG 
--report-file=build.log


> 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: 5 208 026.16 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.
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89626): https://edk2.groups.io/g/devel/message/89626
Mute This Topic: https://groups.io/mt/90985557/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Debug OVMF

[Andrew Fish via groups.io]

Sebastien,

The UEFI ROMs generally contain sets of PE/COFF images (drivers, apps, etc) 
that execute not at their linked address. These PE/COFF images have been 
stripped of debug information and optionally contain a PE/COFF debug directory 
entry that points to a file that contains the debug info. Generally for Windows 
this is a PDB file, for macOS it is a dSYM, for Linux it is the ELF. Given this 
we have to teach debuggers how to load EFI symbols.

The idea behind efi_gdb.py is to add a gdb command that can load EFI symbols. 
The idea is to take the PC/address/frame address and walk backwards to find the 
PE/COFF header. The PE/COFF header start gives you the load address and the 
PE/COFF debug directory entry lets you point gdb at the file with the symbols. 
If you are into EFI proper (DXE) you can also pass an —extended flag and the 
gdb command will use symbols from the frame to try and find the EFI System 
Table that contains a list of the load address of all the modules, and then 
load symbols for everything. 

Assuming you tell QEMU to create a gdb remote stub (-gdb tcp::9000)… TL;DR….

When OVMF is running from another terminal window gdb -ex "target remote 
localhost:9000" -ex "source efi_gdb.py” and that should connect to OVMF and 
load the EFI Symbols. 

There are some basic instructions in the header of the Python script. 
https://github.com/tianocore/edk2/blob/master/BaseTools/Scripts/efi_gdb.py

The efi_gdb.py script also adds some other useful EFI related gdb commands to 
dump things like Device Path, HOB, guid, and EFI System Tables. 

Caveat emptor there is a debugger agnostic script, efi_debugging.py, that needs 
to be next to efi_gdb.py. My daily driver is lldb so I wrote these scripts for 
lldb, and then ported to gdb with lots of interweb searching. But even if 
something goes wrong I can probably help out on the mailing list. 

Thanks,

Andrew Fish

PS It should be possible to use the efi_debugging.py Python classes with any 
debugger that supports Python, or to use the services from other gdb debugging 
scripts etc. 

> On May 9, 2022, at 3:00 AM, Boeuf, Sebastien  
> wrote:
> 
> On Mon, 2022-05-09 at 11:49 +0200, kra...@redhat.com 
>  wrote:
>> On Mon, May 09, 2022 at 09:32:52AM +, Boeuf, Sebastien wrote:
>>> Hi,
>>> 
>>> I'm trying to debug OVMF with gdb connected to Cloud Hypervisor but
>>> the
>>> problem is that the debug binary that I have generated doesn't
>>> contain
>>> any symbols. Do you know how to generate debug symbols for OVMF?
>> 
>> Build/OvmfX64/DEBUG_GCC5/X64/*.debug
>> 
>> You might want checkout BaseTools/Scripts/efi_*.py too (didn't try
>> them
>> myself yet).
> 
> Ah thanks for the pointers, I'll try these :)
> 
> 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: 5 208 026.16 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.
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89621): https://edk2.groups.io/g/devel/message/89621
Mute This Topic: https://groups.io/mt/90985478/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [rfc] Remove support for unsupported tool_chain_tags

[Andrew Fish via groups.io]

I can sign up to maintain XCODE. 

I think Rebecca has been running test builds with XCODE. 

The XCODE5 names comes from the compiler flags needing to change for Xcode 5. 
Yes 2013 called and wants it compiler back. 

Thanks,

Andrew Fish

> On May 2, 2022, at 4:24 PM, Sean  wrote:
> 
> As discussed at the weekly tools meeting, I am proposing that all unsupported 
> tool chains get removed from tools_def.template in the Basetools/Conf folder 
> (edk2/tools_def.template at master · tianocore/edk2 (github.com) 
> ).
> The fact that VS2008 is still listed there is proof of a problem.  Many 
> of these old tool chains are not available and if found would not reliably 
> work anyway (see dozens of emails on the list, most recent by rebecca).  
> 
> The suggestion from the tools meeting discussions is that we should setup 
> maintainers for each tool chain tag and any tool chain tag without a 
> maintainer would then be removed.  
> 
> Today the CI and PR system is testing the most recent versions of VS and GCC. 
>  As of this email that tag is VS2019 and GCC5.  There has also been a desire 
> to add clang (clangpdb tag) to the list of CI builds but it is currently only 
> partially supported and needs some community effort.  The GCC5 tag might need 
> more clarity as I know this supports many different versions so I am not sure 
> how to correctly communicate what is the actual supported version.  Maybe the 
> container discussion would help ([CI] Use containers on Linux · Discussion 
> #2732 · tianocore/edk2 (github.com) 
> ) and it could be N and 
> N-1 on the latest container images?  
> 
> 
> 
> Finally, the question is how to define a supported tool chain and what are 
> the expectations for the "maintainer".  I would propose two things. 
> 
> 1. A category/tag created for the tool chain in the issue tracking system and 
> the maintainer will be the default assigned owner for incoming bugs and is 
> responsible for triage and resolution.  
> 
> a. If all maintainers resign the community would be notified and if no 
> one came forward the toolchain would be dropped.  
> 
> b. If the tag had a high bug count and low resolution/response rate the 
> toolchain maintainer role would be re-evaluated.  
> 
> 2. At defined points in the edk2 development process, each package is 
> compiled in debug, release, and noopt for the toolchain for all supported 
> architectures.   The report is made available.  
> 
> A. Suggested at minimum for each hard freeze stable tag point but could 
> be CI, nightly, weekly, etc.  
> 
> B. Suggestion is this should somehow be automated for the CI system and 
> tool chains supported.  
> 
> 3. Update maintainers.txt to indicate tool chain maintainers
> 
> 
> 
> Please use this email and/or tools meeting to discuss the proposal or 
> becoming a toolchain maintainer. 
> 
> RFC will be implemented after the may stable tag if no issues are raised.  
> 
> 
> 
> Thanks
> 
> Sean
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89524): https://edk2.groups.io/g/devel/message/89524
Mute This Topic: https://groups.io/mt/90848478/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-discuss] GSoC Proposal

[Andrew Fish via groups.io]

> On Apr 14, 2022, at 6:06 PM, Nate DeSimone  
> wrote:
> 
> Hi Marvin,
> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Marvin
>> Häuser
>> Sent: Thursday, April 14, 2022 12:56 AM
>> To: disc...@edk2.groups.io; Desimone, Nathaniel L
>> 
>> Cc: Pedro Falcato ; edk2-devel-groups-io
>> ; adachristin...@gmail.com; Shi, Steven
>> 
>> Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal
>> 
>> I feel like there are so many much easier solutions to this problem that are 
>> at
>> most limited by the clear specification. The UEFI specification with regards 
>> to
>> booting and all of that obviously is of utmost importance.
> 
> If you have a better idea that retains compatibility with the existing UEFI 
> PI then I would be happy to hear it. Ultimately anything we do needs to be a 
> pure extension that retains compatibility with old code. Given that 
> restriction having the ability to coalesce all the LibraryClasses into a 
> single module and have cross-module linking seems like the best way to handle 
> it to me.
> 
>> The UEFI PI specification parts that deal about internal structure, as far 
>> as I know, are
>> only in place to make it easy to integrate Intel IP.
> 
> Its not just for Intel. The biggest reason for it to increase the 
> standardization of the boot flow across the PC ecosystem. We have learned 
> from experience that firmware is super critical to get a product out the door 
> but it is also difficult to write. So we try to make it as reusable as 
> humanly possible.
> 
>> In fact, I don’t *know*, but I’m pretty sure the very strict separation 
>> between PEI and DXE was
>> preserved mostly because MRC was 32-bit-only for a long time. Glad that
>> seems to have been resolved, AMD does memory init by PSP nowadays.
> 
> Having less complex early stages chain load more complex later stages is a 
> common design pattern in firmware, not just UEFI. For example, your typical 
> ARM system loads kinda like this:
> 
> PBL (SoC ROM) --> SBL (RAM Init) --> ARM Trust Zone --> Hypervisor --> EDK II 
> or U-Boot or LittleKernel (which runs android fastboot)
> 
> Comparing relative complexity I believe the Intel UEFI PI design is actually 
> pretty simple when you consider how much it gets done:
> 
> Ucode ROM --> SEC + PEI --> DXE + SMM + BDS
> 
> My biggest criticism of the design is that the strict separation between PEI 
> and DXE doesn't exist between DXE, SMM, and BDS 
> 
> There are a few reasons why PEI was 32-bit for quite some time. The biggest 
> one is the code size increase, 64-bit x86 code is 20-30% larger than 32-bit 
> x86 code. Since the only RAM Pre-Memory code has access to is the cache 
> onboard the processor and for security reasons all that code has to fit 
> within that RAM we generally do everything we can to make that image as small 
> as possible. Second, 64-bit requires a page table and since we desired to 
> keep PEI simple we tried to avoid that. Finally, the PI spec didn't allow a 
> 64-bit PEI until recently. MRC is 32-bit code just because that is what PEI 
> happens to be. Porting it to 64-bit is not terribly difficult.
> 
> Ultimately the mix of 32/64-bit does cause some difficulties. Any data 
> structures that get shared between PEI and DXE (HOBs, PCDs, etc.) need to 
> resolve to the same size and packing. LibraryClasses need to be written to 
> compile properly in both modes. In the case of FSP API mode you need to 
> resort to thunking between 32 and 64-bit modes during DXE. More or less we 
> decided that the costs are starting to outweigh the advantages.
> 

I’d also point out that x86 VMs use X64 (x86-64) PEI today and it works so the 
32-bit/64-bit mix has nothing to do with UEFI/PI/edk2. 

In the PC ecosystem a single chipset family can power thousands of unique 
designs. So the  DRAM memory needs to be external, support lots of different 
chipset packages(signal integrity...), support the lowest cost through the 
highest cost DRAM and thousands of different board layouts. So programing DRAM 
takes a masters degree in antenna design. I’ve seen MRC (Memory Reference Code) 
with over a MiB of DEBUG prints in it, and it literally is printing histograms 
of what it is tuning. So all this code has to run before the system has any 
DRAM, thus it is running using the cache as RAM. I’ve not looked at the x86 
architecture specs form the vendors in a while, but back in the day they did 
not support page tables in ROM or pinned cached. Now it might work, but if it 
breaks your CPU vendor blames you so you don’t code PEI in X64….

We contributed the 1st edk2 ARM platform, Beagle Board, and It was a long time 
ago but I seem to remember the mask ROM used a table in NOR FLASH to init 
memory and then copied an image from NOR FLASH into DRAM and jumped to it. So 
PEI is kind of not really needed and we implemented a PrePEI and jumped 
directly to DXE. 

Given I was around back in the day when all this stuff was designed I can say 
SEC was 

Re: [edk2-devel][PATCH v3 1/8] IntelFsp2Pkg: X64 compatible changes to support PEI in 64bit

[Andrew Fish via groups.io]

> On Apr 6, 2022, at 4:57 PM, Ni, Ray  wrote:
> 
>> -; UINT32
>> +; UINTN
>> ; EFIAPI
>> -; AsmReadEsp (
>> +; AsmReadStackPointer (
>> ;   VOID
>> ;   );
>> ;--
>> -global ASM_PFX(AsmReadEsp)
>> -ASM_PFX(AsmReadEsp):
>> +global ASM_PFX(AsmReadStackPointer)
>> +ASM_PFX(AsmReadStackPointer):
>> mov eax, esp
>> ret
>> 
> 
> I guess it's possible that bootloader sets up the stack above 4G.
> If that's the case, above code doesn't work.
> 
> 

Is there an issue with the SecSwitchStack too?

Thanks,

Andrew Fish

> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88483): https://edk2.groups.io/g/devel/message/88483
Mute This Topic: https://groups.io/mt/90294483/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] need help - edk2 build issue

[Andrew Fish via groups.io]

Sukumar,

The LongJump.iii is just the nasm file after it has been post processed you 
should be able to look at it. 

If I look at mine I see. 

44: rdsspq rax
...
49:incsspq rax

Those are some funky x86 instructions maybe your nasm is too old? 

This should be the required version I think:
https://github.com/tianocore/edk2/blob/master/BaseTools/Bin/nasm_ext_dep.yaml
{
  "id": "nasm-1",
  "scope": "edk2-build",
  "type": "nuget",
  "name": "mu_nasm",
  "source": "https://api.nuget.org/v3/index.json;,
  "version": "2.15.05",
  "flags": ["set_path", "host_specific"]
}

Thanks,

Andrew Fish

> On Apr 5, 2022, at 1:09 PM, Ghorai, Sukumar  wrote:
> 
> Hi,
> 
> would you pl help me to resolve this edk2 build issue (TOT codebase)?
> 
> sghorai@sghorai-desk3:~/work/edk2-tianocore/edk2-april05/edk2$ build -p 
> UefiPayloadPkg/UefiPayloadPkg.dsc -a IA32 -a X64 -t GCC5 -D 
> BOOTLOADER=COREBOOT
> Build environment: Linux-5.13.0-35-generic-x86_64-with-glibc2.29
> Build start time: 12:23:43, Apr.05 2022
> 
> WORKSPACE= /home/sghorai/work/edk2-tianocore/edk2-april05/edk2
> EDK_TOOLS_PATH   = 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/BaseTools
> CONF_PATH= /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/Conf
> PYTHON_COMMAND   = /usr/bin/python3.8
> 
> 
> Processing meta-data .
> Architecture(s)  = IA32 X64
> Build target = DEBUG
> Toolchain= GCC5
> 
> Active Platform  = 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/UefiPayloadPkg/UefiPayloadPkg.dsc
> ... done!
> Building ... 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
>  [X64]
> make: Nothing to be done for 'tbuild'.
> Building ... 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/MdePkg/Library/UefiLib/UefiLib.inf
>  [X64]
> make: Nothing to be done for 'tbuild'.
> Building ... 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
>  [X64]
> make: Nothing to be done for 'tbuild'.
> Building ... 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf
>  [X64]
> make: Nothing to be done for 'tbuild'.
> Building ... 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/UefiPayloadPkg/Library/DxeHobListLib/DxeHobListLib.inf
>  [X64]
> make: Nothing to be done for 'tbuild'.
> Building ... 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf
>  [X64]
> make: Nothing to be done for 'tbuild'.
> Building ... 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
>  [X64]
> make: Nothing to be done for 'tbuild'.
> Building ... 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
>  [X64]
> Building ... 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
>  [X64]
> make: Nothing to be done for 'tbuild'.
> make: Nothing to be done for 'tbuild'.
> Building ... 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
>  [X64]
> make: Nothing to be done for 'tbuild'.
> Building ... 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
>  [X64]
> make: Nothing to be done for 'tbuild'.
> Building ... 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/MdePkg/Library/BaseLib/BaseLib.inf
>  [X64]
> Trim --asm-file -o 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/Build/UefiPayloadPkgX64/DEBUG_GCC5/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/LongJump.i
>  -i 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/Build/UefiPayloadPkgX64/DEBUG_GCC5/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/inc.lst
>  
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/MdePkg/Library/BaseLib/X64/LongJump.nasm
> Building ... 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/MdePkg/Library/DxePcdLib/DxePcdLib.inf
>  [X64]
> make: Nothing to be done for 'tbuild'.
> Building ... 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/MdePkg/Library/RegisterFilterLibNull/RegisterFilterLibNull.inf
>  [X64]
> make: Nothing to be done for 'tbuild'.
> Building ... 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/UefiPayloadPkg/Library/DebugPrintErrorLevelLibHob/DebugPrintErrorLevelLibHob.inf
>  [X64]
> make: Nothing to be done for 'tbuild'.
> Building ... 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/UefiPayloadPkg/Library/DxeHobLib/DxeHobLib.inf
>  [X64]
> make: Nothing to be done for 'tbuild'.
> Building ... 
> /home/sghorai/work/edk2-tianocore/edk2-april05/edk2/MdePkg/Library/BasePrintLib/BasePrintLib.inf
>  [X64]
> make: Nothing to be done for 'tbuild'.
> "gcc" -MMD -MF 
> 

Re: [edk2-devel] CryptoPkg build broken using XCODE5 (Availability.h not found)

[Andrew Fish via groups.io]

Rebecca,

I got it to compile by doing this

diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf 
b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
index cdeed0d073eb..72dbeb2795e8 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
@@ -595,8 +595,8 @@ [BuildOptions]
   # 3017:  may be used before being set (NOTE: This was fixed in 
OpenSSL 1.1 HEAD with
   #   commit d9b8b89bec4480de3a10bdaf9425db371c19145b, and can be dropped 
then.)
   RVCT:*_*_ARM_CC_FLAGS = $(OPENSSL_FLAGS) 
--library_interface=aeabi_clib99 
--diag_suppress=1296,1295,550,1293,111,68,177,223,144,513,188,128,546,1,3017 
-JCryptoPkg/Include
-  XCODE:*_*_IA32_CC_FLAGS   = -mmmx -msse -U_WIN32 -U_WIN64 $(OPENSSL_FLAGS) 
-w -std=c99 -Wno-error=uninitialized
-  XCODE:*_*_X64_CC_FLAGS= -mmmx -msse -U_WIN32 -U_WIN64 $(OPENSSL_FLAGS) 
-w -std=c99 -Wno-error=uninitialized
+  XCODE:*_*_IA32_CC_FLAGS   = -mmmx -msse -U_WIN32 -U_WIN64 $(OPENSSL_FLAGS) 
-w -std=c99 -Wno-error=uninitialized -DOPENSSL_NO_APPLE_CRYPTO_RANDOM
+  XCODE:*_*_X64_CC_FLAGS= -mmmx -msse -U_WIN32 -U_WIN64 $(OPENSSL_FLAGS) 
-w -std=c99 -Wno-error=uninitialized -DOPENSSL_NO_APPLE_CRYPTO_RANDOM
 
   #
   # AARCH64 uses strict alignment and avoids SIMD registers for code that may 
execute


Thanks,

Andrew Fish

> On Mar 29, 2022, at 10:33 AM, Rebecca Cran  wrote:
> 
> A build of CryptoPkg with XCODE5 on macOS is now trying to include 
> Availability.h, which isn't found:
> 
> In file included from 
> /Users/bcran/src/uefi/edk2/CryptoPkg/Library/OpensslLib/openssl/crypto/init.c:13:
> /Users/bcran/src/uefi/edk2/CryptoPkg/Library/OpensslLib/openssl/include/crypto/rand.h:24:12:
>  fatal error: 'Availability.h' file not found
> #  include 
>^~~~
> 
> This is because of the following in 
> CryptoPkg/Library/OpensslLib/openssl/include/crypto/rand.h
> 
> # if defined(__APPLE__) && !defined(OPENSSL_NO_APPLE_CRYPTO_RANDOM)
> #  include 
> #  if (defined(__MAC_OS_X_VERSION_MIN_REQUIRED) && 
> __MAC_OS_X_VERSION_MIN_REQUIRED >= 101200) || \
>  (defined(__IPHONE_OS_VERSION_MIN_REQUIRED) && 
> __IPHONE_OS_VERSION_MIN_REQUIRED >= 8)
> #   define OPENSSL_APPLE_CRYPTO_RANDOM 1
> #   include 
> #   include 
> #  endif
> # endif
> 
> -- 
> Rebecca Cran
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88208): https://edk2.groups.io/g/devel/message/88208
Mute This Topic: https://groups.io/mt/90113674/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 3/3] Basetools: turn off gcc12 warning

[Andrew Fish via groups.io]

> On Mar 29, 2022, at 2:38 PM, Andrew Fish via groups.io 
>  wrote:
> 
> 
> 
>> On Mar 29, 2022, at 11:14 AM, gr...@grantlmul.xyz 
>> <mailto:gr...@grantlmul.xyz> wrote:
>> 
>> While I can't test this myself, the following does appear to result in a 
>> successful build using the same clang version:
>> 
>> 
>> diff --git a/BaseTools/Source/C/DevicePath/GNUmakefile 
>> b/BaseTools/Source/C/DevicePath/GNUmakefile
>> index b05d2bddfa..81aa35aa31 100644
>> --- a/BaseTools/Source/C/DevicePath/GNUmakefile
>> +++ b/BaseTools/Source/C/DevicePath/GNUmakefile
>> @@ -14,7 +14,9 @@ OBJECTS = DevicePath.o UefiDevicePathLib.o 
>> DevicePathFromText.o  DevicePathUtili
>>  include $(MAKEROOT)/Makefiles/app.makefile
>>  
>>  # gcc 12 trips over device path handling
>> -BUILD_CFLAGS += -Wno-error=stringop-overflow
>> +ifeq($(CC), gcc)
>> +  BUILD_CFLAGS += -Wno-error=stringop-overflow
>> +endif
>>  
> 
> Gerd,
> 
> I’m not sure if this was caused by my email client but your fix did not work 
> for me.
> GNUmakefile:17: *** missing separator.  Stop.
> 

Sorry I forgot to mention I was using an Xcode clang on macOS. 

Thanks,

Andrew Fish

> I had to add a space after `ifeq` to get it to work.
> diff --git a/BaseTools/Source/C/DevicePath/GNUmakefile 
> b/BaseTools/Source/C/DevicePath/GNUmakefile
> index b05d2bddfa68..ebab1d3e2617 100644
> --- a/BaseTools/Source/C/DevicePath/GNUmakefile
> +++ b/BaseTools/Source/C/DevicePath/GNUmakefile
> @@ -14,7 +14,9 @@ OBJECTS = DevicePath.o UefiDevicePathLib.o 
> DevicePathFromText.o  DevicePathUtili
>  include $(MAKEROOT)/Makefiles/app.makefile
>  
>  # gcc 12 trips over device path handling
> -BUILD_CFLAGS += -Wno-error=stringop-overflow
> +ifeq ($(CC), gcc)
> +  BUILD_CFLAGS += -Wno-error=stringop-overflow
> +endif
>  
>  LIBS = -lCommon
>  ifeq ($(CYGWIN), CYGWIN)
> 
> 
> I had been working around like this previously (I’m not sure about the 
> portability of -Wno-unknown-warning-option):
> 
> diff --git a/BaseTools/Source/C/DevicePath/GNUmakefile 
> b/BaseTools/Source/C/DevicePath/GNUmakefile
> index b05d2bddfa68..d08588a81f80 100644
> --- a/BaseTools/Source/C/DevicePath/GNUmakefile
> +++ b/BaseTools/Source/C/DevicePath/GNUmakefile
> @@ -14,7 +14,7 @@ OBJECTS = DevicePath.o UefiDevicePathLib.o 
> DevicePathFromText.o  DevicePathUtili
>  include $(MAKEROOT)/Makefiles/app.makefile
>  
>  # gcc 12 trips over device path handling
> -BUILD_CFLAGS += -Wno-error=stringop-overflow
> +BUILD_CFLAGS += -Wno-error=stringop-overflow -Wno-unknown-warning-option
>  
>  LIBS = -lCommon
>  ifeq ($(CYGWIN), CYGWIN)
> 
> Thanks,
> 
> Andrew Fish
>>  LIBS = -lCommon
>>  ifeq ($(CYGWIN), CYGWIN)
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88207): https://edk2.groups.io/g/devel/message/88207
Mute This Topic: https://groups.io/mt/89997416/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 3/3] Basetools: turn off gcc12 warning

[Andrew Fish via groups.io]

> On Mar 29, 2022, at 11:14 AM, gr...@grantlmul.xyz wrote:
> 
> While I can't test this myself, the following does appear to result in a 
> successful build using the same clang version:
> 
> 
> diff --git a/BaseTools/Source/C/DevicePath/GNUmakefile 
> b/BaseTools/Source/C/DevicePath/GNUmakefile
> index b05d2bddfa..81aa35aa31 100644
> --- a/BaseTools/Source/C/DevicePath/GNUmakefile
> +++ b/BaseTools/Source/C/DevicePath/GNUmakefile
> @@ -14,7 +14,9 @@ OBJECTS = DevicePath.o UefiDevicePathLib.o 
> DevicePathFromText.o  DevicePathUtili
>  include $(MAKEROOT)/Makefiles/app.makefile
>  
>  # gcc 12 trips over device path handling
> -BUILD_CFLAGS += -Wno-error=stringop-overflow
> +ifeq($(CC), gcc)
> +  BUILD_CFLAGS += -Wno-error=stringop-overflow
> +endif
>  

Gerd,

I’m not sure if this was caused by my email client but your fix did not work 
for me.
GNUmakefile:17: *** missing separator.  Stop.

I had to add a space after `ifeq` to get it to work.
diff --git a/BaseTools/Source/C/DevicePath/GNUmakefile 
b/BaseTools/Source/C/DevicePath/GNUmakefile
index b05d2bddfa68..ebab1d3e2617 100644
--- a/BaseTools/Source/C/DevicePath/GNUmakefile
+++ b/BaseTools/Source/C/DevicePath/GNUmakefile
@@ -14,7 +14,9 @@ OBJECTS = DevicePath.o UefiDevicePathLib.o 
DevicePathFromText.o  DevicePathUtili
 include $(MAKEROOT)/Makefiles/app.makefile
 
 # gcc 12 trips over device path handling
-BUILD_CFLAGS += -Wno-error=stringop-overflow
+ifeq ($(CC), gcc)
+  BUILD_CFLAGS += -Wno-error=stringop-overflow
+endif
 
 LIBS = -lCommon
 ifeq ($(CYGWIN), CYGWIN)


I had been working around like this previously (I’m not sure about the 
portability of -Wno-unknown-warning-option):

diff --git a/BaseTools/Source/C/DevicePath/GNUmakefile 
b/BaseTools/Source/C/DevicePath/GNUmakefile
index b05d2bddfa68..d08588a81f80 100644
--- a/BaseTools/Source/C/DevicePath/GNUmakefile
+++ b/BaseTools/Source/C/DevicePath/GNUmakefile
@@ -14,7 +14,7 @@ OBJECTS = DevicePath.o UefiDevicePathLib.o 
DevicePathFromText.o  DevicePathUtili
 include $(MAKEROOT)/Makefiles/app.makefile
 
 # gcc 12 trips over device path handling
-BUILD_CFLAGS += -Wno-error=stringop-overflow
+BUILD_CFLAGS += -Wno-error=stringop-overflow -Wno-unknown-warning-option
 
 LIBS = -lCommon
 ifeq ($(CYGWIN), CYGWIN)

Thanks,

Andrew Fish
>  LIBS = -lCommon
>  ifeq ($(CYGWIN), CYGWIN)
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88206): https://edk2.groups.io/g/devel/message/88206
Mute This Topic: https://groups.io/mt/89997416/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Question about UEFI, AddressSanitizer and MMU mappings

[Andrew Fish via groups.io]

>From an UEFI point of view if you own the memory you can do what you want with 
>it. The UEFI Spec does not deal with paging but the PI Spec does have 
>abstractions for how the CPU operates via the CPU ARCH Protocol [1].

So for example if you want to write protect the page tables, add guard page, or 
add a stack guard all that is OK and exists today [2].
PcdNullPointerDetectionPropertyMask
PcdInitValueInTempStack
PcdHeapGuardPageType
PcdHeapGuardPoolType
PcdHeapGuardPropertyMask
PcdHeapGuardPageType
PcdHeapGuardPropertyMask
PcdCpuStackGuard

Does Asan just need to force page faults? Or does it want to make virtual 
address mappings? 

If someone wants to work on ASan (or any of the other sanitizers) I’m happy to 
volunteer to consult. 

[1] 
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/Cpu.h#L221
[2] 
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/MdeModulePkg.dec#L979

Thanks,

Andrew Fish

> On Mar 25, 2022, at 2:07 AM, Marvin Häuser  wrote:
> 
> Hey Pedro,
> 
> ASan is somewhat listed for „LLVM Optimizations“.
> A quick and dirty reference for UEFI UBSan can be found here: 
> https://github.com/acidanthera/OpenCorePkg/tree/master/Library/OcGuardLib 
> 
> 
> I don’t think you need to strictly adhere to the UEFI spec for debug tooling. 
> I cannot check the code now, but I can imagine things like ConvertPointer() 
> will not be happy about non-identity-mapping OOTB. But the issues I can think 
> of should be fairly easy to resolve.
> 
> Best regards,
> Marvin
> 
>> On 24. Mar 2022, at 23:32, Pedro Falcato  wrote:
>> 
>> 
>> Hi!
>> 
>> I've been thinking about adding sanitizer support (UBSan and KASAN), like 
>> coreboot already has, to the wiki's Tasks for the upcoming GSoC, but I'm a 
>> bit confused by something.
>> Is there anything in the UEFI spec that stops us from doing non-identity 
>> memory mappings? I know it specifies the need for the identity mappings (in 
>> the architectures where it requires the MMU being enabled), but nowhere do I 
>> see anything about the other parts of the address space.
>> Of course, UEFI supporting AddressSanitizer would be kind of dependent on 
>> fancier memory mappings.
>> 
>> Thanks,
>> Pedro
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88030): https://edk2.groups.io/g/devel/message/88030
Mute This Topic: https://groups.io/mt/90010978/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Debugging scripts: "Add support for gdb and lldb"

[Andrew Fish via groups.io]

Rebecca,

That would be awesome. I’m happy to help, and answer questions. 

 I’ve been kind of swamped in my day job lately so this would really help. 

Thanks,

Andrew Fish

> On Mar 15, 2022, at 8:48 PM, Rebecca Cran  wrote:
> 
> Given the lack of progress on this for many months, I was wondering if I 
> should perhaps take this over and work on the changes needed to get this 
> functionality committed?
> 
> -- 
> Rebecca Cran
> 
> 
> On 2/10/22 12:13, Rebecca Cran wrote:
>> Andrew: We discussed your patch from August last year in today's Community 
>> Meeting.
>> 
>> The patch is https://edk2.groups.io/g/devel/message/78906, but it sounds as 
>> though there needs to be a v2 to move the files into BaseTools/Scripts based 
>> on recent discussions.
>> 
>> 
>> Mike: it looks like there weren't actually any reviews on it, so it'll need 
>> to wait until after the freeze.
>> 
>> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#87616): https://edk2.groups.io/g/devel/message/87616
Mute This Topic: https://groups.io/mt/89815211/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Unit Test and sanitizers

[Andrew Fish via groups.io]

Just throwing out an idea for the edk2 unit tests. At least for clang you can 
turn on the sanitizer via a simple command line flag to the compiler. So seems 
it would make sense to turn on it for unit tests? I’m not sure if the Linux 
clang, and maybe even some versions of gcc support this too?  Not clear how it 
works on VC++ or other compilers.

Here is a stupid example from the Xcode clang on macOS of what I’m talking 
about. In the 1st case the write to NULL crashes the test app with a seg fault. 
With the sanitizers the buffer overflow and UB  is detected. So the sanitizer 
gives you better test coverage for free and makes it much easier to root cause 
the failure.

~/work/Compiler/sanitize>cat t.c
  
int
main(int argc, char **argv)
{
  char test[1] = { 0 };
  char *ptr = [0];

#ifndef SKIP_OVERFLOW
  ptr += 2;
  *ptr = 1;
#endif
  
  ptr = (char *)0;
  *ptr = 2;
  return 0;
}
~/work/Compiler/sanitize>clang -g t.c && ./a.out
  
zsh: segmentation fault  ./a.out
~/work/Compiler/sanitize>clang -g -fsanitize=address -fsanitize=undefined  t.c 
&& ./a.out 
=
==5302==ERROR: AddressSanitizer: stack-buffer-overflow on address 
0x7ff7b066f7c2 at pc 0x00010f893db0 bp 0x7ff7b066f790 sp 0x7ff7b066f788
WRITE of size 1 at 0x7ff7b066f7c2 thread T0
#0 0x10f893daf in main t.c:9
#1 0x1129754fd in start dyldMain.cpp:879

Address 0x7ff7b066f7c2 is located in stack of thread T0 at offset 34 in frame
#0 0x10f893baf in main t.c:3

  This frame has 1 object(s):
[32, 33) 'test' (line 4) <== Memory access at offset 34 overflows this 
variable
HINT: this may be a false positive if your program uses some custom stack 
unwind mechanism, swapcontext or vfork
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow t.c:9 in main
Shadow bytes around the buggy address:
  0x1ffef60cdea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1ffef60cdeb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1ffef60cdec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1ffef60cded0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1ffef60cdee0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1ffef60cdef0: 00 00 00 00 f1 f1 f1 f1[01]f3 f3 f3 00 00 00 00
  0x1ffef60cdf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1ffef60cdf10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1ffef60cdf20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1ffef60cdf30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1ffef60cdf40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
  Shadow gap:  cc
==5302==ABORTING
zsh: abort  ./a.out
~/work/Compiler/sanitize>clang -g -fsanitize=address -fsanitize=undefined 
-DSKIP_OVERFLOW  t.c && ./a.out 
t.c:13:3: runtime error: store to null pointer of type 'char'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior t.c:13:3 in 
AddressSanitizer:DEADLYSIGNAL
=
==5312==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 
0x0001020cde3f bp 0x7ff7bde358c0 sp 0x7ff7bde357c0 T0)
==5312==The signal is caused by a WRITE memory access.
==5312==Hint: address points to the zero page.
#0 0x1020cde3f in main t.c:13
#1 0x108d414fd in start dyldMain.cpp:879

==5312==Register values:
rax = 0x  rbx = 0x7ff7bde35800  rcx = 0x7ff7bde357c0  
rdx = 0x1ffef7bc6af8  
rdi = 0x7ff7bde352f1  rsi = 0x  rbp = 0x7ff7bde358c0  
rsp = 0x7ff7bde357c0  
 r8 = 0x000102580480   r9 = 0x7ff7bde34a90  r10 = 0x  
r11 = 0x0206  
r12 = 0x000108db43a0  r13 = 0x7ff7bde35978  r14 = 0x0001020cdc80  
r15 = 0x000108da8010  
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV t.c:13 in main
==5312==ABORTING
zsh: abort  ./a.out

Thanks,

Andrew Fish

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86933): https://edk2.groups.io/g/devel/message/86933
Mute This Topic: https://groups.io/mt/89353871/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub 

Re: [edk2-devel] PcdDebugPropertyMask in DSC: How to I set different values for PEI and DXE?

[Andrew Fish via groups.io]

> On Feb 17, 2022, at 5:36 PM, Michael D Kinney  
> wrote:
> 
> Hi Andrew,
>  
> I forgot about the library constraints.
>  
> Unless we want to first add a feature to build a library instance for each 
> module type into
> a different build output directory, we cannot support setting a FixedAtBuild 
> PCD for each
> module type.
>  

Mike,

Yea I’m thinking this is a good reason to maybe not add more knobs. 

I was trying to get tricky and have code conditionally use a global so I could 
use the lib XIP when I shot myself in the foot. 

Thanks,

Andrew Fish

> If you use PatchableInModule, you can post process all the modules to set 
> individual
> module PCD values.  You have to do two steps.  One DSC to build all the 
> modules and
> generate AsBuiltInf.  2nd DSC/FDF that references the AsBuildInfs and sets 
> the 
> PatchableInModule PCD values in the scope of the modules needed.
>  
> The only reason the different ARCHs for PEI and DXE works is because the libs
> for each ARCH are build separately and already have different build output 
> locations.
>  
> Mike
>  
>  
>  
> From: Andrew Fish mailto:af...@apple.com>> 
> Sent: Thursday, February 17, 2022 4:42 PM
> To: devel@edk2.groups.io <mailto:devel@edk2.groups.io>; Oram, Isaac W 
> mailto:isaac.w.o...@intel.com>>
> Cc: Kinney, Michael D  <mailto:michael.d.kin...@intel.com>>
> Subject: Re: [edk2-devel] PcdDebugPropertyMask in DSC: How to I set different 
> values for PEI and DXE?
>  
>  
> 
> 
> On Feb 17, 2022, at 4:26 PM, Oram, Isaac W  <mailto:isaac.w.o...@intel.com>> wrote:
>  
> Andrew,
> 
> It is a reasonable ask, but I lean towards voting no.  We can more or less do 
> the equivalent by breaking a monolithic build into a set of phase specific 
> build/DSC/FDF or something similar.  That seems more flexible anyway.  Maybe 
> we want binaries with settings based on maturity more than phase.  And so on.
> 
> 
> My primary concern that the complexity added to an already complex feature.  
> PCD have a lot of binary compatibility challenges anyway.  And this doesn't 
> add any that don't already exist, but it does make it a lot easier to 
> introduce a mismatch issue.
> 
>  
> I shot my self in the foot with the Fixed* macro in a library so I did not 
> get the drivers override. So I feel that pain. You need to used the non Fixed 
> form from a lib to get the value from the global produced by the driver. 
> 
> 
> 
> My more recreational question is if this makes sense in most cases, or if 
> there are a limited set of PCD that it makes sense for.  A lot of similar PCD 
> are much more like shared constants and thus it doesn't make a lot of sense 
> for them to vary across executables.  E.G. drivers are asking for problems if 
> they change max string lengths inconsistently. There are definitely more than 
> one PCD where it seems reasonable.  Maybe they are the "wrong" type though.  
> Maybe they should be a dynamic type if a flexible usage is desired.
> 
>  
> I was trying to have different settings for 
> gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask is regards to the action taken 
> on an ASSERT. 
>  
> To be honest it was not my 1st choice and I was working around some early 
> boot exception handling code not saving the EFI_SYSTEM_CONTEXT and blocking 
> the scheme I was trying to use. 
> 
> 
> 
> Tangentially related, there was some previous work to make macros for phase 
> architectures.
> 
> [Defines]
>  PEI_ARCH= IA32
>  DXE_ARCH= X64
> 
> Enabling [Components.$(PEI_ARCH)] and [Components.$(DXE_ARCH)]
> 
>  
> In my case PEI_ARCH == DXE_ARCH so this kind of trick is not helpful. The 
> reality is this trick only works for non virtualized X64 platforms and the 
> edk2 supports a lot more flavors of platforms than X64. 
>  
> Thanks,
>  
> Andrew Fish
> 
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=2308 
> <https://bugzilla.tianocore.org/show_bug.cgi?id=2308>
> 
> If we do something with PCD, we should probably try to be consistent with 
> this and maybe extend it or integrate it into DSC syntax.  With standalone 
> MM, it probably makes more sense to have PEI, DXE, and SMM.  RT would also 
> make sense to have different settings.  I have mixed feelings about BDS.  I 
> think it makes sense to see it as a potentially independent phase that isn't 
> currently.  But also probably won't ever be independent from DXE.
> 
> Regards,
> Isaac
> 
> 
> -Original Message-
> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> 
> mailto:devel@edk2.groups.io>> On

Re: [edk2-devel] PcdDebugPropertyMask in DSC: How to I set different values for PEI and DXE?

[Andrew Fish via groups.io]

> On Feb 17, 2022, at 4:26 PM, Oram, Isaac W  wrote:
> 
> Andrew,
> 
> It is a reasonable ask, but I lean towards voting no.  We can more or less do 
> the equivalent by breaking a monolithic build into a set of phase specific 
> build/DSC/FDF or something similar.  That seems more flexible anyway.  Maybe 
> we want binaries with settings based on maturity more than phase.  And so on.
> 
> 
> My primary concern that the complexity added to an already complex feature.  
> PCD have a lot of binary compatibility challenges anyway.  And this doesn't 
> add any that don't already exist, but it does make it a lot easier to 
> introduce a mismatch issue.
> 

I shot my self in the foot with the Fixed* macro in a library so I did not get 
the drivers override. So I feel that pain. You need to used the non Fixed form 
from a lib to get the value from the global produced by the driver. 

> 
> My more recreational question is if this makes sense in most cases, or if 
> there are a limited set of PCD that it makes sense for.  A lot of similar PCD 
> are much more like shared constants and thus it doesn't make a lot of sense 
> for them to vary across executables.  E.G. drivers are asking for problems if 
> they change max string lengths inconsistently. There are definitely more than 
> one PCD where it seems reasonable.  Maybe they are the "wrong" type though.  
> Maybe they should be a dynamic type if a flexible usage is desired.
> 

I was trying to have different settings for 
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask is regards to the action taken on 
an ASSERT. 

To be honest it was not my 1st choice and I was working around some early boot 
exception handling code not saving the EFI_SYSTEM_CONTEXT and blocking the 
scheme I was trying to use. 

> 
> Tangentially related, there was some previous work to make macros for phase 
> architectures.
> 
> [Defines]
>  PEI_ARCH= IA32
>  DXE_ARCH= X64
> 
> Enabling [Components.$(PEI_ARCH)] and [Components.$(DXE_ARCH)]
> 

In my case PEI_ARCH == DXE_ARCH so this kind of trick is not helpful. The 
reality is this trick only works for non virtualized X64 platforms and the edk2 
supports a lot more flavors of platforms than X64. 

Thanks,

Andrew Fish

> https://bugzilla.tianocore.org/show_bug.cgi?id=2308 
> <https://bugzilla.tianocore.org/show_bug.cgi?id=2308>
> 
> If we do something with PCD, we should probably try to be consistent with 
> this and maybe extend it or integrate it into DSC syntax.  With standalone 
> MM, it probably makes more sense to have PEI, DXE, and SMM.  RT would also 
> make sense to have different settings.  I have mixed feelings about BDS.  I 
> think it makes sense to see it as a potentially independent phase that isn't 
> currently.  But also probably won't ever be independent from DXE.
> 
> Regards,
> Isaac
> 
> 
> -Original Message-
> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> 
> mailto:devel@edk2.groups.io>> On Behalf Of Andrew Fish 
> via groups.io <http://groups.io/>
> Sent: Thursday, February 17, 2022 12:22 PM
> To: Kinney, Michael D  <mailto:michael.d.kin...@intel.com>>
> Cc: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> Subject: Re: [edk2-devel] PcdDebugPropertyMask in DSC: How to I set different 
> values for PEI and DXE?
> 
> 
> 
>> On Feb 17, 2022, at 10:52 AM, Kinney, Michael D  
>> wrote:
>> 
>> I agree that your approach is the only way right now.
>> 
>> Do you have a feature request???
> 
> Well it does seem like a reasonable thing to be able to do? What do other 
> people think?
> 
> I was able to refactor my code and I did not actually end up needing to 
> override every PEIM and the PEI Core.
> 
> Thanks,
> 
> Andrew Fish
> 
>> 
>> Mike
>> 
>>> -Original Message-
>>> From: Andrew Fish 
>>> Sent: Wednesday, February 16, 2022 7:26 PM
>>> To: Kinney, Michael D 
>>> Cc: devel@edk2.groups.io
>>> Subject: Re: [edk2-devel] PcdDebugPropertyMask in DSC: How to I set 
>>> different values for PEI and DXE?
>>> 
>>> 
>>> 
>>>> On Feb 16, 2022, at 2:10 PM, Kinney, Michael D 
>>>>  wrote:
>>>> 
>>>> Hi Andrew,
>>>> 
>>>> Current DSC syntax for platform scoped [PcdsXXX] sections only 
>>>> supports CPU Arch and SKUID.
>>>> 
>>>> So there is no mechanism today to specify different PCD values based 
>>>> on module type.
>>>> 
>>>> You can manage this in the DSC file, but it does require the module 
>>>