Tianocore/edk2.git/MdePkg/Include/Library/DebugLib.h, branch master

MdePkg/DebugLib: add DEBUG_PAGING

2026-03-23T09:55:50+00:00

Add new log bit for all paging-related log messages, i.e. page table updates because of memory encryption or memory attribute changes. Signed-off-by: Gerd Hoffmann

MdePkg: Replace include guards with #pragma once

2026-02-23T21:01:28+00:00

Replace traditional `#ifndef`/`#define`/`#endif` include guards with `#pragma` once. `#pragma once` is a widely supported preprocessor directive that prevents header files from being included multiple times. It is supported by all toolchains used to build edk2: GCC, Clang/LLVM, and MSVC. Compared to macro-based include guards, `#pragma once`: - Eliminates the risk of macro name collisions or copy/paste errors where two headers inadvertently use the same guard macro. - Eliminate inconsistency in the way include guard macros are named (e.g., some files use `__FILE_H__`, others use `FILE_H_`, etc.). - Reduces boilerplate (three lines replaced by one). - Avoids polluting the macro namespace with guard symbols. - Can improve build times as the preprocessor can skip re-opening the file entirely, rather than re-reading it to find the matching `#endif` ("multiple-include optimization"). - Note that some compilers may already optimize traditional include guards, by recognzining the idiomatic pattern. This change is made acknowledging that overall portability of the code will technically be reduced, as `#pragma once` is not part of the C/C++ standards. However, this is considered acceptable given: 1. edk2 already defines a subset of supported compilers in BaseTools/Conf/tools_def.template, all of which have supported `#pragma once` for over two decades. 2. There have been concerns raised to the project about inconsistent include guard naming and potential macro collisions. Approximate compiler support dates: - MSVC: Supported since Visual C++ 4.2 (1996) - GCC: Supported since 3.4 (2004) (http://gnu.ist.utl.pt/software/gcc/gcc-3.4/changes.html) - Clang (LLVM based): Since initial release in 2007 Signed-off-by: Michael Kubacki

MdePkg: Fix property typos in MdePkg

2026-01-26T08:44:12+00:00

The word property is misspelled as propery, so fix it. Signed-off-by: Qihang Gao

MdePkg: Add DEBUG_SECURITY Bit in PcdDebugPrintErrorLevel

2025-07-14T07:25:12+00:00

Tcg2Dxe and its libraries are currently the noisiest modules in edk2. For a sample platform printing at INFO level, Tcg2Dxe printed 4,000 lines out of 5,700 total lines printed. This commit defines a DEBUG_SECURITY bit to control the debug output of Tcg2Dxe and other security related components. Most of the output is not useful except for deep debugging of TPM transactions, so it is appropriate to only print when the DEBUG_SECURITY bit is present. Signed-off-by: Oliver Smith-Denny

MdePkg: Fix null macros for XCODE5 and CLANG

2024-10-18T16:22:07+00:00

When building OvmfPkg in RELEASE mode in the XCODE5 toolchain, the ASSERT_EFI_ERROR change prevents this error: .../MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:141:15: error: variable 'Status' set but not used [-Werror,-Wunused-but-set-variable] EFI_STATUS Status; ^ which is currently stopping the build. When building in RELEASE mode in the CLANGPDB toolchain,the DEBUG macro change prevents this error: .../edk2/OvmfPkg/VirtioSerialDxe/VirtioSerial.c:28:22: error: variable 'EventNames' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration] STATIC CONST CHAR8 *EventNames[] = { ^ which is currently stopping the build. CLANGDWARF produces the same error as CLANGPDB above, if -Wno-unneeded-internal-declaration is removed from its build flags. With the null DEBUG macro change, this warning suppression can be removed from CLANGDWARF, which is considered a benefit as it has the potential to catch real coding errors. This is done in a subsequent commit. This commit has the desirable side effect that we no longer require (and cannot use) explicit `#ifndef MDEPKG_NDEBUG` around items only used in DEBUG macros. This requires the ArmPkg change made here to be in the same commit as the MdePkg changes. Note: In common with existing macros in EDK II, including the pre-existing and unchanged DEBUG/NOOPT versions of the macros which are modified here, we use the standard approach of adding `do { ... } while (FALSE)` wrapping to ensure that the macros behave correctly with surrounding code (e.g. require a following ';' and do not combine in unexpected ways with nearby conditionals). Continuous-integration-options: PatchCheck.ignore-multi-package Co-authored-by: Mikhail Krichanov Signed-off-by: Mike Beaton

MdePkg: DebugLib: Check Signature in CR in Release Builds

2024-10-08T00:31:58+00:00

The CR macro is used to access an enclosing structure from a pointer within the structure. In DEBUG builds (i.e. when MDEPKG_NDEBUG is not set and debug asserts are enabled), this macro does signature validation checking to ensure that the structure that has been found is the correct structure, based on a signature passed in by the caller. However, if MDEPKG_NDEBUG is set or debug asserts are disabled, no signature validation is performed, meaning that CR may return an invalid structure that the caller believes is valid and has had signature validation on, causing undefined behavior (memory corruption). We should where at all possible have defined behavior, particularly in RELEASE builds, which are what typical platforms will ship to consumers. This patch updates CR to do the signature validation in all scenarios to provide defined behavior from the macro. In the event of a signature failure, CR will either 1) assert if !MDEPKG_NDEBUG and debug asserts are enabled (existing behavior) or 2) return NULL to indicate to the caller that signature validation failed. There exist consumers today who already, erroneously, rely on this behavior. Another macro, BASE_CR, exists for callers who do not wish to perform signature validation. Any code that wishes to avoid the signature validation should move to this macro. Signed-off-by: Oliver Smith-Denny

