]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commitdiff
gdb: remove unnecessary code relating to limited-length arrays
authorAndrew Burgess <aburgess@redhat.com>
Tue, 6 Aug 2024 19:53:35 +0000 (20:53 +0100)
committerAndrew Burgess <aburgess@redhat.com>
Wed, 14 Aug 2024 08:52:35 +0000 (09:52 +0100)
While reviewing this commit:

  commit 8fdd2b2bcd8117cafcc6ef976e45f0d9f95fb528
  Date:   Tue Aug 6 19:34:18 2024 +0200

      Mark unavailable bytes of limited-length arrays when allocating contents

I spotted that there was some code in value::record_latest relating to
limited-length arrays which appeared redundant.  The code was added
with the first introduction on limited-length arrays in commit:

  commit a0c07915778486a950952139d27c01d4285b02b4
  Date:   Fri Feb 10 23:49:19 2023 +0000

      GDB: Introduce limited array lengths while printing values

The code in question is in value::record_latest.  When the value being
recorded is lazy we need to fetch its value before adding it to the
history list.  The code I spotted checks to see if the value is lazy,
if we currently have array limiting in effect, and if we do sets
m_limited_length to max_value_size before finally calling fetch_lazy.

The first thing fetch_lazy does is call allocate_contents to setup the
value's buffer, and in allocate_contents we perform the same set of
checks: if the value is an array, and array length limiting is in
effect then only allocate max_value_size buffer for the contents.

In ::allocate_contents the `if` condition check is spread out between
::allocate_contents and ::set_limited_array_length, but I'm certain
it's checking the same condition.

As such the checks and m_limited_length adjustment in ::record_latest
is redundant and can be removed.

Out of curiosity I went back to the original a0c07915778486a commit
and removed the same block of code from record_latest_value (as
value::record_latest was called back then) and non of the tests added
by commit a0c07915778486a failed.  I think this block of code was
never needed.

Anyway, I removed the unnecessary code and retested and there are no
regressions.

There should be no user visible changes after this commit.

Approved-By: John Baldwin <jhb@FreeBSD.org>
gdb/value.c

index 78ace05b4ba60135cf387d64136fb6dcb6a2be8c..d9b3c6ece04c6d0961ef18ab9de24365d10fa22b 100644 (file)
@@ -1700,21 +1700,7 @@ value::record_latest ()
      the value was taken, and fast watchpoints should be able to assume that
      a value on the value history never changes.  */
   if (lazy ())
-    {
-      /* We know that this is a _huge_ array, any attempt to fetch this
-        is going to cause GDB to throw an error.  However, to allow
-        the array to still be displayed we fetch its contents up to
-        `max_value_size' and mark anything beyond "unavailable" in
-        the history.  */
-      if (m_type->code () == TYPE_CODE_ARRAY
-         && m_type->length () > max_value_size
-         && array_length_limiting_element_count.has_value ()
-         && m_enclosing_type == m_type
-         && calculate_limited_array_length (m_type) <= max_value_size)
-       m_limited_length = max_value_size;
-
-      fetch_lazy ();
-    }
+    fetch_lazy ();
 
   /* Mark the value as recorded in the history for the availability check.  */
   m_in_history = true;