Date: Tue, 28 Dec 2010 19:26:57 +0000 (UTC) From: John Baldwin <jhb@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/usr.bin/gcore Makefile elfcore.c extern.h gcore.1 gcore.c Message-ID: <201012281927.oBSJR7L1052828@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
jhb 2010-12-28 19:26:57 UTC
FreeBSD src repository
Modified files: (Branch: RELENG_7)
usr.bin/gcore Makefile elfcore.c extern.h gcore.1
gcore.c
Log:
SVN rev 216771 on 2010-12-28 19:26:57Z by jhb
MFC 199805,203532,204329,210063,210065:
- Change gcore in order to get rid of the procfs accesses and use FreeBSD's
specific sysctls and ptrace interfaces.
This change switches a bit gcore POLA that is summarized here:
- now gcore can recognize threads within the process and handle dumps
on thread-scope
- the process to be analyzed will be stopped during its gcore run
- gcore may not work with processes which are actively being analyzed
by gdb or truss
- the ptrace interface may cause syscalls to return EINTR, thus
interferring with signals handling within the process
- Fix gcore so that it can have the '-s' flag without hanging.
- Fix the way the segments are included in the gcore outputs (with the
default invokation):
- Right now if segments are not writable are not included. Remove this.
- Right now if a segment is mapped with NOCORE the check is not honoured.
Change this by checking the newly added flag, from libutil,
KVME_FLAG_NOCOREDUMP.
Besides that, add a new flag (-f) that forces a 'full' dump of all the
segments excluding just the malformed ones. This might be used very
carefully as, among the reported segments, there could be memory
mapped areas that could be vital to program execution.
Revision Changes Path
1.9.10.1 +2 -0 src/usr.bin/gcore/Makefile
1.19.2.3 +169 -181 src/usr.bin/gcore/elfcore.c
1.4.24.1 +4 -0 src/usr.bin/gcore/extern.h
1.15.18.1 +18 -14 src/usr.bin/gcore/gcore.1
1.31.18.1 +35 -34 src/usr.bin/gcore/gcore.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012281927.oBSJR7L1052828>