> On Aug 14, 2023, at 5:26 PM, Michael Kubacki <mikub...@linux.microsoft.com>
> wrote:
>
> On 8/14/2023 8:23 PM, Andrew Fish via groups.io 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 <mailto: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 <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]
-=-=-=-=-=-=-=-=-=-=-=-
