Date: Thu, 17 Nov 2016 23:16:56 +0000 (UTC) From: Bryan Drewery <bdrewery@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r308788 - head/usr.bin/gcore Message-ID: <201611172316.uAHNGuYV064389@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: bdrewery Date: Thu Nov 17 23:16:56 2016 New Revision: 308788 URL: https://svnweb.freebsd.org/changeset/base/308788 Log: Cleanup some leftovers from '-s' removal in r302792. MFC after: 2 weeks Sponsored by: Dell EMC Isilon Modified: head/usr.bin/gcore/gcore.c Modified: head/usr.bin/gcore/gcore.c ============================================================================== --- head/usr.bin/gcore/gcore.c Thu Nov 17 23:05:34 2016 (r308787) +++ head/usr.bin/gcore/gcore.c Thu Nov 17 23:16:56 2016 (r308788) @@ -143,21 +143,6 @@ main(int argc, char *argv[]) fd = open(corefile, O_RDWR|O_CREAT|O_TRUNC, DEFFILEMODE); if (fd < 0) err(1, "%s", corefile); - /* - * The semantics of the 's' flag is to stop the target process. - * Previous versions of gcore would manage this by trapping SIGHUP, - * SIGINT and SIGTERM (to be passed to the target pid), and then - * signal the child to stop. - * - * However, this messes up if the selected dumper uses ptrace calls - * that leave the child already stopped. The waitpid call in elfcore - * never returns. - * - * The best thing to do here is to externalize the 's' flag and let - * each dumper dispose of what that means, if anything. For the elfcore - * dumper, the 's' flag is a no-op since the ptrace attach stops the - * process in question already. - */ dumper->dump(efd, fd, pid); (void)close(fd); @@ -169,6 +154,6 @@ void usage(void) { - (void)fprintf(stderr, "usage: gcore [-s] [-c core] [executable] pid\n"); + (void)fprintf(stderr, "usage: gcore [-c core] [executable] pid\n"); exit(1); }
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201611172316.uAHNGuYV064389>