From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by sourceware.org (Postfix) with ESMTPS id 47FEB3858D35 for ; Thu, 12 Jan 2023 09:00:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 47FEB3858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com Received: by mail-lf1-x135.google.com with SMTP id d30so22564040lfv.8 for ; Thu, 12 Jan 2023 01:00:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=mime-version:user-agent:references:message-id:in-reply-to:subject :cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=zD9C8kEFi816lXjVvy4e6dqLD/x7kmh4pO5s+a5UjRs=; b=hFqWWmYj6bp5Qnv4fpkaP4HrxogX5MtrHV/c33YgGJCMXXDh76gVAnlkegFCN06k0i g86BJ4dVLGUUH3at6zcD72DgKaM6zH+9IjssXrYntig6Ejk1DZ+v4YCmLiRksG1lVh8U /OlsZeZxBG1bKVPt60Mq3sTI0PzE9FEN069D2YaPZk5fCBY/T1n7d64upenxIMWfXd25 uEAdP6ho25UXHbizl6QcUiWWXe2taoQRaxTXbKST4QdvWKrqTh2XfSGPJyyTXmii1Edi R3f2+coqr0KNkHl722pNSxhu9IEYPLrRGdqyuVFXrztPubFWJ85jSBeLNRDw9LvLhk9h KKWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:references:message-id:in-reply-to:subject :cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zD9C8kEFi816lXjVvy4e6dqLD/x7kmh4pO5s+a5UjRs=; b=ArGxcRzLrxEVDddcDvANlaRon7uLubw8C/IZnKZdfBM5eA9Nr6uKPz/B7D7dYff6Yf 0Vl0bUdzJk0RxUkyJMCADxDFv8/Livb4a2bpORUeMJSIrCtHi9lBIpMOM8LnLJSsd0W3 4hE6mkSsOHP2V/0HGCQlmBcdin+UbKgXPQmZDZ77oQc58ng62LD59MwKMHpeB2q9qF5B RhrE3dVndJHuQLEVOxzmhxY81Yyy53tIzz1LYjPo0u3PnFKVrFagdhvSaDmVSH/SwYJQ 4SpyIXuZ1JtmXcHNiHON9yKBhxx1OjBrP/vhGuBq6XhpStepDdsoovOMHymfPshM/p02 2w0Q== X-Gm-Message-State: AFqh2kojowlNGo6wZ11dU8ZnYlKxU26Q5OIhev9DxAS4aoSgQXxYI402 DV0vUwCZiVCS9sytqhfpOL6k5A== X-Google-Smtp-Source: AMrXdXtSrIi/Am9GgRavYYicyrUFscXdq28FbC7aGJwSfQ0UfXED9x46TWdV5jBbBpPQir1UXi5G9w== X-Received: by 2002:ac2:598f:0:b0:4cb:df5:92a6 with SMTP id w15-20020ac2598f000000b004cb0df592a6mr3269965lfn.30.1673514034394; Thu, 12 Jan 2023 01:00:34 -0800 (PST) Received: from [192.168.219.3] ([78.8.192.131]) by smtp.gmail.com with ESMTPSA id a6-20020a056512200600b004caf6f0b08csm3156245lfb.107.2023.01.12.01.00.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2023 01:00:33 -0800 (PST) Date: Thu, 12 Jan 2023 09:00:30 +0000 (GMT) From: "Maciej W. Rozycki" To: Tom Tromey cc: Andrew Burgess , gdb-patches@sourceware.org Subject: Re: [RFC] gdb: introduce limited array lengths while printing values In-Reply-To: <87ee5agqik.fsf@tromey.com> Message-ID: References: <20211006172902.2691582-1-andrew.burgess@embecosm.com> <87ee5agqik.fsf@tromey.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Tom, It looks like it comes at almost an anniversary. On Fri, 14 Jan 2022, Tom Tromey wrote: > >>>>> "Andrew" == Andrew Burgess 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 = > > 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 = > > 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 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 > 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 , 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