From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by sourceware.org (Postfix) with ESMTPS id 533043858D35 for ; Fri, 14 Jan 2022 17:45:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 533043858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com Received: from cmgw15.mail.unifiedlayer.com (unknown [10.0.90.130]) by progateway4.mail.pro1.eigbox.com (Postfix) with ESMTP id BE111100477AA for ; Fri, 14 Jan 2022 17:45:40 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id 8QdwnCPFxikTn8QdwnnrZU; Fri, 14 Jan 2022 17:45:40 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=CeHNWJnl c=1 sm=1 tr=0 ts=61e1b6c4 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=DghFqjY3_ZEA:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=13KGAo4DAAAA:8 a=A8oJy8mYAAAA:8 a=7z3do4ldlYgDzllBJNIA:9 a=DdAeqqNASC6T8jxox_Jq:22 a=MasS0_dV9q-jaWZIey9J:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=8x+VTFxEoQpkHIL4XqewQaNdcVRrjrQOFv5q5NZbN7A=; b=QshscZ5l/Z7/LKUQ6zg87X7aNO OdP1Kvx9W0a7AezMPfAe6PNqsoCWNUqLhgBsmWXyiLSM6ACcH5AA/H5SRmPp9uPMPE/q2oOStaBHK sPHlaVwOX4DhSNCm3Tqu0+60n; Received: from 75-166-134-30.hlrn.qwest.net ([75.166.134.30]:55886 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1n8Qdv-002ByD-Se; Fri, 14 Jan 2022 10:45:39 -0700 From: Tom Tromey To: Andrew Burgess Cc: gdb-patches@sourceware.org Subject: Re: [RFC] gdb: introduce limited array lengths while printing values References: <20211006172902.2691582-1-andrew.burgess@embecosm.com> X-Attribution: Tom Date: Fri, 14 Jan 2022 10:45:39 -0700 In-Reply-To: <20211006172902.2691582-1-andrew.burgess@embecosm.com> (Andrew Burgess's message of "Wed, 6 Oct 2021 18:29:02 +0100") Message-ID: <87ee5agqik.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 75.166.134.30 X-Source-L: No X-Exim-ID: 1n8Qdv-002ByD-Se X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 75-166-134-30.hlrn.qwest.net (murgatroyd) [75.166.134.30]:55886 X-Source-Auth: tom+tromey.com X-Email-Count: 6 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3025.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2022 17:45:42 -0000 >>>>> "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. 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. Tom