From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30765 invoked by alias); 11 May 2012 20:25:24 -0000 Received: (qmail 30740 invoked by uid 22791); 11 May 2012 20:25:22 -0000 X-SWARE-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from imr3.ericy.com (HELO imr3.ericy.com) (198.24.6.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 11 May 2012 20:24:55 +0000 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q4BKOoUg031508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 May 2012 15:24:51 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.69]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 11 May 2012 16:24:49 -0400 From: Marc Khouzam To: "'Stan Shebs'" , "'gdb-patches@sourceware.org'" , "'Pedro Alves'" Date: Fri, 11 May 2012 20:25:00 -0000 Subject: RE: 'info os' additions again Message-ID: References: <4FA9A2FA.3090307@earthlink.net> <83k40m0xqt.fsf@gnu.org> <4FAADEBE.7010908@earthlink.net> <83pqaczk9u.fsf@gnu.org> <4FABB2DC.6030905@redhat.com> <4FAC051C.1090208@earthlink.net> In-Reply-To: <4FAC051C.1090208@earthlink.net> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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-05/txt/msg00448.txt.bz2 > -----Original Message----- > From: gdb-patches-owner@sourceware.org=20 > [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Stan Shebs > Sent: Thursday, May 10, 2012 2:13 PM > To: gdb-patches@sourceware.org > Subject: Re: 'info os' additions again >=20 > On 5/10/12 5:21 AM, Pedro Alves wrote: > > 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=20 > same-but-differentness of the Unix > >>> family. I myself have my right hand on a Macbook and=20 > left hand on a > >>> Dell running Linux, and so if I'm sticking to Posix API,=20 > 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=20 > target-specific > >> XML file, so it could be anything. > > > > [...] > > > > It is more useful to consider its MI variant (has it been=20 > contributed yet? I thought > > it had, but I can't see it now), where the frontend queries=20 > GDB for what tables does > > the backend expose (with the MI version of a plain "info=20 > os", which returns > > a table with the list of supported objects), and then=20 > presents them in > > spreadsheet-like format, all without any target-knowledge=20 > hard coding. This is exactly what we're hoping for in Eclipse. So: - ask GDB what tables are available (-info-os without args, I gather) - use that result to list the choice to the user - when the user selects a table, Eclipse asks GDB for the data, and displays it pretty much verbatim. As Pedro points out, this would be future-proof, and any new table could be added without changing Eclipse. Furthermore, to fit well with Eclipse, which has very little OS-specific code, GDB would report the list of available tables based on the OS of the target; Eclipse would not need to consider what that OS is. So, maybe on Windows Eclipse gets a empty table list, or very few tables, while on Linux it gets many more. Either way, Eclipse blindly displays what GDB says is available. At least that is what we were hoping for. I hope that is possible. Thanks for the efforts! Marc > > Exposing > > more GNU/Linux objects through the mechanism in the=20 > GNU/Linux backends serves > > the purpose of being the reference implementation /=20 > proof-of-concept. Vladimir worked > > on an Eclipse plugin that made use of all this, and it was=20 > in the progress > > of being pushed to Eclipse upstream last I heard of it.=20=20 > I'm not aware of its > > current status. >=20 > They're waiting for the GDB bits (including the MI patch=20 > which is in my=20 > queue) to become available, which is why I want to get this=20 > resolved one=20 > way or another. It's a little ironic that Eclipse folks, who=20 > don't care=20 > about command-line syntax, are being blocked on a discussion of=20 > command-line syntax. :-) >=20 > If everybody is tired of the issue, I'll just make a decision; things=20 > can always be changed later. >=20 > Stan >=20 >=20