From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96021 invoked by alias); 17 Sep 2018 17:17:37 -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 95767 invoked by uid 89); 17 Sep 2018 17:17:36 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=completeness, gnulib, figured, our X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Sep 2018 17:17:35 +0000 Received: by simark.ca (Postfix, from userid 112) id DCE901E5A4; Mon, 17 Sep 2018 13:17:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=simark.ca; s=mail; t=1537204652; bh=iS+mOSJc1jYZLjRn79Z8fQTEIm9JrzyrhXNvmo7Z4+k=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=BVAknl4zOWQifQij63Yjgxs6g9F8wzbtVX+3al0tCuo5H0FmfAHhurfAICLrZd1K/ z2rq0ntk8lc+p/mvn9osIzSPaImI8rlGCTaKTzmHisvskaGI2dGcwI1hm1v7XjKIYz 6qOI4Lj8QzfdhGQNkgLf4xF6riC14vJMzHIXIRf0= Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 96CDB1E175; Mon, 17 Sep 2018 13:17:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=simark.ca; s=mail; t=1537204651; bh=iS+mOSJc1jYZLjRn79Z8fQTEIm9JrzyrhXNvmo7Z4+k=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=V9jV1In1kVVVZJJWx0SJZuICYHq0IGQfRj5utdJIL4ThouK0TVi9tynukvHUkfbTs TK8eAIid0pFw6yT95LxDZMvJkp1zrnqfsvIlol6ROFdVSjqjtLGIAK/a0hbK/mp4sM t0rInqKQr6s59yOmHHLBu0cgUwQIiG/qfs40QMJI= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 17 Sep 2018 17:17:00 -0000 From: Simon Marchi To: John Baldwin Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v2 0/6] Add a new 'info proc files' command In-Reply-To: <4228d440-13b6-73f6-751c-216bd2787ae2@FreeBSD.org> References: <20180912233707.43492-1-jhb@FreeBSD.org> <2ef5236e-0b21-b669-6759-d4441a3e744c@simark.ca> <4228d440-13b6-73f6-751c-216bd2787ae2@FreeBSD.org> Message-ID: X-Sender: simark@simark.ca User-Agent: Roundcube Webmail/1.3.6 X-SW-Source: 2018-09/txt/msg00590.txt.bz2 On 2018-09-17 12:58, John Baldwin wrote: > On 9/15/18 7:34 PM, Simon Marchi wrote: >> On 2018-09-12 7:37 p.m., John Baldwin wrote: >>> This should include most of the suggested documentation fixes from >>> the >>> first series. It also adds an additional patch that attempts to tidy >>> up >>> some of the other "info proc" documentation. One change I haven't >>> made >>> (wasn't sure if it was still desired) was if we wanted to replace the >>> specific annotations on individual 'info proc' subcommands about >>> which >>> OS's supported those commands with a single, more general statement >>> that >>> commands may only be supported on a subset of systems supported by >>> GDB. >>> >>> I've moved more of the shared code for generating the 'info proc >>> files' >>> output to fbsd-tdep.c. >>> >>> One open question still from the first series is if GDB can assume >>> the >>> presence of routines like 'inet_ntoa' and 'inet_ntop' for formatting >>> IPv4 and IPv6 addresses. It seems GDB does assume the presence of >>> newer routines (e.g. getaddrinfo()) on POSIX systems in other places >>> (e.g. ser-tcp.c), though in those places we use different APIs for >>> Win32. >> >> There seems to be a gnulib module for that: >> >> https://www.gnu.org/software/gnulib/manual/html_node/inet_005fntop.html >> >> There is a page for inet_ntoa too: >> >> https://www.gnu.org/software/gnulib/manual/html_node/inet_005fntoa.html >> >> but there is no gnulib module for it. Probably because we can always >> use inet_ntop instead? > > Yes, inet_ntop is sufficient for both. I had grepp'ed for 'ntoa' and > 'ntop' in gdb/gnulib and didn't find any matches, so I assumed that > meant there wasn't a module. Is gdb/gnulib a subset of the actual > gnulib > and new bits are imported on demand? > > Hmm, reading update-gnulib.sh, it seems so. I'll look at what is > involved > in doing that. You probably have it figured out by now, but for completeness: the gnulib directory in gdb is indeed a subset of the complete gnulib. gnulib comes with a tool (gnulib-tool) to create a package containing only the modules you want, and their dependencies. update-gnulib.sh in our codebase is just a wrapper around that. So it should just be a matter of adding the inet_ntop module in update-gnulib.sh and running it. Simon