From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 9JKAIewsDmDHcQAAWB0awg (envelope-from ) for ; Sun, 24 Jan 2021 21:29:00 -0500 Received: by simark.ca (Postfix, from userid 112) id 7993C1EF80; Sun, 24 Jan 2021 21:29:00 -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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED 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 9B4851E940 for ; Sun, 24 Jan 2021 21:28:59 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 38FA938708F2; Mon, 25 Jan 2021 02:28:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 38FA938708F2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1611541739; bh=PwJnpRYz9e1qtjJMWoV98wrdkEPkJF5VhFeYFPd3F0o=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=rko0ydsHe8BvUafHxqoW+PWq1K7BF5VJEGU4/SuoVkCz3T8gMFNpiGtaPV7R8qJnA Js2cKzzx++Ou1B3W8WBK6oUmgjAAbIqmH9IXI2Aov7fvQImMrE4THw87xiCp3xGAQW GcTVY5O7DRxwCCnB4KK9nw81KglZkRpxQkj72Xcc= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 5F3DD3858C27 for ; Mon, 25 Jan 2021 02:28:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5F3DD3858C27 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 10P2SnbW020800 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 24 Jan 2021 21:28:54 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 10P2SnbW020800 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 39E9E1E940; Sun, 24 Jan 2021 21:28:49 -0500 (EST) Subject: Re: [PATCH 009/203] what is this code for To: Joel Brobecker , Tom Tromey References: <20210101214723.1784144-1-tom@tromey.com> <20210101214723.1784144-10-tom@tromey.com> <20210103060009.GB285722@adacore.com> Message-ID: <3ecfae34-c2d5-873e-b67d-175beca08547@polymtl.ca> Date: Sun, 24 Jan 2021 21:28:48 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <20210103060009.GB285722@adacore.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 25 Jan 2021 02:28:49 +0000 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: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2021-01-03 1:00 a.m., Joel Brobecker wrote: > 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... > In addition to this good explanation: I tried removing the `|| pc == 0` from the code (based on current master) and got these failures: +FAIL: gdb.base/nodebug.exp: p sizeof(dataglobal + 1) +FAIL: gdb.base/nodebug.exp: ptype *dataglobal +FAIL: gdb.base/nodebug.exp: ptype dataglobal + 1 +FAIL: gdb.base/nodebug.exp: ptype sizeof(dataglobal + 1) +FAIL: gdb.base/nodebug.exp: whatis *dataglobal +FAIL: gdb.base/nodebug.exp: whatis dataglobal + 1 +FAIL: gdb.base/nodebug.exp: whatis sizeof(dataglobal + 1) So it's already covered. Tom, are these cases correctly handled with this series applied? Simon