From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50850 invoked by alias); 10 Sep 2018 18:30:32 -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 50778 invoked by uid 89); 10 Sep 2018 18:30:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=annoying, baldwin, Baldwin, HContent-Transfer-Encoding:8bit 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; Mon, 10 Sep 2018 18:30:23 +0000 Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id B86A710AFD2; Mon, 10 Sep 2018 14:30:20 -0400 (EDT) Subject: Re: [PATCH 4/5] Support 'info proc files' on live FreeBSD processes. To: Simon Marchi , gdb-patches@sourceware.org References: <20180908003659.37482-1-jhb@FreeBSD.org> <20180908003659.37482-5-jhb@FreeBSD.org> <5889a8bc-3941-677c-ff54-135b1bb9f2d6@ericsson.com> From: John Baldwin Message-ID: <78a76b21-779f-b44d-29ec-5494b1a5476d@FreeBSD.org> Date: Mon, 10 Sep 2018 18:30:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <5889a8bc-3941-677c-ff54-135b1bb9f2d6@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00291.txt.bz2 On 9/8/18 4:00 PM, Simon Marchi wrote: > On 2018-09-08 01:36 AM, John Baldwin wrote: >> This walks the list of struct kinfo_file objects returned by a call to >> kinfo_getfile outputting a description of each open file descriptor. > > LGTM. > > It would be nice to share the printing of the information between core > and live process, so that we can't forget to change one if we change the > other. But if there are some subtle differences between both loops that > would make sharing more annoying than anything, I don't mind. I've followed the same approach I used for 'info proc mappings' which is to use shared helper routines as much as possible. What I could perhaps do to share code is add new TARGET_FREEBSD_ target objects, but this would entail reworking the code quite a bit I think. It would mean that I would need a way to let a gdbarch hook into the core target's xfer_partial method more generically (right now there is a hook just for siginfo, but I think we'd want a hook for arbitrary objects). I would then rewrite the info proc bits in fbsd-tdep.c in terms of fetching target objects and always parsing them in the core dump format. I think there were a few things in some of the other 'info proc' methods that weren't quite as straightforward as for the 'files' and 'mappings' case though. -- John Baldwin                                                                            Â