From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) by sourceware.org (Postfix) with ESMTPS id 71DA8396EC91 for ; Thu, 3 Dec 2020 11:04:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 71DA8396EC91 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wr1-x442.google.com with SMTP id g14so1405658wrm.13 for ; Thu, 03 Dec 2020 03:04:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=6f+v4LeTVS1uM2TUjIm4Qxn81ttqXPTx5KMCtTLvOVw=; b=JEKN+jum3mS8n5Lu9rVKo3SfjlSRhKSKOxE/cBAskjHWzLMFdgafbPG8zp6sjrjN0i XVTbVO26FtnqQtsWTpq5WjvYZ5QAA7tlGNXMhpsZJD9yZctzaeX7rL4sxTANPa1RjKvF xCLUAq1WdR3vS9x5zs0avTboATrLu8UL9DPaKxsaqx8a0XRLmOC1WPM2NNn+sN1KCtug 2gOGnO4XfcPwJ9a2GfJxkPLSB6XE2MVO7vHrmIXh0rqNKjqJVw+Crzghl3KXbiVl0FIq I0cDfMb+/JvD7/1pz58HGqK06PdIc4wryiunq7A3XRIu1WEOGw5b8KlfwuuLZqL/ffVR bZSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=6f+v4LeTVS1uM2TUjIm4Qxn81ttqXPTx5KMCtTLvOVw=; b=MUIkT81sSEKfwFWJv5UPwQol105/HN35D7mWSg08ABGK7PT4DD2xSRfLOoot6nBC+B Jtzb5Up7EpVV9xO9Yh4rPzdWo3+GEtF8ACsD/dP5czEL4g1KvYKXJPmYj3d5UuhhDA6B XtFteggYWZuK0YJ5GdEmwYu3nO66khe/byyv8pApWq9S7qP6G8pYAgC16VqfXCsxirEc iXWt0YoAXDelf8MD6Mgaeu07erla2G+eAQjhM34ubfW0295po0lSE52/dSEZY8BgOR1Y zu1onNb1FVMzEMAwk7O3AuXvt3ZX6BU9nvAXMMHJqt2kn8QTSONUgfaFvuJnI/dlqgtc 08tQ== X-Gm-Message-State: AOAM530wA4AAc03yTbfGMD4M/yemlz+EkKQKVIZXlsB5e7K2F57whpZW g7Z61wNzGJlYBS1WKpvoV0zS6NfDIbnlTg== X-Google-Smtp-Source: ABdhPJye6QgT2nBZloB5IJ76wvVbkqjjxMjH8xtfY5TL/BcrS8HfmGB74SlBX9leF77H/2+eH0FLmQ== X-Received: by 2002:adf:e387:: with SMTP id e7mr2931666wrm.177.1606993476432; Thu, 03 Dec 2020 03:04:36 -0800 (PST) Received: from localhost (host109-154-20-215.range109-154.btcentralplus.com. [109.154.20.215]) by smtp.gmail.com with ESMTPSA id v20sm979348wml.34.2020.12.03.03.04.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Dec 2020 03:04:35 -0800 (PST) Date: Thu, 3 Dec 2020 11:04:34 +0000 From: Andrew Burgess To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] gdb: user variables with components of dynamic type Message-ID: <20201203110434.GD2729@embecosm.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201115140759.GA498820@adacore.com> X-Operating-System: Linux/5.8.13-100.fc31.x86_64 (x86_64) X-Uptime: 10:56:02 up 39 days, 1:59, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-5.4 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Thu, 03 Dec 2020 11:04:39 -0000 Hi Joel, 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. * Joel Brobecker [2020-11-15 18:07:59 +0400]: > Hi Andrew, > > > So your third choice was the winner, the array has dynamic type and > > includes a computed data location. > > Thanks for providing the additional details. > > > The problem in terms of implementation is that really everything is > > either a real inline value, or a pointer. All the other words are > > just language sugar on top of these two choices. > > Agreed. > > > When we look at C++ references (basically pointers + automatic > > dereferencing), > > Thanks for sharing the experiment. This was actually a good refresher > for me. > > > So we get the behaviour we might expect, the pointer value underlying > > the reference is preserved, but the value pointed too is not. > > Yeah. What I took away from this experiment is that I think > the syntax in printing the value gives some clues as to why > some of the underlying value is not captured by the value history > mechanism. Whether this is enough or not will likely depend on > the level of the user, but I tend to think that a reasonably sharp > user seeing @: can infer that the value printed > from it is the current value at the address shown. So good enough > for me. > > > > It's possible that the compromise you suggest (treat dynamic components > > > the same as pointers) might be the most reasonable way out, but I think > > > it'll invite confusion on the users' side, and probably bug reports. > > > At the very least, I think we should warn users when we do this, so > > > as to be sure to set expectations right, on the spot. > > > > Adding a warning would be reasonably simple, we can start with (in > > value.c:set_internalvar): > > > > if (is_dynamic_type (value_type (new_data.value))) > > warning ("some warning text here..."); > > > > There's two problems, the first is easy enough to solve: if the top > > level value being captured is dynamic, then we do capture the _actual_ > > value, it's only when a sub-component is dynamic that we have > > problems. The above check will trigger if only the top-level value is > > dynamic, so it warns in too many places. > > > > As a concrete example, given this Fortran type: > > > > type :: some_type > > integer, allocatable :: array_one (:,:) > > integer :: a_field > > integer, allocatable :: array_two (:,:) > > end type some_type > > > > type(some_type) :: some_var > > > > Then in GDB: > > > > (gdb) set $foo = some_var > > > > We capture the contents of the some_type struct, including the > > pointers to the dynamic objects array_one and array_two. But if > > instead we do: > > > > (gdb) set $bar = some_var%array_one > > > > Now we capture the full contents of array_one, there's no further > > dynamic type resolution required. Changing 'some_var%array_one' will > > not change the value of $bar, but the change would be see in $foo. > > > > The harder problem is, what warning do we print?? I initially went > > with: > > > > components of dynamically typed values are not currently captured within internal variables > > > > despite being a bit long, it's not immediately clear if a user will > > know what 'dynamically typed values' means? Maybe we end up needing a > > language specific warning, so for Fortran: > > > > the values of allocatable fields are not currently captured within internal variables > > > > thoughts or suggestions are welcome... > > I admit I'm having minor headaches trying to wrap my head around > the various scenarios and how we would want to deal with the situation. > > For instance, do we auto-dereference [1] the same way for all languages? > For Ada, for instance, I think we always auto-derefrence, regardless > if the data we're printing is top-level or whether it's part of > an aggregate. It sounds like the same is True for Fortran as well. > But it does look from your experiments that C++ only dereferences > in some of the cases (e.g. when printing a struct with a field being > a reference, the field's value is the address, without the actual > underlying value). This question would have an impact on the warning, > since we would warn only when there is auto-dereferencing. > > For the timing of the warning, at least, it seems clear to me that > it would be printed when printing the value. Do we want to print it > when accessing the value too? It would seem logical, I think, but > are there scenarios where this could be counter-productive? > > There's also the question of avoiding to get the warning printed > in the middle of the value itself. This might be a bit minor, but > it's something I've always found to be distracting and hard to read, > when a warning is lost with some other data being printed. > > > > Have you looked at how we handle components which are references? > > > I wonder how well we handle those... > > > > As above we treat them as pointers, but guard against possible > > confusion by displaying them as pointers. > > > > 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. 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? What happens if the parent object is assigned to a user variable? My Ada foo is weak, but I'll try to dig into this and understand what happens, but maybe you know the answer already. 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. Thanks, Andrew > > (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.