From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 12 21:51:00 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 166C0B53; Tue, 12 Feb 2013 21:51:00 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by mx1.freebsd.org (Postfix) with ESMTP id 0DA983A7; Tue, 12 Feb 2013 21:50:58 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id dq12so467008wgb.12 for ; Tue, 12 Feb 2013 13:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=0pyKx6O5IfMTqBWxeerN64IwsXPidHIkU+7fg6D5/R0=; b=KQJhnrtt2Y7vZPtL6KNb529LHDootzbKV8mp4nY3iNiVuu5ZMAVwCKnl7v1WLqSWch Hp7UBUQPd8SoeDLhwBXYbXd+/VTiK1zIVbuK+r9Z2SNuS/WXeINX642X7Noligs+onkv 5n/zBi4cYxUF3tb+iDSuJKHxed6mP4mdp1CxCGnqS2YQpTO86oTcsQCBE4gffkkuz0ck mwaCffc2wRFENVUaAjBR4aimz8XP/+OeJ+8sP7JjAWAtHBw4I1c8lKFsKpqc1UMl1FJ1 LuVTsKcigbsgzBazg9iRmyooMIhZoVHYBTAkIsJ55WzuxvS7Ep4jW2b6mTs1F6Xl4XKz Gwkg== X-Received: by 10.194.92.65 with SMTP id ck1mr34075821wjb.54.1360705857920; Tue, 12 Feb 2013 13:50:57 -0800 (PST) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPS id hb9sm39149205wib.3.2013.02.12.13.50.56 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 12 Feb 2013 13:50:57 -0800 (PST) Sender: Mikolaj Golub Date: Tue, 12 Feb 2013 23:50:54 +0200 From: Mikolaj Golub To: John Baldwin Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130212215054.GA9839@gmail.com> References: <20130119151253.GB88025@gmail.com> <201301241120.52054.jhb@freebsd.org> <201301251531.43540.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201301251531.43540.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Stanislav Sedov , Kostik Belousov , "Robert N. M. Watson" , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 21:51:00 -0000 On Fri, Jan 25, 2013 at 03:31:43PM -0500, John Baldwin wrote: > BTW, one off-ball thought I have is that I would like to have a mode where > libprocstat operates on a core file (of a process, not a kernel crash dump), > so it could list the threads from a core dump, and possibly file descriptor > info (if PR kern/173723 is implemented). > > We certainly could have a 'raw' mode where it spat out name: value or XML > of the entire kinfo_proc perhaps. > It looks very interesting! Do you mean something like this? root@lisa:/root # sh -c 'kill -5 $$' Trace/BPT trap (core dumped) root@lisa:/root # ls -l sh.core -rw------- 1 root wheel 8790016 Feb 12 21:17 sh.core root@lisa:/root # procstat sh.core PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM 674 657 674 657 657 1 root - FreeBSD ELF32 sh root@lisa:/root # procstat -f sh.core PID COMM FD T V FLAGS REF OFFSET PRO NAME 674 sh text v r r-------- - - - /bin/sh 674 sh ctty v c rw------- - - - /dev/pts/0 674 sh cwd v d r-------- - - - /root 674 sh root v d r-------- - - - / 674 sh 0 v c rw------- 8 2537 - /dev/pts/0 674 sh 1 v c rw------- 8 2537 - /dev/pts/0 674 sh 2 v c rw------- 8 2537 - /dev/pts/0 root@lisa:/root # procstat -v sh.core PID START END PRT RES PRES REF SHD FL TP PATH 674 0x8048000 0x8064000 r-x 28 0 1 0 CN-- vn /bin/sh 674 0x8064000 0x8066000 rw- 2 0 1 0 ---- df 674 0x28064000 0x2807a000 r-x 22 0 17 0 CN-- vn /libexec/ld-elf.so.1 674 0x2807a000 0x28083000 rw- 9 0 1 0 ---- df 674 0x28084000 0x280a3000 r-x 31 32 2 1 CN-- vn /lib/libedit.so.7 674 0x280a3000 0x280a5000 rw- 2 0 1 0 C--- vn /lib/libedit.so.7 674 0x280a5000 0x280a7000 rw- 0 0 0 0 ---- -- 674 0x280a7000 0x280e0000 r-x 57 0 4 2 CN-- vn /lib/libncurses.so.8 674 0x280e0000 0x280e3000 rw- 3 0 1 0 C--- vn /lib/libncurses.so.8 674 0x280e3000 0x28213000 r-x 304 0 34 17 CN-- vn /lib/libc.so.7 674 0x28213000 0x2821a000 rw- 7 0 1 0 C--- vn /lib/libc.so.7 674 0x2821a000 0x28243000 rw- 16 0 2 0 ---- df 674 0x28400000 0x28c00000 rw- 24 0 2 0 ---- df 674 0xbfbdf000 0xbfbff000 rwx 3 0 1 0 ---D df 674 0xbfbff000 0xbfc00000 r-x 0 0 20 0 CN-- ph Here is my attempt to implement it: http://people.freebsd.org/~trociny/procstat_core.1.patch The patch needs much work yet, especially the userland part, but looks like it is good enough for demonstration purposes to discuss how this should be done properly. So, procstat data is stored in a core as note sections with name "FreeBSD" and types NT_PROCSTAT_PROC, NT_PROCSTAT_FILES, ... The current format of notes is a header of sizeof(int) and data in the format as it is returned by a related sysctl call. I think the header should provide some versioning and for the cases I implemented (kinfo_proc, kinfo_file, kinfo_vmentry) it contains a value of the corresponding kinfo struct size (e.g. KINFO_VMENTRY_SIZE). It might be not the best solution and I would be glad for suggestions. (BTW, why don't we have constants like KINFO_VMENTRY_SIZE defined for all archs?) To avoid code duplication I changed the code of kinfo sysctl handlers to output kinfo data to sbuf instead of calling SYSCTL_OUT directly so these functions could be used by both sysctl handlers and the coredump routine. Another thing I am not sure about is writing procstat data in the coredump routine. The coredump routine on the first pass calculates core sizes and on the second pass does actual writing. I added procstat in that way that procstat data is collected on the first run to internal buffers and on the second pass is copied from the buffers to the core. I could do this another way, e.g running kern_proc_*out() twice, on the fist pass with tiny buffer and a drain routine that would calculate data length, but this looks less efficient, complicates things and currently I am not sure that procstat sizes are not changeable between the passes. The issue with my approach I see is that after the first pass, before actually doing allocations we check corefile limits. I do allocations before checking the limit, so potentially using some kernel space when it might not be allowed by limits. Is this a problem I should worry and try another approach? I do nothing yet for freebsd32 compat case. I suppose I should check if the dumping process is running 32 binary and store procstat data in freebsd32 format? As I said there is much to do in userland, and I would like to concentrate on the kernel part and the format first, but I would be glad if somebody helps me with the problem I faced linking libelf to libprocstat. With the modifications to the libprocstat makefile: -DPADD= ${LIBKVM} ${LIBUTIL} -LDADD= -lkvm -lutil +DPADD= ${LIBELF} ${LIBKVM} ${LIBUTIL} +LDADD= -lelf -lkvm -lutil buildworld fails with the error: make: don't know how to make /scratch2/tmp/trociny/obj/i386.i386/home/trociny/svn/base/head/tmp/usr/lib/libelf.a. Stop -- Mikolaj Golub