Re: [PATCH 0/2] [gdb/python] Remove Py_RETURN_{NONE,TRUE,FALSE}

[Tom de Vries <tdevries@suse.de>]

On 5/13/26 4:44 PM, Tom Tromey wrote:
> Tom> The only point of it seems to be to increase the reference count on the
> Tom> Py_None object for older python versions.
> 
> Tom> ISTM unnecessary to increase the reference count for each Py_RETURN_NONE use.
> 
> I mentioned this in the bug, but for the record on the list, I think
> this patch will not work for versions of Python before the immortality
> changes.
> 

Hi Tom,

thank you for review comments.

I can confirm that this is the case.  I ran into a test failures with 
python 3.6, and managed to fix some of them by making gdbpy_ref aware of 
None/True/False:
...
diff --git a/gdb/python/py-ref.h b/gdb/python/py-ref.h
index dc0b14814af..b2eb2811408 100644
--- a/gdb/python/py-ref.h
+++ b/gdb/python/py-ref.h
@@ -27,11 +27,19 @@ struct gdbpy_ref_policy
  {
    static void incref (PyObject *ptr)
    {
+    if (ptr == Py_None
+	|| ptr == Py_True
+	|| ptr == Py_False)
+      return;
      Py_INCREF (ptr);
    }

    static void decref (PyObject *ptr)
    {
+    if (ptr == Py_None
+	|| ptr == Py_True
+	|| ptr == Py_False)
+      return;
      Py_DECREF (ptr);
    }
  };
...
but a few test-cases still failed, AFAIU because of using Py_DECREF on 
None/True/False.

I could have tried to fix this by replacing Py_DECREF et al by 
gdb-specific overrides that handle None/True/False in the appropriate 
way, but that would be way beyond the scope of what I was trying to achieve.

So instead, I've written a v2 that wraps Py_RETURN_{NONE,FALSE,TRUE} in 
functions that return gdbpy_ref, and used those instead ( 
https://sourceware.org/pipermail/gdb-patches/2026-May/227374.html ).

Please let me know what you think about this approach.

Thanks,
- Tom

> In particular if a gdb method returns a new reference, it means the
> caller is free to decref the reference.  However this series changes gdb
> to assume that the decref will not happen for certain objects.
> 
> thanks,
> Tom