This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 3/4] Support 'info proc' for native FreeBSD processes.
- From: John Baldwin <jhb at freebsd dot org>
- To: gdb-patches at sourceware dot org
- Cc: Simon Marchi <simark at simark dot ca>, binutils at sourceware dot org
- Date: Wed, 03 Jan 2018 13:07:10 -0800
- Subject: Re: [PATCH 3/4] Support 'info proc' for native FreeBSD processes.
- Authentication-results: sourceware.org; auth=none
- References: <20171222220513.54983-1-jhb@FreeBSD.org> <137803623.10H6MxTIBr@ralph.baldwin.cx> <fa25abff20db4c10f7bfed366a07c582@simark.ca>
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<struct kinfo_vmentry, free_deleter<struct kinfo_vmentry>>
> >>
> >> 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