[PATCH] Allow conversion of 128-bit integers to Python

[PATCH] Allow conversion of 128-bit integers to Python

[Tom Tromey]

Currently, trying to convert a 128-bit integer from a gdb.Value to a
Python integer will fail.  This is surprising because Python uses
bigints internally.

The bug here is that valpy_long uses value_as_long, which fails for
anything wider than LONGEST.  This patch fixes the problem by using
the recommended Python API.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33366
---
 gdb/python/py-value.c                 | 41 +++++++++++++++++++++++----
 gdb/testsuite/gdb.python/py-value.exp | 12 ++++++++
 2 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/gdb/python/py-value.c b/gdb/python/py-value.c
index 833ce26d5a3..973785b5e4a 100644
--- a/gdb/python/py-value.c
+++ b/gdb/python/py-value.c
@@ -1866,7 +1866,7 @@ valpy_long (PyObject *self)
 {
   struct value *value = ((value_object *) self)->value;
   struct type *type = value->type ();
-  LONGEST l = 0;
+  PyObject *result;
 
   try
     {
@@ -1882,17 +1882,46 @@ valpy_long (PyObject *self)
 	  && type->code () != TYPE_CODE_PTR)
 	error (_("Cannot convert value to long."));
 
-      l = value_as_long (value);
+      gdb::array_view<const gdb_byte> contents = value->contents ();
+#if PY_VERSION_HEX >= 0x030d0000
+      int flags = (type_byte_order (type) == BFD_ENDIAN_BIG
+		   ? Py_ASNATIVEBYTES_BIG_ENDIAN
+		   : Py_ASNATIVEBYTES_LITTLE_ENDIAN);
+      if (type->is_unsigned ())
+	flags |= Py_ASNATIVEBYTES_UNSIGNED_BUFFER;
+      result = PyLong_FromNativeBytes (contents.data (), contents.size (),
+				       flags);
+#else
+      /* We need this roundabout approach because int.from_bytes
+	 requires "signed" to be a keyword arg.  */
+      gdbpy_ref<> args
+	(Py_BuildValue ("(y#s)", contents.data (),
+			(Py_ssize_t) contents.size (),
+			(type_byte_order (type) == BFD_ENDIAN_BIG
+			 ? "big" : "little")));
+      if (args == nullptr)
+	return nullptr;
+
+      gdbpy_ref<> kwargs (Py_BuildValue ("{sO}", "signed",
+					 type->is_unsigned ()
+					 ? Py_False : Py_True));
+      if (kwargs == nullptr)
+	return nullptr;
+
+      gdbpy_ref<> callable (PyObject_GetAttrString ((PyObject *) &PyLong_Type,
+						    "from_bytes"));
+      if (callable == nullptr)
+	return nullptr;
+
+      result = PyObject_Call (callable.get (), args.get (), kwargs.get ());
+#endif
     }
   catch (const gdb_exception &except)
     {
       return gdbpy_handle_gdb_exception (nullptr, except);
     }
 
-  if (type->is_unsigned ())
-    return gdb_py_object_from_ulongest (l).release ();
-  else
-    return gdb_py_object_from_longest (l).release ();
+  return result;
 }
 
 /* Implements conversion to float.  */
diff --git a/gdb/testsuite/gdb.python/py-value.exp b/gdb/testsuite/gdb.python/py-value.exp
index ab49f2deb92..089bf7563bf 100644
--- a/gdb/testsuite/gdb.python/py-value.exp
+++ b/gdb/testsuite/gdb.python/py-value.exp
@@ -844,3 +844,15 @@ if {[allow_cplus_tests]} {
 	test_subscript_regression "${binfile}-cxx" "c++"
     }
 }
+
+if {[allow_rust_tests]} {
+    gdb_test "set lang rust"
+
+    set cst 0x80000000000000000000000000000000
+    gdb_test "python print(int(gdb.parse_and_eval('${cst}u128')))" \
+	"170141183460469231731687303715884105728" \
+	"convert 128 bit unsigned constant to python int"
+    gdb_test "python print(int(gdb.parse_and_eval('${cst}i128')))" \
+	"-170141183460469231731687303715884105728" \
+	"convert 128 bit signed constant to python int"
+}
-- 
2.49.0

Re: [PATCH] Allow conversion of 128-bit integers to Python

[Simon Marchi]

