From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id /OWFOZirzF/RcQAAWB0awg (envelope-from ) for ; Sun, 06 Dec 2020 04:59:52 -0500 Received: by simark.ca (Postfix, from userid 112) id D687D1F0B8; Sun, 6 Dec 2020 04:59:52 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 611381E58E for ; Sun, 6 Dec 2020 04:59:51 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 63032388E819; Sun, 6 Dec 2020 09:59:50 +0000 (GMT) Received: from rock.gnat.com (rock.gnat.com [205.232.38.15]) by sourceware.org (Postfix) with ESMTP id E35093854810 for ; Sun, 6 Dec 2020 09:59:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E35093854810 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=brobecker@adacore.com Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id B80B656203; Sun, 6 Dec 2020 04:59:45 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at gnat.com Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id L4-+E+T5Hpc0; Sun, 6 Dec 2020 04:59:45 -0500 (EST) Received: from float.home (localhost.localdomain [127.0.0.1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPS id 59EDB56200; Sun, 6 Dec 2020 04:59:45 -0500 (EST) Received: by float.home (Postfix, from userid 1000) id E560BA1880; Sun, 6 Dec 2020 13:59:39 +0400 (+04) Date: Sun, 6 Dec 2020 13:59:39 +0400 From: Joel Brobecker To: Andrew Burgess Subject: Re: [PATCH] gdb: user variables with components of dynamic type Message-ID: <20201206095939.GA343140@adacore.com> References: <20201022153238.1947197-1-andrew.burgess@embecosm.com> <20201106230422.GK2729@embecosm.com> <20201108105059.GC451505@adacore.com> <20201112160018.GR2729@embecosm.com> <20201115140759.GA498820@adacore.com> <20201203110434.GD2729@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201203110434.GD2729@embecosm.com> 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: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Hi Andrew, > Sorry for the length of time it has taken me to get back to you. > Initially I was just chewing over your feedback, then I got > sidetracked..... > > I have a question about what you wrote, see inline below. > > > I would not like to change Fortran from displaying dynamnic types as > > > their actual value (and instead just display a pointer) as that seems > > > like a really bad change just to work around a limitation with > > > internal variables. > > > > 100% agreed. > > That's good, and not really surprising as from what you wrote I think > this is what Ada does, but then later on you write... > > > > > > What I think is super interesting is how this all interacts with > > > pretty-printers. So, if I start with this test program: > > > > Interesting indeed. > > > > > I wonder if this problem should just be solved (at least in the > > > short/medium term) by improving the documentation for internal > > > variables? > > > > For me, if I had to summarize my current thinking thanks to our > > discussions so far, I would say: > > > > (a) The case of fields whose type is dynamic is really very > > similar to the case of references. > > > > (b) Since we handle references the same as pointers, I think > > it's fine as a first instance to fix our immediate issue, > > which is the internal error, by providing the exact same > > kind of behavior for those dynamic fields as we provide > > for references. > > ...this. > > Aren't you here arguing that we should immediately fix this issue by > changing the way dynamic types are printed such that they are handled > more like C++ references (i.e. print the address rather than the > contents). Which seems to be the complete opposite of your opinion > above. It does like a contradiction indeed. I must have had a brainfarting moment when I wrote that -- very sorry! > I'm curious, if Ada makes use of dynamic typing then what does GDB > print when an object of dynamic type is nested within some other > object? Ada resolves the dynamic object, and presents the actual type. Reference layers are also silently peeled (we may need to rediscuss the "silently" part, but that would be a separate discussion). I don't have a full map of the various possibilities, but it's not unusual for the "variable" part of an object to be replaced by a reference. It's not always replaced by a reference, though. > What happens if the parent object is assigned to a user variable? Tom was recently asked about something like that, when one of our developers had a situation where the value of something stored in $1 was changing over time, and was surprised by that. Only the contents of the value that's "directly accessible" to re-use Tom's words, are captured. The printing of an object in Ada can involve some silent dereferencing and the de-referenced data is not captured. So re-printing a captured value can yield a different answer. > I guess given your concerns then the idea solution here would be one > that somehow allows GDB to capture all of the dynamic content at the > time the user variable is created. I'll try to figure out if there's > any good ways to achieve this. That would definitely be ideal, absolutely. But it does sound like a significant undertaking. Just thinking of the simple case of a record with one field being a reference. How do go from capturing a buffer with the contents of the record, to a case where we have to have part of that buffer be treated specially so as to know that the data targetted by the corresponding field is not obtained by dereferencing the pointer, but by reading something elsewhere. So, for me, what this discussion has helped me with is that perhaps the best compromise is to do what's right when printing the value of an expression, and then accept that the value capturing method has a limitation that references are captured as pointers, and that therefore that the captured data is not entirely complete and may change while the inferior runs further. Or said differently, if I remember what your patch is trying to do, you've helped me come to the same conclusion as the one you reached back when you proposed the patch. > > (c) Finding a way to make this clearer for users would be a nice > > enhancement, but this would be a general enhancement, not > > something required in the context of your patch. > > > > So you and I are converging towards the same solution in the code, > > and I agree that a documentation update might be useful as well. > > > > Going back to your original patch, I would need more research > > than what I have time for to determine whether I'd fix it > > the same way you did at the location you did. After much staring > > with the entire function's implementation as a context, the patch > > does make sense to me, especially if I ignore a bit the asserts > > for a minute. Hopefully others with a more complete knowledge of > > the area of value-saving for the value history can chime in. > > > > I wish I could be more help! :-/ > > > > -- > > Joel > > > > [1] I know your situation has to do with dynamic types rather than > > references, but I think both cases are in the same boat and could > > be treated the same. -- Joel