From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67223 invoked by alias); 4 May 2018 16:36:34 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 66550 invoked by uid 89); 4 May 2018 16:36:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=target_close, realize X-HELO: gateway24.websitewelcome.com Received: from gateway24.websitewelcome.com (HELO gateway24.websitewelcome.com) (192.185.51.253) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 04 May 2018 16:36:32 +0000 Received: from cm15.websitewelcome.com (cm15.websitewelcome.com [100.42.49.9]) by gateway24.websitewelcome.com (Postfix) with ESMTP id 5B42875F20 for ; Fri, 4 May 2018 11:36:31 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id Edh9fkXkrbXuJEdh9f5YDc; Fri, 04 May 2018 11:36:31 -0500 X-Authority-Reason: nr=8 Received: from 97-122-176-117.hlrn.qwest.net ([97.122.176.117]:45988 helo=pokyo) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1fEdh9-002N0z-3n; Fri, 04 May 2018 11:36:31 -0500 From: Tom Tromey To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 3/3] Heap-allocate core_target instances References: <20180503162234.15371-1-palves@redhat.com> <20180503162234.15371-4-palves@redhat.com> Date: Fri, 04 May 2018 16:36:00 -0000 In-Reply-To: <20180503162234.15371-4-palves@redhat.com> (Pedro Alves's message of "Thu, 3 May 2018 17:22:34 +0100") Message-ID: <87in832x9t.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Source-L: No X-Exim-ID: 1fEdh9-002N0z-3n X-Source-Sender: 97-122-176-117.hlrn.qwest.net (pokyo) [97.122.176.117]:45988 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-SW-Source: 2018-05/txt/msg00094.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> This gets rid of the core_ops global, and replaces it with Pedro> heap-allocated core_target instances. In practice, there will only be Pedro> one such instance, though that will change further ahead as more Pedro> pieces of multi-target support are merged. Pedro> + /* FIXME: kettenis/20031023: Eventually this variable should Pedro> + disappear. */ Pedro> + struct gdbarch *m_core_gdbarch = NULL; This comment is very gdb. It was a bit hard to read the patch but I think I excerpted this correctly: Pedro> +void Pedro> +core_target::close () [...] Pedro> + delete this; I realize this is what was planned from your c++-ification series, but today I was wondering if this code path: void core_target::detach (inferior *inf, int from_tty) { unpush_target (this); => int unpush_target (struct target_ops *t) ... target_close (t); invokes undefined behavior. "delete this" seems to be ok if you are careful not to use "this" afterward, but is this particular use ok? I don't know the rule here but I thought I'd mention it just in case. Pedro> +/* Deleter for std::unique_ptr. Closes the target if an exception is Pedro> + thrown. */ Pedro> +struct target_ops_closer Pedro> +{ Pedro> + void operator() (target_ops *target) Pedro> + { Pedro> + target->close (); Pedro> + } Pedro> +}; This seems like something to put in target.h. Tom