Date: Thu, 19 Nov 2009 08:02:56 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Attilio Rao <attilio@freebsd.org> Cc: freebsd-current@freebsd.org, Ed Maste <emaste@freebsd.org> Subject: Re: [PATCH] Let gcore use ptrace interface rather than the procfs Message-ID: <alpine.BSF.2.00.0911190757430.12162@fledge.watson.org> In-Reply-To: <3bbf2fe10911181733j598083feiddf3d4b34d0007d6@mail.gmail.com> References: <3bbf2fe10911160718j7784b311g2980aa02c79bc9ec@mail.gmail.com> <alpine.BSF.2.00.0911171120050.47035@fledge.watson.org> <20091117141713.GA51251@sandvine.com> <9C740225-CB30-4D26-8E4B-F9D5DC51B899@FreeBSD.org> <3bbf2fe10911181733j598083feiddf3d4b34d0007d6@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 19 Nov 2009, Attilio Rao wrote: > 2009/11/17 Robert N. M. Watson <rwatson@freebsd.org>: >> >> On 17 Nov 2009, at 14:17, Ed Maste wrote: >> >>> Our original motivation for doing this was to make gcore work with >>> threaded apps, not avoiding procfs, but that's a useful side-effect of the >>> work. Note though that for that purpose it isn't complete; procfs is >>> still used in readmap to read the process' memory map. It looks like we >>> need to find a way to implement readmap without procfs. >> >> Are the sysctls used for procstat -v sufficient for this purpose? > > This patch should address the arised concerns by both of you: > http://www.freebsd.org/~attilio/Sandvine/STABLE_8/gcore/gcore2.diff > > and additively fix elf_getstatus() to not use procfs, so that gcore is > completely procfs independent now. Comments, reviews and testing are > welcome. If you add the missing include of sys/wait.h, elfcore.c generates an error instead of a warning on this non-traditional use of wait(2): + wait(); Something like this may be preferred: if (waitpid(pid, NULL, 0) < 0) err(1, "waitpid"); This further persisting reference to procfs can be replaced with a sysctl/kvm interface: gcore.c: asprintf(&binfile, "/proc/%d/file", pid); See the implementation of "procstat -b" which returns the path to the binary using the same underlying mechanism (vn_fullpath on the process image vnode). I think that kills the last of the procfs dependencies, in which case perhaps we can remove the procfs.h include from elfcore.c, which requires defining a local version of a summary data structure borrowed from procfs. It's worth trying with procfs unmounted, however, to make sure they're really all gone (which is how I ran into the above problem). Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0911190757430.12162>