Re: [RFC] gdb: introduce limited array lengths while printing values

["Maciej W. Rozycki" <macro@embecosm.com>]

Hi Tom,

 It looks like it comes at almost an anniversary.

On Fri, 14 Jan 2022, Tom Tromey wrote:

> >>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:
> 
> Andrew> This commit introduces the idea of loading only part of an array in
> Andrew> order to print it, what I call "limited length" arrays.
> 
> Andrew> The motivation behind this work is to make it possible to print slices
> Andrew> of very large arrays, where very large means bigger than
> Andrew> max-value-size.
> 
> Seems reasonable.  My first thought was why doesn't the user just bump
> up max-value-size, but I suppose one can always find an even bigger
> array.

 My understanding of the motivation for this feature has been this is for 
data objects so large as to put a serious strain on the resources of the 
debugger if retrieved whole, so just bumping up `max-value-size' would be 
defeating the purpose the setting is there in the first place.

> Andrew>   (gdb) p $1
> Andrew>   $2 = <unavailable>
> 
> Andrew> This patch is currently RFC, I would like to hear what people think
> Andrew> about both the idea in general, and the approach taken.
> 
> I think this detail is the crucial point.
> 
> Andrew> One question I have is whether the value history problem would be
> Andrew> better addressed in a different way, for example, we could just drop
> Andrew> the '$1 = ' for values that are not being added into the history, so
> Andrew> things would look like:
> 
> Andrew>   (gdb) p -elements 10 -- large_1d_array
> Andrew>   {0, 1, 2, 3, 4, 5, 6, 7, 8, 9...}
> 
> Andrew> which might be a better solution.
> 
> I'm not a fan of this one.  It seems overly subtle to me.
> 
> Andrew> Another possibility would be to tag
> Andrew> the "unavailable" value with a reason field so we could do something
> Andrew> like:
> 
> Andrew>   (gdb) p $1
> Andrew>   $2 = <unavailable: original value was too large>
> 
> Andrew> which is slightly more informative, but clearly is a more invasive
> Andrew> change to the value structure.
> 
> How much more invasive?
> 
> Also, it seems to me that if the new print request would show elements
> that do exist, then the <unavailable> could be avoided.  That is, if the
> number requested from history is less than or equal to what was done
> before, just satisfy the request.
> 
> Andrew> But I think Tom was looking into having the value optimized out checks
> Andrew> not actually load the value in at one point, so maybe, if that change
> Andrew> landed, then we could investigate the possibility of having the array
> Andrew> printing code only load the elements from the target one at a
> Andrew> time (with the dcache providing some optimisation), which might avoid
> Andrew> the need to perform the current partial load?
> 
> This did land:
> 
>     commit a519e8ffe2b0f008deaef1517562090d9eaadccc
>     Author: Tom Tromey <tromey@adacore.com>
>     Date:   Fri Sep 10 12:40:54 2021 -0600
> 
>         Add lval_funcs::is_optimized_out
> 
> Andrew> Anyway, I'd be interested to hear people's thoughts; is this a
> Andrew> valuable change?  Which approach seems like the right way to go?
> 
> I think it makes sense to allow something here.
> 
> Another possibility is that when printing a length-limited array, just
> make a new array type with the requested bounds.  Then it will fit
> automatically and work "properly" in history.  The downside is this may
> be confusing to users.  On the whole I think I'd prefer some kind of
> unavailability message when a request can't be satisfied.  Though
> perhaps one way to do this would be to make an array type, but also mark
> the value as "this has a synthetic type", so that the value code can
> know when to emit the message.

 I have come up with yet another approach, which will hopefully make 
everyone happy.  For limited-length requests data up to `max-value-size' 
is retrieved and stored in the history regardless of how much less has 
been requested with the relevant `print' command.

 If history is later accessed, then elements beyond the `max-value-size' 
limit at the time the entry was created are shown as <unavailable>, while 
these within are returned normally whether for printing or for expression 
evaluation.  I think this is consistent and what one might expect.

 This required some preparatory changes to how history is handled to avoid 
surprising effects, so I have turned Andrew's original change into a small 
patch series.  Submitted shortly as v2 and not an RFC anymore.

 Thank you for your review.

  Maciej