On Tue, Aug 15, 2023 at 1:23 AM Andrew (EFI) Fish <af...@apple.com> wrote:
>
>
>
> On Aug 14, 2023, at 3:51 PM, Pedro Falcato <pedro.falc...@gmail.com> wrote:
>
> On Mon, Aug 14, 2023 at 9:49 PM Michael Kubacki
> <mikub...@linux.microsoft.com> wrote:
>
>
> From: Michael Kubacki <michael.kuba...@microsoft.com>
>
> 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.
I don't think the upstream compiler folks are willing to support our
broken printf variant. Nor should we encourage things like
VOID
Foo (
UINTN Val
)
{
DEBUG ((DEBUG_INFO, "%Lx", (UINT64) Val);
}
while not providing anything that looks but doesn't look like normal C
printf semantics.
--
Pedro
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107748): https://edk2.groups.io/g/devel/message/107748
Mute This Topic: https://groups.io/mt/100745693/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
