[edk2-devel] VS2019 and AARCH64 with current EDKII mainline code.
Hi all, I've been trying to build the latest 2023 release of EDKII with AARCH64 using VS2019, and I'm encountering an issue with line 51 of MdePkg\Library\BaseLib\AArch64\SetJumpLongJump.asm. Specifically, there's no EXTERN for InternalAssertJumpBuffer and the 64 bit ARM cross assembler that comes with VS2019 does not support /D or -D so there's no way to set a flag that properly defines MDEPKG_NDEBUG. -PreDefine "MDEPKG_NDEBUG SETx blah" doesn't work either, because it doesn't declare MDEPKG_NDEBUG in a context that the assembler's preprocessor recognizes. How is this supposed to work, exactly? For now, I'm using my own version of BaseLib, so I can remove that code block from SetJumpLongJump.asm, or add the EXTERN, but that's far from ideal since I'd like to avoid maintaining my own copy of BaseLib just to fix a single build error. Regards, -Ken Taylor -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#116908): https://edk2.groups.io/g/devel/message/116908 Mute This Topic: https://groups.io/mt/105033123/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] Using the TCP->Accept interface.
Hi all, I hate to ask this, but has anyone used or tested the standard NetworkPkg TCP driver's socket Accept functionality? I've been trying to listen for a connection, but I can't seem to figure out how to configure the TCP interface correctly for this. I know the local IP address and listening port, but obviously the remote IP address and port won't be defined until a connection is established. But if I try to configure one thing without the other, I get all kinds of EFI_INVALID_PARAMETER errors. And if I don't specify anything but the listening port, I nothing seems able to connect. Regards, -Ken. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#77683): https://edk2.groups.io/g/devel/message/77683 Mute This Topic: https://groups.io/mt/84148178/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] ECC: Won't somebody PLEASE think of the... test structures.
If the structure is a non-static local variable, most compilers will silently
inject an intrinsic call to memcpy in function initialization. This leads to
an intermittent linker error.
If the compiler you use automatically supports an intrinsic memcpy in the given
architecture or optimizes out the memcpy, it will build for you and you won't
know you need to link to an intrinsic support library in order to build cross
platform. This leads to code that builds for you, but not for me.
Regards,
-Ken.
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Bret
Barkelew via groups.io
Sent: Thursday, September 24, 2020 6:23 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] ECC: Won't somebody PLEASE think of the... test
structures.
ERROR - EFI coding style error
ERROR - *Error code: 5007
ERROR - *There should be no initialization of a variable as part of its
declaration
ERROR - *file:
//home/corthon/_uefi/edk2_qemu_ci/edk2/MdeModulePkg/Library/VariablePolicyLib/VariablePolicyUnitTest/VariablePolicyUnitTest.c
ERROR - *Line number: 333
ERROR - *Variable Name: MatchCheckPolicy
EccCheck no likey:
SIMPLE_VARIABLE_POLICY_ENTRY ValidationPolicy = {
{
VARIABLE_POLICY_ENTRY_REVISION,
sizeof(VARIABLE_POLICY_ENTRY) + sizeof(TEST_VAR_1_NAME),
sizeof(VARIABLE_POLICY_ENTRY),
TEST_GUID_1,
TEST_POLICY_MIN_SIZE_NULL,
TEST_POLICY_MAX_SIZE_NULL,
TEST_POLICY_ATTRIBUTES_NULL,
TEST_POLICY_ATTRIBUTES_NULL,
VARIABLE_POLICY_TYPE_NO_LOCK
},
TEST_VAR_1_NAME
};
But you can't init this structure separately without addressing each field.
Can a brother get an override?
- Bret
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#65597): https://edk2.groups.io/g/devel/message/65597
Mute This Topic: https://groups.io/mt/77071159/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] HiiDatabaseDxe, ConfigRouting.c, GetElementsFromRequest.
Hi All, I recently encountered an ASSERT in the GetElementsFromRequest function in HiiDatabaseDxe that caused me some vexation. Specifically, this function ASSERTs (TmpRequest != NULL) if L"PATH=" is not found in a ConfigRequest string. The problem here is that it's possible for code that is remote from this function to trigger that assert via a call to EFI_HII_CONFIG_ACCESS_PROTOCOL->ExtractConfig () with a valid pointer to a garbage request string (or a request string with no L"PATH=" in it). In a debug build, this is troubling, as it's hard to figure out which call to ExtractConfig failed without unwinding the stack or instrumenting every call. However, in a release build, the ASSERT (of course) falls through, and the very next line does two StrStr (NULL, L"...") while evaluating a condition. This looks like a NULL pointer reference at runtime to me, particularly after reviewing StrStr in MdePkg/Library/BaseLib/String.c. Maybe instead of just falling through and doing one or more StrStr (NULL) calls, the release build should return FALSE if TmpRequest == NULL. And maybe the parameter checking in the upstream protocol interface implementations calling GetElementsFromRequest should verify that request strings passed in from external code contain at least one L"PATH=" instance after checking for NULL, and return EFI_INVALID_PARAMETER if they do not, prior to getting anywhere near calling GetElementsFromRequest. Regards, -Ken. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#62711): https://edk2.groups.io/g/devel/message/62711 Mute This Topic: https://groups.io/mt/75553629/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] PCD EX interface.
Hi all, I'm trying to access a PCD in a build independent manner. Specifically, moving forward, I want to write a PCD value in my BIOS code during PEI phase, and then read back the value of that PCD in a build independent shell utility (or identify and report situations in which the PCD is not found). I figure this is a good time to use [PcdsDynamicEx] in the build, because standard PCDs are assigned a build specific token, which kind of defeats my purpose. At first, everything seemed to be working okay. A call to PcdGetEx8 returned 0 on a build in which the PCD was undefined. Then I tried a build in which I wrote the PCD, and I got back a random number other than 0 or what I'd written to the PCD in the BIOS. Then, I decided to try PcdGetExSize to see if the PCD was even defined properly defined... at which point my shell utility locked up. So a little debugging later, and I discover that I'm hitting an ASSERT because the GUID my utility is passing to the DXE PCD service isn't being found in the list of GUIDs. Probably an error in my build or build tool configuration, so I'll have to sort that out. That's on me. But now I've got a problem: If I try to get the size of a DynamicEx PCD in the context of a BIOS build for which that PCD is undefined, the call locks up. I expected to just get a size of 0, since the PCD is not defined in the build context of the PCD DXE service. Is this a problem that's been fixed since my BIOS source code was cut? What can I do for older builds that haven't been fixed (and probably never will)? Do I have to just accept that I'm going to get garbage or lockup if I run my shell utility on some builds? Do I have to write a DXE driver and expose a protocol, just so I can know if that PCD exists and is properly defined? Is the idea that I might want to do this unreasonable? Should I just give up and use a HOB or a variable? Regards, -Ken. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#53435): https://edk2.groups.io/g/devel/message/53435 Mute This Topic: https://groups.io/mt/70044584/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
