From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31359 invoked by alias); 10 May 2012 12:22:13 -0000 Received: (qmail 31347 invoked by uid 22791); 10 May 2012 12:22:09 -0000 X-SWARE-Spam-Status: No, hits=-7.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 10 May 2012 12:21:54 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4ACLn4T028437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 08:21:50 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q4ACLmlI010811; Thu, 10 May 2012 08:21:48 -0400 Message-ID: <4FABB2DC.6030905@redhat.com> Date: Thu, 10 May 2012 12:22:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Eli Zaretskii CC: Stan Shebs , gdb-patches@sourceware.org Subject: Re: 'info os' additions again References: <4FA9A2FA.3090307@earthlink.net> <83k40m0xqt.fsf@gnu.org> <4FAADEBE.7010908@earthlink.net> <83pqaczk9u.fsf@gnu.org> In-Reply-To: <83pqaczk9u.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-05/txt/msg00334.txt.bz2 On 05/10/2012 06:18 AM, Eli Zaretskii wrote: >> Date: Wed, 09 May 2012 14:16:46 -0700 >> From: Stan Shebs >> CC: gdb-patches@sourceware.org >> >>> FWIW, I never understood the reason why others prefer "info os". >> >> I'm sure a lot of it comes from the same-but-differentness of the Unix >> family. I myself have my right hand on a Macbook and left hand on a >> Dell running Linux, and so if I'm sticking to Posix API, I want GDB to >> work the same on the two. > > Can you show the "same but different" sub-commands we have now? > > What I see in osdata.c is that the info comes from a target-specific > XML file, so it could be anything. Yes, we've been through this discussion before. http://sourceware.org/ml/gdb-patches/2012-01/msg00028.html Restating here, much tweaked: 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. "info os" was introduced really as a generic "OS awareness" mechanism. "OS awareness" is a slang term that (contrary to what one might expect" means that GDB doesn't have backed in any knowledge of the OS the target is running, but yet, is able to expose info about OS specific objects for the user. Imagine remote debugging your custom RTOS with a generic --target=arm-eabi GDB, and wanting to list info about tasks, locks, and a multitude of random other objects in your target. "info os" provides that mechanism. It is more useful to consider its MI variant (has it been contributed yet? I thought it had, but I can't see it now), where the frontend queries GDB for what tables does the backend expose (with the MI version of a plain "info os", which returns a table with the list of supported objects), and then presents them in spreadsheet-like format, all without any target-knowledge hard coding. Exposing more GNU/Linux objects through the mechanism in the GNU/Linux backends serves the purpose of being the reference implementation / proof-of-concept. Vladimir worked on an Eclipse plugin that made use of all this, and it was in the progress of being pushed to Eclipse upstream last I heard of it. I'm not aware of its current status. Further in the previous discussion you pointed out that we should apply this logic consistently (to other targets/oss), by putting the current "info MyOS SOMETHING" under the single "info os" roof, removing "info dos", "info w32", etc. But I've also pointed out back that that could only fit those cases where the commands output tabular form data, and, have _no_ dependency on current inferior context (e.g., apply to the current inferior only). At least "info w32" is not a good fit for that reason, as it works with the current inferior. "info os" is really meant for listing info about everything (all processes, threads, etc.) running on the target at once. E.g., on GNU/Linux, "info os sem" lists all semaphores in the system, not just the current inferior's. There was also the point about "info os" not being a full replacement for a hard coded command today. E.g., we'd lose the specific online help for those commands' and their sub-fields, given the generality of "info os". So we could expose the objects that "info dos" and "info w32" exposes through the "info os" mechanism, do frontends display them in the same agnostic way they'll display the GNU/Linux bits. But that wouldn't be an exact match for the functionality those existing commands provide. Rather, it would be parallel functionality. As summary, don't get bogged up on the "info os" command itself. Consider that patch that added more GNU/Linux bits to "info os" as exposing more bits to the frontend through the generic OS-data table machinery. -- Pedro Alves