From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id MsYKI3OY71/2TAAAWB0awg (envelope-from ) for ; Fri, 01 Jan 2021 16:47:31 -0500 Received: by simark.ca (Postfix, from userid 112) id 4155F1F0B7; Fri, 1 Jan 2021 16:47:31 -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.9 required=5.0 tests=DKIM_SIGNED, MAILING_LIST_MULTI,T_DKIM_INVALID,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 F03E41E590 for ; Fri, 1 Jan 2021 16:47:29 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 792F0384640D; Fri, 1 Jan 2021 21:47:29 +0000 (GMT) Received: from gateway33.websitewelcome.com (gateway33.websitewelcome.com [192.185.146.130]) by sourceware.org (Postfix) with ESMTPS id 83D0538618C3 for ; Fri, 1 Jan 2021 21:47:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 83D0538618C3 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=tom@tromey.com Received: from cm11.websitewelcome.com (cm11.websitewelcome.com [100.42.49.5]) by gateway33.websitewelcome.com (Postfix) with ESMTP id C8DF4A6657D for ; Fri, 1 Jan 2021 15:47:25 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id vSGbka172nPrxvSGbkldYn; Fri, 01 Jan 2021 15:47:25 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Transfer-Encoding:MIME-Version:Message-Id:Date:Subject: To:From:Sender:Reply-To:Cc:Content-Type:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=SslL3AxmELM+DGq4aNFZGZ2pvB2/mFHK6Y2SahR0sas=; b=sGSh24CVonUxOaKwvm9SQ5L4Ns 2sGrieLS5j9Hsl9P2Vb9tcP7CB4iFOxQUdmP0N1jia1vEK3NOqAY1u2q8rp92ZnRQlkJWY9P3aDdO Lg5ePipJArrTLXJGVNDOOEQ+/; Received: from 97-122-81-39.hlrn.qwest.net ([97.122.81.39]:60372 helo=localhost.localdomain) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kvSGb-0028yz-KH for gdb-patches@sourceware.org; Fri, 01 Jan 2021 14:47:25 -0700 From: Tom Tromey To: gdb-patches@sourceware.org Subject: [PATCH 000/203] Refactor expressions Date: Fri, 1 Jan 2021 14:44:00 -0700 Message-Id: <20210101214723.1784144-1-tom@tromey.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 97.122.81.39 X-Source-L: No X-Exim-ID: 1kvSGb-0028yz-KH X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 97-122-81-39.hlrn.qwest.net (localhost.localdomain) [97.122.81.39]:60372 X-Source-Auth: tom+tromey.com X-Email-Count: 1 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes 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: , Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" I have long thought that struct expression is the worst data structure in GDB. In fact, I've sometimes told people it is the worst data structure I've encountered in my career. I've wanted to rewrite it for many years, and this year I finally found a workable plan and the motivation to do so. This series is the result. The new approach is what I consider to be the most obvious data structure to use here: a base class represents a single node of an expression tree, and concrete subclasses implement the various operations. Each object maintains its own storage. In the end, 'struct expression' is just a simple wrapper around the root node of a tree. The weird things in the current code -- the strange way storage is handled, and the need to "rotate" the expression after creation -- are gone. The series is, of course, extremely long. This is partly due to my desire to split it up so that each patch is reasonably understandable, but also partly because it is just unavoidable. Conceptually it can be divided into multiple sub-series. I didn't submit these separately, though, as they don't really make sense independently. I've already submitted any patch that was truly separate. (These aren't all in yet, though, and this series depends on them.) Here are the sub-series: 1. Split functions out from the evaluators. Each evaluator function is fairly long, and mixes knowledge about the structure of the expression (how the exp_elements are laid out) with knowledge of the semantics of the operation. This part of the series, which is about 70 patches, splits out the semantics of most operations into their own functions. These functions can be then be reused -- which is helpful for ensuring that changes don't sneak in. In this part of the series, sometimes the newly-introduced functions have extraneous arguments. This was done partly so that some could be reused by generic code in part 2; but also partly because it was just simpler to write patches by rote. 2. Introduce 'class operation' and its subclasses. This sub-series is around 100 patches. It introduces the new base class for an expression operation, and then proceeds to add operations for every necessary opcode. In some cases multiple such operations are needed -- for example when multiple languages implement an opcode in different ways. Some discussion of the design & tradeoffs appear in the "Introduce class operation" patch. 3. Convert existing code to use operations. This is a short sub-series of around 10 patches. Each parser is converted separately, as are DTrace and SystemTap probes 4. Delete obsolete code. The final 20 patches or so are concerned with removing all the code that is now obsolete, and with doing some minor tidying of the result. The overall approach here is to replace the current data structure -- but only the data structure. I didn't generally try to clean up things that seemed a bit weird. I also didn't try to add new features, like async evaluation. After starting the project, I felt that trying to combine this refactoring with another, different one would be too difficult. This is all on the branch t/expression-rewrite-incr in my github. Regression tested on x86-64 Fedora 32. I also built it on PPC Linux to ensure that the ppc-linux-nat.c changes would build. Tom