From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64822 invoked by alias); 3 Jan 2018 21:56:26 -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 64802 invoked by uid 89); 3 Jan 2018 21:56:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=Hx-languages-length:1175 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 03 Jan 2018 21:56:24 +0000 Received: from ralph.baldwin.cx (astound-66-234-202-155.ca.astound.net [66.234.202.155]) by mail.baldwin.cx (Postfix) with ESMTPSA id 8461310A87D; Wed, 3 Jan 2018 16:56:22 -0500 (EST) From: John Baldwin To: gdb-patches@sourceware.org Cc: Simon Marchi , binutils@sourceware.org Subject: Re: [PATCH 3/4] Support 'info proc' for native FreeBSD processes. Date: Wed, 03 Jan 2018 21:56:00 -0000 Message-ID: <1609352.MG7B8nrzjn@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: References: <20171222220513.54983-1-jhb@FreeBSD.org> <137803623.10H6MxTIBr@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00040.txt.bz2 On Wednesday, January 03, 2018 02:13:28 PM Simon Marchi wrote: > Hi John, > > >> > +#ifdef HAVE_KINFO_GETVMMAP > >> > + if (do_mappings) > >> > + { > >> > + int nvment; > >> > + std::unique_ptr> > >> > >> Is there a reason to have and use free_deleter rather than > >> gdb::unique_xmalloc_ptr? > >> > >> > + vmentl (kinfo_getvmmap (pid, &nvment)); > > > > This function (kinfo_getvmmap) which is defined in the libutil library > > included in > > FreeBSD's base system calls malloc() internally, so the memory returned > > must be > > freed with free() rather than xfree(). This deleter is already used > > earlier in > > fbsd_find_memory_regions() for another call to kinfo_getvmmap() for > > the same reason. > > But isn't xfree just a wrapper around free? Ah, for some reason I thought that xmalloc/xfree were a matched pair that could in some cases refer to a separate malloc implementation, not always a wrapper around normal malloc() / free(). I'll remove the deleter altogether (and it's one existing use) in a future change. -- John Baldwin