Message ID | 20230313-split-objfile-type-allocator-2-v1-0-69ba773ac17b@tromey.com |
---|---|
Headers |
Return-Path: <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2D176383E81B for <patchwork@sourceware.org>; Mon, 13 Mar 2023 22:10:04 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from outbound-ss-761.bluehost.com (outbound-ss-761.bluehost.com [74.220.211.250]) by sourceware.org (Postfix) with ESMTPS id 0BDAA3858412 for <gdb-patches@sourceware.org>; Mon, 13 Mar 2023 22:08:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0BDAA3858412 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com Received: from cmgw10.mail.unifiedlayer.com (unknown [10.0.90.125]) by progateway8.mail.pro1.eigbox.com (Postfix) with ESMTP id 8DF4D1004CA42 for <gdb-patches@sourceware.org>; Mon, 13 Mar 2023 22:08:06 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id bqKspfLFTHIU4bqKspFy9G; Mon, 13 Mar 2023 22:08:06 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=NfUja0P4 c=1 sm=1 tr=0 ts=640f9ec6 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=IkcTkHD0fZMA:10:nop_charset_1 a=k__wU0fu6RkA:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=zstS-IiYAAAA:8 a=Y2XxTl1ky1PgmuFFt88A:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=4G6NA9xxw8l3yy4pmD5M:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=To:Content-Transfer-Encoding:Content-Type:MIME-Version: Message-Id:Date:Subject:From:Sender:Reply-To:Cc: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=TAJZN2t6WffeBIH7bo6ty7a8VsIDJuTgIMEyuqtBzBE=; b=CNryHRVOa8V3hIT1wI4W0z4qns nV4DHNbvR0thqMuK4w0Kpr3cZNItz9vm8cD9LJO+g8J2hvm6H+OzJ0t9LI4lhmZQj+Yvg8BHIPx3J hpTPT/7QDoT448NxOBJ8cULGn; Received: from 71-211-185-113.hlrn.qwest.net ([71.211.185.113]:52788 helo=[192.168.0.21]) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <tom@tromey.com>) id 1pbqKs-000u2m-7i for gdb-patches@sourceware.org; Mon, 13 Mar 2023 16:08:06 -0600 From: Tom Tromey <tom@tromey.com> Subject: [PATCH 00/20] Remove objfile_type Date: Mon, 13 Mar 2023 16:08:00 -0600 Message-Id: <20230313-split-objfile-type-allocator-2-v1-0-69ba773ac17b@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAMGeD2QC/x2NQQrCMBAAv1JydiFNkapfEQ+buLErMQm7QZTSv 5t6HAZmVqMkTGouw2qE3qxccofxMJiwYH4Q8L2zcdZNdhon0Jq4QfHPyImgfSsBplQCtiLgwM7 nk41ojziT6RGPSuAFc1j2zAu1keyiCkX+/M/X27b9AIzv0OWJAAAA To: gdb-patches@sourceware.org X-Mailer: b4 0.12.1 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: 71.211.185.113 X-Source-L: No X-Exim-ID: 1pbqKs-000u2m-7i X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 71-211-185-113.hlrn.qwest.net ([192.168.0.21]) [71.211.185.113]:52788 X-Source-Auth: tom+tromey.com X-Email-Count: 1 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3020.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list <gdb-patches.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=subscribe> Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
Remove objfile_type
|
|
Message
Tom Tromey
March 13, 2023, 10:08 p.m. UTC
The "split objfile" to-do list has an item for moving objfile_type to the per-BFD object. However, I noticed recently that the contents of objfile_type depend solely on the gdbarch. So, there's no reason to even have this on the objfile at all. In fact, I reasoned, we could go further and remove it in favor of the per-gdbarch builtin_type. However, this doesn't work due to the way type allocation is done. I have never much liked this part of gdb, so this series first attempts to clean it up, by introducing a type allocator. This allows for the removal of some code. During this process, the symbol readers are changed to prefer allocation of their types on the per-objfile obstack, which I think is more correct anyway. Finally, by the end of the series, objfile_type can be removed. Regression tested on x86-64 Fedora 36. Tom --- Tom Tromey (20): Introduce type_allocator Remove alloc_type_arch Remove alloc_type_copy Remove alloc_type Reuse existing builtin types Remove arch_type Remove init_type Unify arch_integer_type and init_integer_type Unify arch_character_type and init_character_type Unify arch_boolean_type and init_boolean_type Unify arch_float_type and init_float_type Unify arch_decfloat_type and init_decfloat_type Unify arch_pointer_type and init_pointer_type Use type allocator for range types Use type allocator for array types Use type allocator for set types Use builtin type when appropriate Rename objfile_type to builtin_type Add some types to struct builtin_type Remove objfile_type gdb/ada-lang.c | 92 ++--- gdb/amdgpu-tdep.c | 5 +- gdb/arm-tdep.c | 9 +- gdb/avr-tdep.c | 6 +- gdb/coffread.c | 42 +-- gdb/compile/compile-c-symbols.c | 10 +- gdb/compile/compile-c-types.c | 11 +- gdb/compile/compile-cplus-symbols.c | 10 +- gdb/compile/compile-cplus-types.c | 5 +- gdb/csky-tdep.c | 5 +- gdb/ctfread.c | 47 +-- gdb/d-lang.c | 44 +-- gdb/dwarf2/cu.c | 2 +- gdb/dwarf2/expr.c | 9 +- gdb/dwarf2/read.c | 111 +++--- gdb/f-exp.y | 13 +- gdb/f-lang.c | 55 +-- gdb/fbsd-tdep.c | 20 +- gdb/ft32-tdep.c | 5 +- gdb/gdbtypes.c | 704 +++++++++++------------------------- gdb/gdbtypes.h | 266 ++++++++++---- gdb/gnu-v3-abi.c | 9 +- gdb/go-lang.c | 34 +- gdb/ia64-tdep.c | 9 +- gdb/jit.c | 5 +- gdb/linux-tdep.c | 29 +- gdb/m2-lang.c | 12 +- gdb/m32c-tdep.c | 24 +- gdb/m68k-tdep.c | 9 +- gdb/mdebugread.c | 95 ++--- gdb/nds32-tdep.c | 7 +- gdb/netbsd-tdep.c | 22 +- gdb/objfiles.c | 4 +- gdb/opencl-lang.c | 43 +-- gdb/parse.c | 12 +- gdb/rl78-tdep.c | 20 +- gdb/rs6000-tdep.c | 3 +- gdb/rust-lang.c | 33 +- gdb/sh-tdep.c | 9 +- gdb/stabsread.c | 155 ++++---- gdb/target-descriptions.c | 18 +- gdb/valops.c | 10 +- gdb/windows-tdep.c | 55 +-- gdb/xcoffread.c | 4 +- gdb/xtensa-tdep.c | 3 +- gdb/z80-tdep.c | 7 +- 46 files changed, 1014 insertions(+), 1088 deletions(-) --- base-commit: 7fee66abd3fd69a0c4dc6c8dcd9aa49eede3864e change-id: 20230313-split-objfile-type-allocator-2-07980fa05a7e Best regards,
Comments
On 3/13/23 18:08, Tom Tromey wrote: > The "split objfile" to-do list has an item for moving objfile_type to > the per-BFD object. However, I noticed recently that the contents of > objfile_type depend solely on the gdbarch. So, there's no reason to > even have this on the objfile at all. In fact, I reasoned, we could > go further and remove it in favor of the per-gdbarch builtin_type. > > However, this doesn't work due to the way type allocation is done. I > have never much liked this part of gdb, so this series first attempts > to clean it up, by introducing a type allocator. This allows for the > removal of some code. During this process, the symbol readers are > changed to prefer allocation of their types on the per-objfile > obstack, which I think is more correct anyway. > > Finally, by the end of the series, objfile_type can be removed. I went quickly through the series, it looks like a nice simplification. The type_allocator stuff seems to remove a lot of duplication, and obviously the removal of objfile_type does too. Given I just gave it a quick look: Reviewed-By: Simon Marchi <simon.marchi@efficios.com> Simon
Simon> I went quickly through the series, it looks like a nice Simon> simplification. The type_allocator stuff seems to remove a lot of Simon> duplication, and obviously the removal of objfile_type does too. Simon> Given I just gave it a quick look: Simon> Reviewed-By: Simon Marchi <simon.marchi@efficios.com> Thanks. I'm rebuilding it & re-testing it. Since the changes were pretty trivial (some parameters names in a .h and a couple of comment changes), I'm not going to re-send it. I'll check it in once regression testing is done. Tom