From: John Baldwin <jhb@freebsd.org>
To: Simon Marchi <simark@simark.ca>
Cc: gdb-patches@sourceware.org, binutils@sourceware.org
Subject: Re: [PATCH 3/4] Support 'info proc' for native FreeBSD processes.
Date: Wed, 03 Jan 2018 19:05:00 -0000 [thread overview]
Message-ID: <137803623.10H6MxTIBr@ralph.baldwin.cx> (raw)
In-Reply-To: <d23979ca-e9ad-f9c1-a09c-bbd966499e13@simark.ca>
On Tuesday, December 26, 2017 09:22:52 PM Simon Marchi wrote:
> On 2017-12-22 05:05 PM, John Baldwin wrote:
> > + else
> > + {
> > + pid = strtol (built_argv[0], NULL, 10);
> > + }
>
> Unnecessary curly braces.
Fixed.
> > +#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.
> > +
> > + if (vmentl)
>
> vmentl != NULL
>
> There are a few other instances of if (ptr) that should be changed to if (ptr != NULL).
Ok. The style in GDB doesn't seem consistent in this regard (I largely based this
code on the 'info proc' implementation in linux-tdep.c which doesn't explicitly
compare against NULL/nullptr (though I prefer the explicit comparison myself)).
Also, I feel like we should use nullptr rather than NULL when working with "smart"
pointer types like unique_ptr<> at least?
> > @@ -461,23 +828,6 @@ show_fbsd_lwp_debug (struct ui_file *file, int from_tty,
> > }
> >
> > #if defined(TDP_RFPPWAIT) || defined(HAVE_STRUCT_PTRACE_LWPINFO_PL_TDNAME)
> > -/* Fetch the external variant of the kernel's internal process
> > - structure for the process PID into KP. */
> > -
> > -static void
> > -fbsd_fetch_kinfo_proc (pid_t pid, struct kinfo_proc *kp)
> > -{
> > - size_t len;
> > - int mib[4];
> > -
> > - len = sizeof *kp;
> > - mib[0] = CTL_KERN;
> > - mib[1] = KERN_PROC;
> > - mib[2] = KERN_PROC_PID;
> > - mib[3] = pid;
> > - if (sysctl (mib, 4, kp, &len, NULL, 0) == -1)
> > - perror_with_name (("sysctl"));
> > -}
> > #endif
>
> This leaves an empty #if/#endif. Should it be removed or moved with the function?
Removed, good catch.
--
John Baldwin
next prev parent reply other threads:[~2018-01-03 19:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-22 22:05 [PATCH 0/4] Support for 'info proc' on FreeBSD cores and native John Baldwin
2017-12-22 22:05 ` [PATCH 1/4] Create psuedo sections for FreeBSD NT_PROCSTAT_(PROC|FILES|VMMAP) notes John Baldwin
2017-12-27 1:18 ` Simon Marchi
2018-01-02 11:49 ` Nick Clifton
2017-12-22 22:05 ` [PATCH 3/4] Support 'info proc' for native FreeBSD processes John Baldwin
2017-12-27 2:23 ` Simon Marchi
2018-01-03 19:05 ` John Baldwin [this message]
2018-01-03 19:13 ` Simon Marchi
2018-01-03 21:56 ` John Baldwin
2017-12-22 22:05 ` [PATCH 2/4] Support 'info proc' for FreeBSD process core dumps John Baldwin
2017-12-27 1:56 ` Simon Marchi
2018-01-03 19:05 ` John Baldwin
2017-12-22 22:13 ` [PATCH 4/4] Document support for 'info proc' on FreeBSD John Baldwin
2017-12-23 8:46 ` Eli Zaretskii
2017-12-27 1:53 ` [PATCH 0/4] Support for 'info proc' on FreeBSD cores and native Simon Marchi
2018-01-03 19:05 ` John Baldwin
2018-01-03 19:15 ` Simon Marchi
2018-01-03 23:39 ` John Baldwin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=137803623.10H6MxTIBr@ralph.baldwin.cx \
--to=jhb@freebsd.org \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=simark@simark.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox