From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 7pIpGnRd8V9mdwAAWB0awg (envelope-from ) for ; Sun, 03 Jan 2021 01:00:20 -0500 Received: by simark.ca (Postfix, from userid 112) id 5E6311F0AA; Sun, 3 Jan 2021 01:00:20 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=MAILING_LIST_MULTI,RDNS_NONE autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [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 678781E965 for ; Sun, 3 Jan 2021 01:00:19 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3D9E93857004; Sun, 3 Jan 2021 06:00:18 +0000 (GMT) Received: from rock.gnat.com (rock.gnat.com [IPv6:2620:20:4000:0:a9e:1ff:fe9b:1d1]) by sourceware.org (Postfix) with ESMTP id 376D63857004 for ; Sun, 3 Jan 2021 06:00:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 376D63857004 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 48159117225; Sun, 3 Jan 2021 01:00:15 -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 sIhW59cSVIwK; Sun, 3 Jan 2021 01:00:15 -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 D6B4F11721B; Sun, 3 Jan 2021 01:00:14 -0500 (EST) Received: by float.home (Postfix, from userid 1000) id 610A7A1608; Sun, 3 Jan 2021 10:00:09 +0400 (+04) Date: Sun, 3 Jan 2021 10:00:09 +0400 From: Joel Brobecker To: Tom Tromey Subject: Re: [PATCH 009/203] what is this code for Message-ID: <20210103060009.GB285722@adacore.com> References: <20210101214723.1784144-1-tom@tromey.com> <20210101214723.1784144-10-tom@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210101214723.1784144-10-tom@tromey.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 Tom, > @@ -1224,7 +1224,7 @@ eval_op_var_msym_value (struct type *expect_type, struct expression *exp, > > struct type *type = value_type (val); > if (type->code () == TYPE_CODE_ERROR > - && (noside != EVAL_AVOID_SIDE_EFFECTS || pc != 0)) > + && (noside != EVAL_AVOID_SIDE_EFFECTS)) > error_unknown_type (msymbol->print_name ()); > return val; I tracked the origin of this code down to the following commit... commit 46a4882b3c7d9ec981568b8b13a3c9c39c8f8e61 Author: Pedro Alves Date: Mon Sep 4 20:21:15 2017 +0100 Subject: Stop assuming no-debug-info variables have type int ... which was the second stage of a similar change for functions. The revision log did not really give an explicit explanation for this code, but after a bit of thinking, I think I was able to figure it out. Consider the case where you're trying to investigate a variable called "opaque" which is declared in the symbol table but does not have any debug info. * If noside != EVAL_AVOID_SIDE_EFFECTS (typically, we're trying to print the value, then we always error out with: | 'opaque' has unknown type; cast it to its declared type ... This is what the patch is about. That's not what you are asking about, because it's easy to understand. OK. * So, if noside == EVAL_AVOID_SIDE_EFFECTS, what does it mean to only print the error message above if pc != 0? Well, if pc == 0, it means OP_VAR_MSYM_VALUE node is first, and since that operator doesn't have any "parameters", what it means to me is that it must actually be the only operand of the expression. Thus, we must be facing the following situation: | (gdb) ptype opaque And what do we do in that scenario? Well, we have code in gdbtype.c which gives default types for the various kinds of minimal symbols. For data symbols, it looks like this: | objfile_type->nodebug_data_symbol | = init_nodebug_var_type (objfile, ""); So, when we do a ptype, we don't get an error, but instead, get some information about the symbol: | (gdb) ptype opaque | type = If, on the other hand pc != 0, it means our minsym is part of a larger expression, such as, for instance "opaque + 1". With today's GDB, a "ptype" of the expression above generates the same error message when when in EVAL_NORMAL mode: | (gdb) ptype opaque + 1 | 'opaque' has unknown type; cast it to its declared type If you remove the check above, then we no longer trigger the "has unknown type" error. So, instead, we just evaluate the minsym as is, which means we get a value whose type is the type of "objfile_type->nodebug_data_symbol", in other words TYPE_CODE_ERROR, which leads to: | (gdb) ptype opaque + 1 | Argument to arithmetic operation not a number or boolean. For minimal symbols which are text symbols, these get a default type of TYPE_CODE_FUNC, so removing the above breaks the check which forces the user to specify the return type. We should probably add a test or two in gdb.base/nodebug.exp for that... -- Joel