Message ID | 20230105200237.987771-6-simon.marchi@polymtl.ca |
---|---|
State | Committed |
Commit | d246d904adf3e338c731c123219a8246281002e2 |
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 19C6A385843E for <patchwork@sourceware.org>; Thu, 5 Jan 2023 20:13:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 19C6A385843E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1672949585; bh=ILtPRLqy1I+1sYceU6jYhnJUDqO4F9nuh/bFUZMs6kw=; h=To:Cc:Subject:Date:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=wgwd1LRStrT95QMh33M7K6zaE2kYgy/oNZgQyoyKGx2CXeL1PFuirltZ07QE4NHTv 49hm4f6QX3ehGfD5eiw4n//6vHlYrStZOgwyhl363iUrkXChe2RsdUJfn29m4D6PqV KNpw2O26BFrwlMLSMkrgasJrcJVuJIoOVLtQaxho= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 9AF343858D33 for <gdb-patches@sourceware.org>; Thu, 5 Jan 2023 20:12:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9AF343858D33 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 305KCUZk015470 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Jan 2023 15:12:35 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 305KCUZk015470 Received: from simark.localdomain (unknown [217.28.27.60]) (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 ESMTPSA id 2C9DD1E4A3; Thu, 5 Jan 2023 15:02:40 -0500 (EST) To: gdb-patches@sourceware.org Cc: Simon Marchi <simon.marchi@efficios.com>, Andrew Burgess <aburgess@redhat.com> Subject: [PATCH v2 5/8] gdb: add gdbarch_up Date: Thu, 5 Jan 2023 15:02:34 -0500 Message-Id: <20230105200237.987771-6-simon.marchi@polymtl.ca> X-Mailer: git-send-email 2.39.0 In-Reply-To: <20230105200237.987771-1-simon.marchi@polymtl.ca> References: <20230105200237.987771-1-simon.marchi@polymtl.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Thu, 5 Jan 2023 20:12:30 +0000 X-Spam-Status: No, score=-3189.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham 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> From: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> Reply-To: Simon Marchi <simon.marchi@polymtl.ca> Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
Initial support for ROCm platform (AMD GPU) debugging
|
|
Commit Message
Simon Marchi
Jan. 5, 2023, 8:02 p.m. UTC
From: Simon Marchi <simon.marchi@efficios.com>
Add a gdbarch_up unique pointer type, that calls gdbarch_free on
deletion. This is used in the ROCm support patch at the end of this
series.
Change-Id: I4b808892d35d69a590ce83180f41afd91705b2c8
Approved-By: Andrew Burgess <aburgess@redhat.com>
---
gdb/gdbarch.h | 8 ++++++++
1 file changed, 8 insertions(+)
Comments
>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
Simon> From: Simon Marchi <simon.marchi@efficios.com>
Simon> Add a gdbarch_up unique pointer type, that calls gdbarch_free on
Simon> deletion. This is used in the ROCm support patch at the end of this
Simon> series.
gdbarch_free is just a wrapper around delete.
What if this typedef just used the default deleter instead?
Moving gdbarch to just use new/delete always looks pretty easy.
Tom
On 1/5/23 15:31, Tom Tromey wrote: >>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes: > > Simon> From: Simon Marchi <simon.marchi@efficios.com> > Simon> Add a gdbarch_up unique pointer type, that calls gdbarch_free on > Simon> deletion. This is used in the ROCm support patch at the end of this > Simon> series. > > gdbarch_free is just a wrapper around delete. > What if this typedef just used the default deleter instead? > Moving gdbarch to just use new/delete always looks pretty easy. > > Tom I think it would involve moving the struct gdbarch definition from gdbarch.c to gdbarch-gen.h, right? Simon
>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes: Simon> On 1/5/23 15:31, Tom Tromey wrote: >>>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes: >> Simon> From: Simon Marchi <simon.marchi@efficios.com> Simon> Add a gdbarch_up unique pointer type, that calls gdbarch_free on Simon> deletion. This is used in the ROCm support patch at the end of this Simon> series. >> >> gdbarch_free is just a wrapper around delete. >> What if this typedef just used the default deleter instead? >> Moving gdbarch to just use new/delete always looks pretty easy. >> >> Tom Simon> I think it would involve moving the struct gdbarch definition from gdbarch.c Simon> to gdbarch-gen.h, right? Ugh, yeah, never mind. It would be nice, maybe, to convert all this so the accessors are inlined and whatnot, but it's a much bigger job. This looks ok to me. Tom
On 1/5/23 15:41, Tom Tromey wrote: >>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes: > > Simon> On 1/5/23 15:31, Tom Tromey wrote: >>>>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes: >>> > Simon> From: Simon Marchi <simon.marchi@efficios.com> > Simon> Add a gdbarch_up unique pointer type, that calls gdbarch_free on > Simon> deletion. This is used in the ROCm support patch at the end of this > Simon> series. >>> >>> gdbarch_free is just a wrapper around delete. >>> What if this typedef just used the default deleter instead? >>> Moving gdbarch to just use new/delete always looks pretty easy. >>> >>> Tom > > Simon> I think it would involve moving the struct gdbarch definition from gdbarch.c > Simon> to gdbarch-gen.h, right? > > Ugh, yeah, never mind. It would be nice, maybe, to convert all this so > the accessors are inlined and whatnot, but it's a much bigger job. I think it would be nice to C++-ify a bit (while keeping the same principle used today. Make all the function pointer fields private, and change all the gdbarch_* free functions to be methods instead. So a call like this: gdbarch_do_something (arch, 1, "hello"); would become arch->do_something (1, "hello"); ... which would still go through the function pointer underneath. Simon
diff --git a/gdb/gdbarch.h b/gdb/gdbarch.h index f4efd8c0bc78..f0399c2fa888 100644 --- a/gdb/gdbarch.h +++ b/gdb/gdbarch.h @@ -306,6 +306,14 @@ extern struct gdbarch *gdbarch_alloc (const struct gdbarch_info *info, extern void gdbarch_free (struct gdbarch *); +struct gdbarch_deleter +{ + void operator() (gdbarch *arch) const + { gdbarch_free (arch); } +}; + +using gdbarch_up = std::unique_ptr<gdbarch, gdbarch_deleter>; + /* Get the obstack owned by ARCH. */ extern obstack *gdbarch_obstack (gdbarch *arch);