diff options
author | Andrew Burgess <aburgess@redhat.com> | 2024-08-06 20:53:35 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2024-08-14 09:52:35 +0100 |
commit | a4c88987f0795d9fd0a2bafc3d5ee1484b5d168b (patch) | |
tree | 011efa81801ca7e71f10ba32a432bd2df8ff316e /gdb | |
parent | ca25db0641f0fed03a55fa918feec4977d88a973 (diff) | |
download | gdb-a4c88987f0795d9fd0a2bafc3d5ee1484b5d168b.zip gdb-a4c88987f0795d9fd0a2bafc3d5ee1484b5d168b.tar.gz gdb-a4c88987f0795d9fd0a2bafc3d5ee1484b5d168b.tar.bz2 |
gdb: remove unnecessary code relating to limited-length arrays
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>
Diffstat (limited to 'gdb')
-rw-r--r-- | gdb/value.c | 16 |
1 files changed, 1 insertions, 15 deletions
diff --git a/gdb/value.c b/gdb/value.c index 78ace05..d9b3c6e 100644 --- a/gdb/value.c +++ b/gdb/value.c @@ -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; |