From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58042 invoked by alias); 15 Nov 2017 18:52:10 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 56429 invoked by uid 89); 15 Nov 2017 18:52:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=Hopefully, convinced, his X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 15 Nov 2017 18:52:07 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 630AA1161B7; Wed, 15 Nov 2017 13:52:06 -0500 (EST) 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 TDS7O2Aregt0; Wed, 15 Nov 2017 13:52:06 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 325CA1161B5; Wed, 15 Nov 2017 13:52:06 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 4EE6687459; Wed, 15 Nov 2017 10:52:04 -0800 (PST) Date: Wed, 15 Nov 2017 18:52:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: RFC: problems with minimal symbols (without a type) Message-ID: <20171115185204.qku477ejfyescpie@adacore.com> References: <20171109012540.ds5ixw4pq6rclhgc@adacore.com> <4bca71af-2877-2adf-9f54-e51d7e6b5b8b@redhat.com> <20171115013531.cwj5pzjttrihofhl@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2017-11/txt/msg00283.txt.bz2 > I'm not seeing this as independent -- if GDB assumes unknown > types are integers, then we won't need to support casting from > unknown types to anything else in the first place, it just > falls out of supporting conversion from integer to anything else. Right. I forgot about those variables having a TYPE_CODE_ERROR. > I actually pasted that part just for completeness. The point I was > really trying to convey is in the unquoted part. I.e, that this is > really a FAQ, that frequently users show up on IRC confused > by GDB showing incorrect results they can't explain. Ah, that's because that was the part that I was less convinced about ;-). I can accept that less experienced users might be confused indeed. > Thanks! Hopefully it'll be a simple change to ada_evaluate_subexp's > UNOP_CAST handling, mirroring the evaluate_subexp_for_cast in > eval.c. Let me know if you run into something odd. That's pretty much it. There is still an unknown inside the "resolve" part, but I spent most of yesterday trying to see if I could reuse the standard code more. Couldn't find a better way, but let's take it one bird at a time... > > That got me to one piece of code in evaluate_subexp_for_cast: > > > > /* Don't allow e.g. '&(int)var_with_no_debug_info'. */ > > if (VALUE_LVAL (val) == lval_memory) > > { > > if (value_lazy (val)) > > value_fetch_lazy (val); > > VALUE_LVAL (val) = not_lval; > > } > > > > I was wondering why do we not want to allow someone get its > > address? I checked the commit that introduced this change, > > and it doesn't say. > > This is to follow usual language rules. A cast expression isn't > an lvalue, so you can't take its address: Ah, ok. My philosophy is been that it's OK, and sometimes good, to allow in the debugger something that's not allowed in the language, if it makes it easier for the user to do his debugging. Would allowing this as an extension be introducing possible confusion? > (top-gdb) p s > $1 = 0x1ec6d00 "long_integer (e) = long_integer (&const__aint_global_gdb_e)" > > Curious, I didn't know that "&" worked in Ada too. Yes. We found that we could extend the expression interpreter to accept some of the same syntaxes that are familiar to a C developer. It's very convenient, because it's quite short :). That was before my time, but I think that's also why we chose the "{TYPE}" syntax for Ada as well, to mimic what is done in C. -- Joel