Re: [PATCH v1] scripts/gdb: fix parsing of MNT_* constants

[Jan Kiszka <jan.kiszka@siemens.com>]

On 19.06.25 23:51, Florian Fainelli wrote:
> On 6/3/25 09:17, Florian Fainelli wrote:
>> On 6/2/25 21:42, Stephen Brennan wrote:
>>> On 5/31/25 22:50, Tony Ambardar wrote:
>>>> Recently, constants in linux/mount.h were changed from integer macros
>>>> parsable by LX_VALUE() to enums which are not, thus breaking gdb python
>>>> scripts:
>>>>
>>>>    Reading symbols from vmlinux...
>>>>    Traceback (most recent call last):
>>>>      File ".../linux/vmlinux-gdb.py", line 25, in <module>
>>>>        import linux.constants
>>>>      File ".../linux/scripts/gdb/linux/constants.py", line 19, in
>>>> <module>
>>>>        LX_MNT_NOSUID = MNT_NOSUID
>>>>    NameError: name 'MNT_NOSUID' is not defined
>>>>
>>>> Update to parse with LX_GDBPARSED(), which correctly handles enums.
>>>>
>>>> Fixes: 101f2bbab541 ("fs: convert mount flags to enum")
>>>> Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
>>>
>>> Hi Tony,
>>>
>>> I was totally unaware that these constants were being consumed by
>>> another debugger, and having fixed them for one, I broke them for
>>> another!
>>>
>>> Thanks for the fix. Having read through the preprocessor magic and this
>>> change, they make sense to me. In the future, I'll be sure to make an
>>> extra check for GDB users when updating enums.
>>>
>>> Reviewed-by: Stephen Brennan <stephen.s.brennan@oracle.com>
>>
>> Not targeted to anyone in particular but this is a recurring problem,
>> the GDB scripts are typically not part of any CI and it is not natural
>> to grep for constant names outside of the C/Rust code where they are
>> being used...
>>
>> I suppose that QEMU it should be much easier to ensure that GDB
>> scripts are being exercised than with my current set-up using OpenOCD
>> + real hardware...
> 
> And also:
> 
> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
> 
> Jan, Kieran, can you please pick this up? Thanks!

Thanks for all the fixes. The version of Johannes has already been 
queued up by Andrew:

https://lore.kernel.org/mm-commits/20250618223437.C3BB2C4CEE7@smtp.kernel.org/T/#u

Regarding automated testing: This would indeed be a valuable addition. 
Some QEMU-based tests should suffice, but I do not know where those 
could be best hooked into for broad visibility. To my understanding, 
KernelCI is right now focusing on single device boot tests, and we would 
rather need some backend/frontend test setup here even when only using a 
virtual device. Some self-built pipeline could provide that as well - 
but where/how to report findings then? Ideas welcome.

And then it would obviously also need some folks willing to contribute 
the actual test cases.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center