From: John Baldwin <jhb@freebsd.org>
To: Simon Marchi <simark@simark.ca>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v2 2/5] Don't return stale data from fbsd_pid_to_exec_file for kernel processes.
Date: Fri, 05 Jan 2018 19:43:00 -0000 [thread overview]
Message-ID: <1784143.eCmo5HAMmC@ralph.baldwin.cx> (raw)
In-Reply-To: <b6be3bbe-8dfd-2eb2-0738-a4fd78064069@simark.ca>
On Thursday, January 04, 2018 09:57:00 PM Simon Marchi wrote:
> On 2018-01-03 08:49 PM, John Baldwin wrote:
> > For processes without an associated executable (such as kernel processes),
> > the kern.proc.pathname.<pid> system control node returns a length of zero
> > without modifying the user's buffer. Detect this case and return NULL
> > rather than the previous contents of the static buffer 'buf'.
> >
> > gdb/ChangeLog:
> >
> > * fbsd-nat.c (fbsd_pid_to_exec_file) [KERN_PROC_PATHNAME]: Return
> > NULL for an empty pathname.
> > ---
> > gdb/ChangeLog | 5 +++++
> > gdb/fbsd-nat.c | 2 +-
> > 2 files changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/gdb/ChangeLog b/gdb/ChangeLog
> > index 29cfbb287b..804dd4f402 100644
> > --- a/gdb/ChangeLog
> > +++ b/gdb/ChangeLog
> > @@ -1,3 +1,8 @@
> > +2018-01-03 John Baldwin <jhb@FreeBSD.org>
> > +
> > + * fbsd-nat.c (fbsd_pid_to_exec_file) [KERN_PROC_PATHNAME]: Return
> > + NULL for an empty pathname.
> > +
> > 2018-01-03 John Baldwin <jhb@FreeBSD.org>
> >
> > * fbsd-tdep.c (KVE_STRUCTSIZE, KVE_START, KVE_END, KVE_OFFSET)
> > diff --git a/gdb/fbsd-nat.c b/gdb/fbsd-nat.c
> > index ec4eed9abe..7b1d1bf148 100644
> > --- a/gdb/fbsd-nat.c
> > +++ b/gdb/fbsd-nat.c
> > @@ -63,7 +63,7 @@ fbsd_pid_to_exec_file (struct target_ops *self, int pid)
> > mib[3] = pid;
> > buflen = sizeof buf;
> > if (sysctl (mib, 4, buf, &buflen, NULL, 0) == 0)
> > - return buf;
> > + return buflen == 0 ? NULL : buf;
> > #endif
> >
> > xsnprintf (name, PATH_MAX, "/proc/%d/exe", pid);
> >
>
> LGTM, but maybe add a comment saying in what situation the sysctl can
> return a buflen of 0.
Ok.
> Does the alternative method that reads from /proc/<pid>/exe work in that
> case too?
No. FreeBSD systems don't generally mount /proc (it's not enabled in the
default install), but in the case that 0 is returned, the relevant pointer
in the process structure (p_textvp) that '/proc/%d/exe' returns a path for
is NULL, so the procfs method will also fail.
Actually, I looked at FreeBSD's procfs and the node is named /proc/%d/file,
not /proc/%d/exe. I did confirm that FreeBSD's procfs does not create
'file' nodes for kernel processes (but also not for init (pid 1)).
I should in fact probably refine this function further to only use procfs
in the #else case if not remove it all together: the last release to not
include the pathname sysctl was FreeBSD 5.5 released in May 2006.
--
John Baldwin
next prev parent reply other threads:[~2018-01-05 19:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-04 1:50 [PATCH v2 0/5] Support for 'info proc' on FreeBSD cores and native John Baldwin
2018-01-04 1:50 ` [PATCH v2 1/5] Support 'info proc' for FreeBSD process core dumps John Baldwin
2018-01-05 2:54 ` Simon Marchi
2018-01-05 19:43 ` John Baldwin
2018-01-09 19:29 ` Simon Marchi
2018-01-04 1:50 ` [PATCH v2 3/5] Use gdb::unique_xmalloc_ptr<> instead of a deleter that invokes free() John Baldwin
2018-01-05 2:58 ` Simon Marchi
2018-01-04 1:50 ` [PATCH v2 2/5] Don't return stale data from fbsd_pid_to_exec_file for kernel processes John Baldwin
2018-01-05 2:57 ` Simon Marchi
2018-01-05 19:43 ` John Baldwin [this message]
2018-01-04 1:59 ` [PATCH v2 4/5] Support 'info proc' for native FreeBSD processes John Baldwin
2018-01-05 3:20 ` Simon Marchi
2018-01-05 19:43 ` John Baldwin
2018-01-04 1:59 ` [PATCH v2 5/5] Document support for 'info proc' on FreeBSD John Baldwin
2018-01-04 16:38 ` Eli Zaretskii
2018-01-04 21:36 ` John Baldwin
2018-01-05 6:53 ` Eli Zaretskii
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=1784143.eCmo5HAMmC@ralph.baldwin.cx \
--to=jhb@freebsd.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