From a4c88987f0795d9fd0a2bafc3d5ee1484b5d168b Mon Sep 17 00:00:00 2001 From: Andrew Burgess Date: Tue, 6 Aug 2024 20:53:35 +0100 Subject: 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 --- gdb/value.c | 16 +--------------- 1 file changed, 1 insertion(+), 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; -- cgit v1.1