From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10970 invoked by alias); 2 Jan 2012 12:08:57 -0000 Received: (qmail 10961 invoked by uid 22791); 2 Jan 2012 12:08:55 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com) (209.85.212.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 02 Jan 2012 12:08:42 +0000 Received: by wibhq12 with SMTP id hq12so11231407wib.0 for ; Mon, 02 Jan 2012 04:08:41 -0800 (PST) Received: by 10.181.13.162 with SMTP id ez2mr105809864wid.17.1325506120965; Mon, 02 Jan 2012 04:08:40 -0800 (PST) Received: from [192.168.0.103] (bl16-31-110.dsl.telepac.pt. [188.81.31.110]) by mx.google.com with ESMTPS id fi11sm50348377wbb.9.2012.01.02.04.08.38 (version=SSLv3 cipher=OTHER); Mon, 02 Jan 2012 04:08:40 -0800 (PST) Message-ID: <4F019E45.5010906@gmail.com> Date: Mon, 02 Jan 2012 12:08:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Stan Shebs CC: Eli Zaretskii , gdb-patches@sourceware.org Subject: Re: [PATCH] Add extra 'info os' information types for Linux (trunk and 7.4) References: <4E95DC58.7030805@codesourcery.com> <4ECD3496.1070609@codesourcery.com> <4EF9497B.9020501@earthlink.net> <4EFA54FF.1080307@earthlink.net> In-Reply-To: <4EFA54FF.1080307@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2012-01/txt/msg00028.txt.bz2 On 12/27/2011 11:30 PM, Stan Shebs wrote: > On 12/26/11 10:29 PM, Eli Zaretskii wrote: > >> Date: Mon, 26 Dec 2011 20:28:43 -0800 From: Stan > >> Shebs > >> > >> Here is a third revision of the 'info os' additions for Linux; > >> it rolls up Kwok's original patch plus requested edits, plus a > >> few more comments and tweaks. I plan to commit this in a day or > >> so, if there are no objections. > > I already voiced an objection the first time: I think > > Linux-specific OS information doesn't belong to "info os", which > > should be for commands generally available on all supported > > systems. I would support an "info linux" command for what you > > want here. > > > > Yeah, I see that went by without comment at the time, but it's a > fair point. > > I think the answer is that there would be few if any "info os" > subcommands that would be genuinely common to all operating systems > that GDB supports; embedded OSes may not even have a well-defined > concept of processes. On the other hand, one could argue that > anything that is not totally general should be given a OS-specific > subcommand, a la "info dos". > > For my part, I would tend to favor "info os" for those kinds of data > that are generic enough to be found on more than one target OS. > Things like processes, semaphores, and sockets are found across a > broad range of systems large and small, and it seems unduly pedantic > to require users to do "info linux semaphores" when targeting Linux, > but "info bsd sem" for BSD - or worse, "info freebsd sem" vs "info > openbsd sem" - and which flavor of BSD is Darwin most like, again? > :-) Putting things under "info os" means less detail for users to > remember. The idea of "info os" is to leave GDB completely agnostic of what is it the backend decides to present to the user/frontend. GDB only knows that it is being given a table with columns and lines. We should not assume that "info os FOO" means the same thing on different OSs. FOO in "info os FOO" is completely not standardized. We're already suffering somewhat from one bit in gdb (MI) that is assuming it is (Mentor is working on a target where "info os processes" would make much more sense to display its own concept of "processes", but MI uses "info os processes" for -list-thread-groups.) If we want to have standard classes of objects, and assume some concepts and fields are present, we should put those objects in some namespace, so that GDB can give them special treatment, like with target description features. E.g., something like "org.gdb.mutex", "org.gdb.sem", etc. It may be important to this discussion to consider that in its present form, "info os" is more useful in its MI variant, where the frontend queries GDB for what tables does the backend expose (with "info os"), and then presents them in spreadsheet-like format, all without any hardcoding. Exposing more bits in the GNU/Linux backends serves the purpose of being the reference implementation / proof-of-concept.