From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83275 invoked by alias); 22 Dec 2017 22:05:49 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 83172 invoked by uid 89); 22 Dec 2017 22:05:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-8.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_3,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=ham version=3.3.2 spammy=1217 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 Dec 2017 22:05:43 +0000 Received: from ralph.baldwin.cx.com (astound-66-234-202-155.ca.astound.net [66.234.202.155]) by mail.baldwin.cx (Postfix) with ESMTPSA id B4E8810A8BC; Fri, 22 Dec 2017 17:05:41 -0500 (EST) From: John Baldwin To: gdb-patches@sourceware.org, binutils@sourceware.org Subject: [PATCH 0/4] Support for 'info proc' on FreeBSD cores and native Date: Fri, 22 Dec 2017 22:05:00 -0000 Message-Id: <20171222220513.54983-1-jhb@FreeBSD.org> X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00481.txt.bz2 This series adds initial support for the 'info proc' command on FreeBSD native processes and process cores. FreeBSD generally does not use the /proc filesystem, but instead exports data structures containing process information either via kernel system control nodes (for live processes), or in core dump notes. My assumption is that the format of 'info proc' is expected to be somewhat OS-specific though probably not gratuitously so. For 'info proc mappings' I choose to include both mapping attributes (such as permissions) along with the object file name. I did choose to implement versions of 'info proc stat' and 'info proc status' that are similar to the output on Linux for now. However, given that the output on FreeBSD is not tied to the output of files in /proc and that having both 'stat' and 'status' with overlapping content seems ambiguous, I do wonder if it wouldn't be better to just have a single command that includes one copy of the information (and perhaps treat 'stat' as an alias of 'status' on FreeBSD)? I also noticed in the document that there are older commands such as 'info proc id' and 'info proc time' that if implemented would contain a subset of the info in the 'stat' commands. I would possibly prefer to resurrect these commands on FreeBSD as subsets of 'stat/status'? What do you all think? I do eventually plan on adding a 'info proc files' that outputs a table of open file descriptors. For the documentation I made minimal changes to the existing documentation for 'info proc' to not state that it requires /proc, but the wording could probably use improvement. I have also not yet documented that FreeBSD supports 'proc stat' and 'proc status' due to the question above. John Baldwin (4): Create psuedo sections for FreeBSD NT_PROCSTAT_(PROC|FILES|VMMAP) notes. Support 'info proc' for FreeBSD process core dumps. Support 'info proc' for native FreeBSD processes. Document support for 'info proc' on FreeBSD. bfd/ChangeLog | 6 + bfd/elf.c | 12 + gdb/ChangeLog | 33 +++ gdb/config.in | 3 + gdb/configure | 60 +++++ gdb/configure.ac | 5 + gdb/doc/ChangeLog | 7 + gdb/doc/gdb.texinfo | 19 +- gdb/fbsd-nat.c | 404 ++++++++++++++++++++++++++++-- gdb/fbsd-tdep.c | 698 ++++++++++++++++++++++++++++++++++++++++++++++++++++ gdb/fbsd-tdep.h | 1 + 11 files changed, 1217 insertions(+), 31 deletions(-) -- 2.15.1