This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: 'info os' additions again


> -----Original Message-----
> From: gdb-patches-owner@sourceware.org 
> [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
> 
> 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<stanshebs@earthlink.net>
> >>> 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.
> >
> > [...]
> >
> > 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.

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 
> 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.
> 
> They're waiting for the GDB bits (including the MI patch 
> which is in my 
> queue) to become available, which is why I want to get this 
> resolved one 
> way or another.  It's a little ironic that Eclipse folks, who 
> don't care 
> about command-line syntax, are being blocked on a discussion of 
> command-line syntax. :-)
> 
> If everybody is tired of the issue, I'll just make a decision; things 
> can always be changed later.
> 
> Stan
> 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]