From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Bp+4H2xsiWAKJwAAWB0awg (envelope-from ) for ; Wed, 28 Apr 2021 10:08:44 -0400 Received: by simark.ca (Postfix, from userid 112) id 749C01F11C; Wed, 28 Apr 2021 10:08:44 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.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 9BF841E01F for ; Wed, 28 Apr 2021 10:08:43 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id F41533A9DC33; Wed, 28 Apr 2021 14:08:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F41533A9DC33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1619618923; bh=+f2RASpvtWCbt8iScqR5AE0/G/jJmP4FY1Oc5xZpsAA=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=ZUSXLiMHt/Yq7fY2V3Jo1r9RwZKrPlyLQNEKowq4EXImRNAz4jCROjVNM601EprjG FFvrrHVd4NtuNIWvoFCn2INaABTFkjZVfPR7L3KKqaVg/FLwIc7MKtxBkSBeIv1pNz Lh9T2mnhIuPm9XvXXEcsEbclqT6B6HQX5wlc4K+Q= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 88947385701E for ; Wed, 28 Apr 2021 14:08:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 88947385701E 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 13SE8Rt0003125 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Apr 2021 10:08:31 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 13SE8Rt0003125 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) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 024801E01F; Wed, 28 Apr 2021 10:08:26 -0400 (EDT) Subject: Re: [PATCH 01/43] Replace the symbol needs evaluator with a parser To: Zoran Zaric , gdb-patches@sourceware.org References: <20210301144620.103016-1-Zoran.Zaric@amd.com> <20210301144620.103016-2-Zoran.Zaric@amd.com> <33656bad-0e3c-95eb-1dcf-5357cf861422@amd.com> Message-ID: Date: Wed, 28 Apr 2021 10:08:26 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <33656bad-0e3c-95eb-1dcf-5357cf861422@amd.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 Wed, 28 Apr 2021 14:08:27 +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 Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2021-04-28 6:17 a.m., Zoran Zaric wrote: > >>> Some concerns were raised that a linear scan of the expression byte >>> stream would have issues if a DWARF producer would try to hide some >>> non DWARF related data after a control flow operation. Although the >>> testsuite doesn't show this case, it is a valid concern, so one of >>> the later patches in this series will address it by switching back to >>> the then redesigned DWARF expression evaluator. >> >> While re-reading your exchange with Tom, I was under the impression that >> traversing the "control flow graph" of the expression, visiting each >> node only once, would be a good solution. It would avoid the infinite >> loop problem, the "two branches" problem, and even the corner cases >> where you have garbage in the middle of the expression, or if the >> expression jumps in the middle of an instruction to re-use the operand >> of an instruction as an instruction. >> >> Patch 39 changes this back to an evaluator, so I'm not sure if this is >> what you implemented or something else, I'll see when I get there. > > There is no concept of a "control flow graph" in the existing gdb evaluator, there is just a byte stream that gdb either fully traverse and evaluates or it "fakes" the target access. When I meant "control flow graph", I didn't mean to have a proper control flow graph representation with classes and all (unless we think it would be useful), but just navigate it conceptually. You maintain a queue of "to visit" instructions and a set of "already visited" instructions. You by pushing the first instruction in the queue and work until the queue is empty. For all instructions but conditional jumps, you push the instruction after it in the queue. For conditional jumps, you also push the jump target in the queue. You maintain the "already visited" set on the side to avoid visiting the same instruction twice, in case there are loops. > > The solution that Tom talked about was just an idea that he used in some other tool and would need to be implemented from scratch. > > The patch 39 switches the evaluator design to throwing the missing context exception idea which re-enables using the same evaluator for both purposes. I'll see and understand better when I get there. But from what I understood of past dicussions, using the evaluator may give wrong results, because one branch may require only registers while another branch may require a frame (that's the point of your patch). So I don't really understand how going back to using an evaluator would work. Although that depends on the semantic we want symbol_needs to have: - find what's needed to evaluate the expression in the current context, only in the branch that would be taken right now? - find what's needed to evaluate the expression in any possible context, considering all branches? Simon