linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v1] scripts/gdb: fix parsing of MNT_* constants
@ 2025-06-01  5:50 Tony Ambardar
  2025-06-03  4:42 ` Stephen Brennan
  0 siblings, 1 reply; 5+ messages in thread
From: Tony Ambardar @ 2025-06-01  5:50 UTC (permalink / raw)
  To: linux-kernel, linux-debuggers
  Cc: Tony Ambardar, Jan Kiszka, Kieran Bingham, Stephen Brennan,
	Christian Brauner

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>
---
 scripts/gdb/linux/constants.py.in | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/scripts/gdb/linux/constants.py.in b/scripts/gdb/linux/constants.py.in
index fd6bd69c5096..d5e3069f42a7 100644
--- a/scripts/gdb/linux/constants.py.in
+++ b/scripts/gdb/linux/constants.py.in
@@ -73,12 +73,12 @@ if IS_BUILTIN(CONFIG_MODULES):
     LX_GDBPARSED(MOD_RO_AFTER_INIT)
 
 /* linux/mount.h */
-LX_VALUE(MNT_NOSUID)
-LX_VALUE(MNT_NODEV)
-LX_VALUE(MNT_NOEXEC)
-LX_VALUE(MNT_NOATIME)
-LX_VALUE(MNT_NODIRATIME)
-LX_VALUE(MNT_RELATIME)
+LX_GDBPARSED(MNT_NOSUID)
+LX_GDBPARSED(MNT_NODEV)
+LX_GDBPARSED(MNT_NOEXEC)
+LX_GDBPARSED(MNT_NOATIME)
+LX_GDBPARSED(MNT_NODIRATIME)
+LX_GDBPARSED(MNT_RELATIME)
 
 /* linux/threads.h */
 LX_VALUE(NR_CPUS)
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH v1] scripts/gdb: fix parsing of MNT_* constants
  2025-06-01  5:50 [PATCH v1] scripts/gdb: fix parsing of MNT_* constants Tony Ambardar
@ 2025-06-03  4:42 ` Stephen Brennan
  2025-06-03 16:17   ` Florian Fainelli
  0 siblings, 1 reply; 5+ messages in thread
From: Stephen Brennan @ 2025-06-03  4:42 UTC (permalink / raw)
  To: Tony Ambardar, linux-kernel, linux-debuggers
  Cc: Jan Kiszka, Kieran Bingham, Christian Brauner

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>

> ---
>  scripts/gdb/linux/constants.py.in | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/scripts/gdb/linux/constants.py.in b/scripts/gdb/linux/constants.py.in
> index fd6bd69c5096..d5e3069f42a7 100644
> --- a/scripts/gdb/linux/constants.py.in
> +++ b/scripts/gdb/linux/constants.py.in
> @@ -73,12 +73,12 @@ if IS_BUILTIN(CONFIG_MODULES):
>      LX_GDBPARSED(MOD_RO_AFTER_INIT)
>  
>  /* linux/mount.h */
> -LX_VALUE(MNT_NOSUID)
> -LX_VALUE(MNT_NODEV)
> -LX_VALUE(MNT_NOEXEC)
> -LX_VALUE(MNT_NOATIME)
> -LX_VALUE(MNT_NODIRATIME)
> -LX_VALUE(MNT_RELATIME)
> +LX_GDBPARSED(MNT_NOSUID)
> +LX_GDBPARSED(MNT_NODEV)
> +LX_GDBPARSED(MNT_NOEXEC)
> +LX_GDBPARSED(MNT_NOATIME)
> +LX_GDBPARSED(MNT_NODIRATIME)
> +LX_GDBPARSED(MNT_RELATIME)
>  
>  /* linux/threads.h */
>  LX_VALUE(NR_CPUS)


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v1] scripts/gdb: fix parsing of MNT_* constants
  2025-06-03  4:42 ` Stephen Brennan
@ 2025-06-03 16:17   ` Florian Fainelli
  2025-06-19 21:51     ` Florian Fainelli
  0 siblings, 1 reply; 5+ messages in thread
From: Florian Fainelli @ 2025-06-03 16:17 UTC (permalink / raw)
  To: Stephen Brennan, Tony Ambardar, linux-kernel, linux-debuggers
  Cc: Jan Kiszka, Kieran Bingham, Christian Brauner

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...

Thanks
-- 
Florian


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v1] scripts/gdb: fix parsing of MNT_* constants
  2025-06-03 16:17   ` Florian Fainelli
@ 2025-06-19 21:51     ` Florian Fainelli
  2025-06-20  5:50       ` Jan Kiszka
  0 siblings, 1 reply; 5+ messages in thread
From: Florian Fainelli @ 2025-06-19 21:51 UTC (permalink / raw)
  To: Stephen Brennan, Tony Ambardar, linux-kernel, linux-debuggers
  Cc: Jan Kiszka, Kieran Bingham, Christian Brauner

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!
-- 
Florian

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v1] scripts/gdb: fix parsing of MNT_* constants
  2025-06-19 21:51     ` Florian Fainelli
@ 2025-06-20  5:50       ` Jan Kiszka
  0 siblings, 0 replies; 5+ messages in thread
From: Jan Kiszka @ 2025-06-20  5:50 UTC (permalink / raw)
  To: Florian Fainelli, Stephen Brennan, Tony Ambardar, linux-kernel,
	linux-debuggers
  Cc: Kieran Bingham, Christian Brauner

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2025-06-20  5:50 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-01  5:50 [PATCH v1] scripts/gdb: fix parsing of MNT_* constants Tony Ambardar
2025-06-03  4:42 ` Stephen Brennan
2025-06-03 16:17   ` Florian Fainelli
2025-06-19 21:51     ` Florian Fainelli
2025-06-20  5:50       ` Jan Kiszka

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).