On 9/5/25 9:29 AM, Tom Tromey wrote:
> Currently, trying to convert a 128-bit integer from a gdb.Value to a
> Python integer will fail.  This is surprising because Python uses
> bigints internally.
> 
> The bug here is that valpy_long uses value_as_long, which fails for
> anything wider than LONGEST.  This patch fixes the problem by using
> the recommended Python API.
> 
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33366
> ---
>  gdb/python/py-value.c                 | 41 +++++++++++++++++++++++----
>  gdb/testsuite/gdb.python/py-value.exp | 12 ++++++++
>  2 files changed, 47 insertions(+), 6 deletions(-)
> 
> diff --git a/gdb/python/py-value.c b/gdb/python/py-value.c
> index 833ce26d5a3..973785b5e4a 100644
> --- a/gdb/python/py-value.c
> +++ b/gdb/python/py-value.c
> @@ -1866,7 +1866,7 @@ valpy_long (PyObject *self)
>  {
>    struct value *value = ((value_object *) self)->value;
>    struct type *type = value->type ();
> -  LONGEST l = 0;
> +  PyObject *result;
>  
>    try
>      {
> @@ -1882,17 +1882,46 @@ valpy_long (PyObject *self)
>  	  && type->code () != TYPE_CODE_PTR)
>  	error (_("Cannot convert value to long."));
>  
> -      l = value_as_long (value);
> +      gdb::array_view<const gdb_byte> contents = value->contents ();
> +#if PY_VERSION_HEX >= 0x030d0000
> +      int flags = (type_byte_order (type) == BFD_ENDIAN_BIG
> +		   ? Py_ASNATIVEBYTES_BIG_ENDIAN
> +		   : Py_ASNATIVEBYTES_LITTLE_ENDIAN);
> +      if (type->is_unsigned ())
> +	flags |= Py_ASNATIVEBYTES_UNSIGNED_BUFFER;
> +      result = PyLong_FromNativeBytes (contents.data (), contents.size (),
> +				       flags);
> +#else
> +      /* We need this roundabout approach because int.from_bytes
> +	 requires "signed" to be a keyword arg.  */
> +      gdbpy_ref<> args
> +	(Py_BuildValue ("(y#s)", contents.data (),
> +			(Py_ssize_t) contents.size (),
> +			(type_byte_order (type) == BFD_ENDIAN_BIG
> +			 ? "big" : "little")));
> +      if (args == nullptr)
> +	return nullptr;
> +
> +      gdbpy_ref<> kwargs (Py_BuildValue ("{sO}", "signed",
> +					 type->is_unsigned ()
> +					 ? Py_False : Py_True));
> +      if (kwargs == nullptr)
> +	return nullptr;
> +
> +      gdbpy_ref<> callable (PyObject_GetAttrString ((PyObject *) &PyLong_Type,
> +						    "from_bytes"));
> +      if (callable == nullptr)
> +	return nullptr;

If we are forced to use kwargs, I think we might as well just use kwargs
for all the args.

Can you add some comments above the Python API calls, just to explain at
a high level what this is doing, so that someone who doesn't know the
Python API by heart can follow what is happening?  Something like:

      /* args = (bytes, byteorder) */
      gdbpy_ref<> args
	(Py_BuildValue ("(y#s)", contents.data (),
			(Py_ssize_t) contents.size (),
			(type_byte_order (type) == BFD_ENDIAN_BIG
			 ? "big" : "little")));
      if (args == nullptr)
	return nullptr;

      /* kwargs = {"signed": signed} */
      gdbpy_ref<> kwargs (Py_BuildValue ("{sO}", "signed",
					 type->is_unsigned ()
					 ? Py_False : Py_True));
      if (kwargs == nullptr)
	return nullptr;

      /* Get `int.from_bytes`.  */
      gdbpy_ref<> callable (PyObject_GetAttrString ((PyObject *) &PyLong_Type,
						    "from_bytes"));
      if (callable == nullptr)
	return nullptr;

      /* Call `int.from_byte(*args, **kwargs)`.  */
      result = PyObject_Call (callable.get (), args.get (), kwargs.get ());

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Simon

Re: [PATCH] Allow conversion of 128-bit integers to Python

[Tom Tromey]

Simon> If we are forced to use kwargs, I think we might as well just use kwargs
Simon> for all the args.

I don't see that this provides a benefit, but I went ahead and did it
anyway.  Note that PyObject_Call requires a tuple argument, so we end up
creating an empty one.

Simon> Can you add some comments above the Python API calls, just to explain at
Simon> a high level what this is doing, so that someone who doesn't know the
Simon> Python API by heart can follow what is happening?

I did this.  I'll check it in shortly.

Tom

Re: [PATCH] Allow conversion of 128-bit integers to Python

[Simon Marchi]

On 9/5/25 1:26 PM, Tom Tromey wrote:
> Simon> If we are forced to use kwargs, I think we might as well just use kwargs
> Simon> for all the args.
> 
> I don't see that this provides a benefit, but I went ahead and did it
> anyway.  Note that PyObject_Call requires a tuple argument, so we end up
> creating an empty one.
> 
> Simon> Can you add some comments above the Python API calls, just to explain at
> Simon> a high level what this is doing, so that someone who doesn't know the
> Simon> Python API by heart can follow what is happening?
> 
> I did this.  I'll check it in shortly.
> 
> Tom

I thought that we could avoid creating the tuple.  If we can't then
it doesn't matter much.  Although the kwargs has the advantage that the
arguments are named, so it's perhaps a bit more readable.

Simon

Re: [PATCH] Allow conversion of 128-bit integers to Python

[Paul Koning]

> On Sep 5, 2025, at 1:51 PM, Simon Marchi <simark@simark.ca> wrote:
> 
> On 9/5/25 1:26 PM, Tom Tromey wrote:
>> Simon> If we are forced to use kwargs, I think we might as well just use kwargs
>> Simon> for all the args.
>> 
>> I don't see that this provides a benefit, but I went ahead and did it
>> anyway.  Note that PyObject_Call requires a tuple argument, so we end up
>> creating an empty one.
>> 
>> Simon> Can you add some comments above the Python API calls, just to explain at
>> Simon> a high level what this is doing, so that someone who doesn't know the
>> Simon> Python API by heart can follow what is happening?
>> 
>> I did this.  I'll check it in shortly.
>> 
>> Tom
> 
> I thought that we could avoid creating the tuple.  If we can't then
> it doesn't matter much.  Although the kwargs has the advantage that the
> arguments are named, so it's perhaps a bit more readable.
> 
> Simon

One would expect an empty tuple to be a predefined object available for anyone who needs one.

	paul

Re: [PATCH] Allow conversion of 128-bit integers to Python

[Tom Tromey]

Paul> One would expect an empty tuple to be a predefined object
Paul> available for anyone who needs one.

I'm not aware of one but presumably allocating a zero-length tuple would
just reuse it if it did exist.

Tom