Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add debug level prefix for advanced logger memory message entries (#523)
# Preface Please ensure you have read the [contribution docs](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md) prior to submitting the pull request. In particular, [pull request guidelines](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md#pull-request-best-practices). ## Description This change added the existing metadata - debug level into the final advanced logger memory entries, it can differentiate the different debug levels, DEBUG_INFO, DEBUG_ERROR, etc. We don't need to touch firmware as debug level info is already part of metadata, so we only need to update the decode script. It's useful to be able to filter out the specific debug level msgs that we care about and make data processing of uefi logs possible. For example, DEBUG_ERROR level prints are generally very important and worth analyzing. One blocking thing now is that we can't tell the difference between different debug level msgs because not all DEBUG_ERROR will have an "error:" as the prefix of the debug msg, and search for "error" will also be noisy as it's a commonly used word. After this PR checked in, we can easily track the DEBUG_ERRORs. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [ ] Impacts functionality? - **Functionality** - Does the change ultimately impact how firmware functions? - Examples: Add a new library, publish a new PPI, update an algorithm, ... - [ ] Impacts security? - **Security** - Does the change have a direct security impact on an application, flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter validation improvement, ... - [ ] Breaking change? - **Breaking change** - Will anyone consuming this change experience a break in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call a function in a new library class in a pre-existing module, ... - [ ] Includes tests? - **Tests** - Does the change include any explicit test code? - Examples: Unit tests, integration tests, robot tests, ... - [ ] Includes documentation? - **Documentation** - Does the change contain explicit documentation additions outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation on an a separate Web page, ... ## How This Was Tested Tested with a platform that uses advancedlogger and can seedebug level prefixes in the msg. 22:36:22.840 : [MM_CORE] [DEBUG_INFO]AdvancedLoggerGetLoggerInfo: LoggerInfo=70F37000 22:36:22.857 : [MM_CORE] [DEBUG_ERROR]ERROR - The FV at 0xFFE60000 is invalid! ## Integration Instructions N/A --------- Co-authored-by: kenlautner <85201046+kenlautner@users.noreply.github.com>
- Loading branch information