MdePkg: Fix DEBUG_CODE and PERF_CODE macros for XCODE5

2024-09-27T16:57:36+00:00

Without these changes, we get the error: error: variable '__DebugCodeLocal' set but not used from the DebugLib.h DEBUG_CODE_BEGIN()/END() macros on XCODE5. Similarly, in NOOPT builds only, we get: error: variable '__PerformanceCodeLocal' set but not used from the PerformanceLib.h PERF_CODE_BEGIN()/END() macros on XCODE5. It is important to note that the previous code involving a local variable was intended to ensure correct behaviour of ; following the macros, in particular that ; should be required: - https://github.com/tianocore/edk2/pull/6226#issuecomment-2364087866 - https://github.com/tianocore/edk2/pull/6226#issuecomment-2364619759 This converted version repeats the standard do { ... } while (FALSE) idiom (which is already used in the END macro) to achieve the same affect. The modified versions work on all toolchains. Signed-off-by: Mike Beaton

MdePkg DebugLib: Enable FILE NAME as DEBUG ASSERT for GCC12

2024-09-13T12:45:29+00:00

Using __FILE_NAME__ is useful for reducing the size of debug image and it's also good for reproducable builds. The gcc-12 also supported this macro. Ref: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=1a9b3f04c11eb467a8dc504a37dad57a371a0d4c This patch removed the checking of __clang__ when using __FILE_NAME__. References: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42579 Signed-off-by: Chun-Yi Lee

MdePkg/Include: Rename _DEBUG() to address name collision

2024-02-14T02:37:16+00:00

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4683 When VS20xx host-based unit tests are built with debug libraries a name collision occurs with the DebugLib.h internal macro _DEBUG(). Rename this internal macro to _DEBUGLIB_DEBUG() to address the name collision. Cc: Liming Gao Cc: Zhiguang Liu Signed-off-by: Michael D Kinney Reviewed-by: Leif Lindholm

MdePkg: Improve wording of manageability debug level comment

2023-12-11T17:07:03+00:00

Improve the wording of the comment explaining the DEBUG_MANAGEABILITY debug level. Signed-off-by: Rebecca Cran Reviewed-by: Michael D Kinney