public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Andrew Burgess <andrew.burgess@embecosm.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] gdb: introduce limited array lengths while printing values
Date: Fri, 14 Jan 2022 10:45:39 -0700	[thread overview]
Message-ID: <87ee5agqik.fsf@tromey.com> (raw)
In-Reply-To: <20211006172902.2691582-1-andrew.burgess@embecosm.com> (Andrew Burgess's message of "Wed, 6 Oct 2021 18:29:02 +0100")

>>>>> "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.

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.

Tom

  parent reply	other threads:[~2022-01-14 17:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-06 17:29 Andrew Burgess
2021-10-06 17:36 ` Eli Zaretskii
2021-11-02 10:03 ` [PING][RFC] " Maciej W. Rozycki
2021-11-09 16:44 ` [PING^2][RFC] " Maciej W. Rozycki
2021-11-16 12:40 ` [PING^3][RFC] " Maciej W. Rozycki
2021-11-23 21:37 ` [PING^4][RFC] " Maciej W. Rozycki
2021-11-30 13:14 ` [PING^5][RFC] " Maciej W. Rozycki
2021-12-08 23:19 ` [PING^6][RFC] " Maciej W. Rozycki
2021-12-15 17:14 ` [PING^7][RFC] " Maciej W. Rozycki
2022-01-04 17:50 ` [PING^8][RFC] " Maciej W. Rozycki
2022-01-12 18:17 ` [PING^9][RFC] " Maciej W. Rozycki
2022-01-14 17:45 ` Tom Tromey [this message]
2023-01-12  9:00   ` [RFC] " Maciej W. Rozycki

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=87ee5agqik.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=andrew.burgess@embecosm.com \
    --cc=gdb-patches@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).