[PATCH 3/4] Support 'info proc' for native FreeBSD processes.
John Baldwin
jhb@freebsd.org
Wed Jan 3 21:56:00 GMT 2018
More information about the Binutils mailing list
Wed Jan 3 21:56:00 GMT 2018
- Previous message (by thread): [PATCH 3/4] Support 'info proc' for native FreeBSD processes.
- Next message (by thread): Documentation for .largecomm and friends
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): [PATCH 3/4] Support 'info proc' for native FreeBSD processes.
- Next message (by thread): Documentation for .largecomm and friends
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list