Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: Tom Tromey <tromey@adacore.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Rewrite gdb_mpz::export_bits
Date: Thu, 10 Sep 2026 16:41:16 +0200	[thread overview]
Message-ID: <af0f18d6-f0a4-4539-a1fb-265a63d07e51@suse.de> (raw)
In-Reply-To: <20260909180822.2255847-1-tromey@adacore.com>

On 9/9/26 8:08 PM, Tom Tromey wrote:

Hi Tom,

thanks for fixing this.

This LGTM.  I have some comments below, but these are all nits, so feel 
free to ignore.

Approved-By: Tom de Vries <tdevries@suse.de>

> A couple of bugs point out that, when multiplication overflows, gdb
> does not compute the correct result. 
> This is caused by some bugs in
> gdb_mpz::export_bits. 

There's more than one bug?  If not, then maybe use "a bug".

> This patch rewrites part of this function,
> hopefully now getting the correct answer.  I think the new code should
> be somewhat simpler to follow.
> 

Agreed, it is simpler.

> A new selftest is added, derived from the code in the bug report.
> 
> This rewrite doesn't try to minimize allocations, the way the previous
> one did.  I tend to doubt that matters, and this is one of the
> readability improvements IMO.
> 

Agreed.

I was not familiar with this code, so I ended up splitting the patch in 
three:
- drop allocation minimization
- fix
- rename exported_val to masked
to get a more minimal fix to look at.

<bikeshedding>  I could live without the third patch, or a more neutral 
name like res or tmp.  Another approach could be to use meaningful names 
like masked, but then do something like:
...
-      masked += neg_offset;
-    }
+      un_signed = masked + neg_offset
+    } else {
+      un_signed = masked;
+    }
...
If so, I prefer "truncated" to "masked".  </bikeshedding>

> Regression tested on x86-64 Fedora 43.
> 
> I am not sure but it might be worth applying this to gdb 18; your
> thoughts appreciated.
> 

I think it's worth it.  As mentioned, I'm not familiar with this code, 
so I can't asses the risk.

> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34601
> ---
>   gdb/gmp-utils.c                     | 38 ++++++++++-------------------
>   gdb/unittests/gmp-utils-selftests.c |  6 +++++
>   2 files changed, 19 insertions(+), 25 deletions(-)
> 
> diff --git a/gdb/gmp-utils.c b/gdb/gmp-utils.c
> index b7fed9a82d1..949d75d21bd 100644
> --- a/gdb/gmp-utils.c
> +++ b/gdb/gmp-utils.c
> @@ -128,35 +128,22 @@ gdb_mpz::export_bits (gdb::array_view<gdb_byte> buf, int endian, bool unsigned_p
>   	       hi.str ().c_str ());
>       }
>   
> -  const gdb_mpz *exported_val = this;
> -  gdb_mpz un_signed;
> -  if (sign < 0)
> +  gdb_mpz masked = *this;
> +  masked.mask (buf.size () * HOST_CHAR_BIT);
> +
> +  if (sign < 0 && masked.sgn () != 0)

I think it's clearer to do this, because there's less state to keep 
going forward:
...
   if (masked.sgn () == 0)
     {
       memset (buf.data (), 0, buf.size ());
       return;
     }

   if (sign < 0)
...

This starts to get verbose, but after factoring out some lambda functions:
...
+  auto export_zero = [&] ()
+  {
+    memset (buf.data (), 0, buf.size ());
+  };
+
+  auto export_if_zero = [&] (gdb_mpz &val)
+  {
+    if (val.sgn () != 0)
+      return false;
+
+    export_zero ();
+    return true;
+  };
...
this is reduced from 5 to 2 lines:
...
   if (export_if_zero (masked))
     return;

   if (sign < 0)
...

Thanks,
- Tom

>       {
>         /* mpz_export does not handle signed values, so create a positive
>   	 value whose bit representation as an unsigned of the same length
> -	 would be the same as our negative value.  */
> +	 would be the same as our negative value.  However, if masking
> +	 left us with 0, we don't need to do anything else.  */
>         gdb_mpz neg_offset = gdb_mpz::pow (2, buf.size () * HOST_CHAR_BIT);
> -      un_signed = *exported_val + neg_offset;
> -      exported_val = &un_signed;
> -    }
> -
> -  /* If the value is too large, truncate it.  */
> -  if (!safe
> -      && mpz_sizeinbase (exported_val->m_val, 2) > buf.size () * HOST_CHAR_BIT)
> -    {
> -      /* If we don't already have a copy, make it now.  */
> -      if (exported_val != &un_signed)
> -	{
> -	  un_signed = *exported_val;
> -	  exported_val = &un_signed;
> -	}
> -
> -      un_signed.mask (buf.size () * HOST_CHAR_BIT);
> +      masked += neg_offset;
>       }
>   
> -  /* It's possible that one of the above results in zero, which has to
> -     be handled specially.  */
> -  if (exported_val->sgn () == 0)
> +  /* It's possible that the above results in zero, which has to be
> +     handled specially.  */
> +  if (masked.sgn () == 0)
>       {
>         memset (buf.data (), 0, buf.size ());
>         return;
> @@ -174,8 +161,9 @@ gdb_mpz::export_bits (gdb::array_view<gdb_byte> buf, int endian, bool unsigned_p
>   
>     size_t word_countp;
>     gdb::unique_xmalloc_ptr<void> exported
> -    (mpz_export (NULL, &word_countp, -1 /* order */, buf.size () /* size */,
> -		 endian, 0 /* nails */, exported_val->m_val));
> +    (mpz_export (nullptr, &word_countp, -1 /* order */,
> +		 buf.size () /* size */, endian, 0 /* nails */,
> +		 masked.m_val));
>   
>     gdb_assert (word_countp == 1);
>   
> diff --git a/gdb/unittests/gmp-utils-selftests.c b/gdb/unittests/gmp-utils-selftests.c
> index 1912d346c17..417abae5463 100644
> --- a/gdb/unittests/gmp-utils-selftests.c
> +++ b/gdb/unittests/gmp-utils-selftests.c
> @@ -80,6 +80,12 @@ gdb_mpz_as_integer ()
>     v -= 1;
>   
>     SELF_CHECK (v.as_integer<ULONGEST> () == ul_expected);
> +
> +  /* This is from PR gdb/34601.  */
> +  LONGEST neg = (LONGEST) 0x8000000000000001ull;
> +  gdb_mpz a (neg);
> +  gdb_mpz b (0x1234);
> +  SELF_CHECK ((a * b).as_integer_truncate<int64_t> () == 0x1234);
>   }
>   
>   /* A helper function which calls the given gdb_mpz object's as_integer
> 
> base-commit: 2ece447a4f3dcf1d96bcaca644dbf895e42194b8


  reply	other threads:[~2026-09-10 14:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-09 18:08 Tom Tromey
2026-09-10 14:41 ` Tom de Vries [this message]
2026-09-10 19:01   ` Tom Tromey
2026-09-11 21:32     ` Tom de Vries
2026-09-14 17:43       ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=af0f18d6-f0a4-4539-a1fb-265a63d07e51@suse.de \
    --to=tdevries@suse.de \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@adacore.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox