'info os' additions again

'info os' additions again

[Stan Shebs]

Back in December and January, we had some spirited discussion of how to 
handle additions to 'info os', triggered by 
http://sourceware.org/ml/gdb-patches/2011-12/msg00829.html , which adds 
a bunch of useful info types for Linux.  Anyway, upon rereading the 
thread, I'm not at all clear on where there was consensus, and if so, 
what the consensus was.

 From what I gather, nobody has much of a problem with GDB gathering and 
presenting the info; by passing it through GDB, we can replace raw 
numbers with symbols, get it into history, add to breakpoint command 
lists, etc.

The main sticking point seems to be syntax.

I tend to favor "info os <type> <subtype>..." because it fits the 
progressive refinement that is a hallmark of GDB commands - the user can 
remember it as "info, and it's OS-related, but I just want semaphores".  
The user doesn't have to consider what OS name might be expected, "os" 
always works to connect to the class of OS-specific info displays.

However, we also have an alternate tradition of "info <target> 
<type>...", including "info dos", "info w32", "info spu", etc.  By that 
tradition, Linux-specific info should be "info linux", and if there were 
BSD OS info, it would be "info bsd", and so forth.  It's simpler to 
document, because the manual can just have a section for each subcommand 
that enumerates the subsubcommands that are available.  Unfortunately 
for consistency, we've also had "info os" for several years.

So there are several questions at hand:

1. What to do with the submitted patch?  ("info os" or "info linux" or 
something else)

2. What policy to set for the future?

3. Change existing info commands to conform to a policy, or allow 
inconsistencies for the sake of backward compatibility?

Stan

Re: 'info os' additions again

[Joel Brobecker]

> 1. What to do with the submitted patch?  ("info os" or "info linux"
> or something else)
> 
> 2. What policy to set for the future?

It's kind of hard for me to feel confident in a general comment
without having really looked at the discussion, but generally
speaking, I tend to favor per-feature command rather than per-
platform commands. I'm sure some features are going to be very
obviously specific to some targets, and it might make sense
in those cases to use target-specific commands, but I would tend
to go with per-feature command, possibly with a way to ask the
debugger whether the feature is available or not.

> 3. Change existing info commands to conform to a policy, or allow
> inconsistencies for the sake of backward compatibility?

I think compatibility is important.  We might want to transition
the current commands in terms of the implementation, but we will
probably need to keep the old commands around for a while, possibly
as aliases. We could also consider progressive deprecation, with
a grace period during which the use of the command triggers a warning
with a note mentioning the new command that replaces the deprecated
one.

-- 
Joel

Re: 'info os' additions again

[Eli Zaretskii]

> Date: Tue, 08 May 2012 15:49:30 -0700
> From: Stan Shebs <stanshebs@earthlink.net>
> 
> I tend to favor "info os <type> <subtype>..." because it fits the 
> progressive refinement that is a hallmark of GDB commands - the user can 
> remember it as "info, and it's OS-related, but I just want semaphores".  
> The user doesn't have to consider what OS name might be expected, "os" 
> always works to connect to the class of OS-specific info displays.
> 
> However, we also have an alternate tradition of "info <target> 
> <type>...", including "info dos", "info w32", "info spu", etc.  By that 
> tradition, Linux-specific info should be "info linux", and if there were 
> BSD OS info, it would be "info bsd", and so forth.  It's simpler to 
> document, because the manual can just have a section for each subcommand 
> that enumerates the subsubcommands that are available.  Unfortunately 
> for consistency, we've also had "info os" for several years.

My personal take of this is that (since quite naturally, most of the
new features introduced into GDB are Linux-specific), "info os" will
rapidly become a hodgepodge of Linux-specific commands, with only a
few supported on other platforms.  At that point, "info os" will
simply be a grossly misleading name, confusing to users of other
platforms and hard to describe clearly in the documentation.

FWIW, I never understood the reason why others prefer "info os".

But I seem to be in the minority on this one, as always.

Re: 'info os' additions again

[Stan Shebs]

On 5/8/12 9:44 PM, Eli Zaretskii wrote:
>> Date: Tue, 08 May 2012 15:49:30 -0700
>> From: Stan Shebs<stanshebs@earthlink.net>
>>
>> I tend to favor "info os<type>  <subtype>..." because it fits the
>> progressive refinement that is a hallmark of GDB commands - the user can
>> remember it as "info, and it's OS-related, but I just want semaphores".
>> The user doesn't have to consider what OS name might be expected, "os"
>> always works to connect to the class of OS-specific info displays.
>>
>> However, we also have an alternate tradition of "info<target>
>> <type>...", including "info dos", "info w32", "info spu", etc.  By that
>> tradition, Linux-specific info should be "info linux", and if there were
>> BSD OS info, it would be "info bsd", and so forth.  It's simpler to
>> document, because the manual can just have a section for each subcommand
>> that enumerates the subsubcommands that are available.  Unfortunately
>> for consistency, we've also had "info os" for several years.
> My personal take of this is that (since quite naturally, most of the
> new features introduced into GDB are Linux-specific), "info os" will
> rapidly become a hodgepodge of Linux-specific commands, with only a
> few supported on other platforms.  At that point, "info os" will
> simply be a grossly misleading name, confusing to users of other
> platforms and hard to describe clearly in the documentation.

I suppose that's possible, although when originally scoping this 
particular addition, I looked over the list of OS objects and included 
everything that seemed of interest to user-space programs.  There are 
many kind of additional objects available via /proc, but they are 
control and systemwide maintenance things that have very little to do 
with debugging an app, and I'm not seeing that anyone could make a 
compelling argument that in-GDB access would be of value.

>
> 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.

Stan

Re: 'info os' additions again

[Eli Zaretskii]

> 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.

Btw, gotta love this doc string:

  (gdb) help info os
  Show OS data ARG.

Re: 'info os' additions again

[Pedro Alves]

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.


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

Re: 'info os' additions again

[Stan Shebs]

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.  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

Re: 'info os' additions again

[Pedro Alves]

On 05/10/2012 07:12 PM, Stan Shebs wrote:

> 
> 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.


What kind of decision?  What would exactly be the alternative?

-- 
Pedro Alves

Re: 'info os' additions again

[Stan Shebs]

On 5/10/12 11:18 AM, Pedro Alves wrote:
> On 05/10/2012 07:12 PM, Stan Shebs wrote:
>
>> 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.
>
> What kind of decision?  What would exactly be the alternative?
>

To pick one of "info os" and "info linux".  I don't think there are many 
other credible alternatives; the subcommand should be a single short 
word, with the rest of the work to be done by subsubcommands and/or 
arguments. "info unix" or "info posix" would qualify, but historically 
we've tended to avoid using those terms in GDB commands, and one could 
argue that they have the same vagueness/overloading issue that "os" does.

Stan

Re: 'info os' additions again

[Pedro Alves]

On 05/10/2012 07:42 PM, Stan Shebs wrote:

> On 5/10/12 11:18 AM, Pedro Alves wrote:
>> On 05/10/2012 07:12 PM, Stan Shebs wrote:
>>
>>> 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.
>>
>> What kind of decision?  What would exactly be the alternative?
>>
> 
> To pick one of "info os" and "info linux".  I don't think there are many other credible alternatives; the subcommand should be a single

> short word, with the rest of the work to be done by subsubcommands and/or arguments. "info unix" or "info posix" would qualify, but
> historically we've tended to avoid using those terms in GDB commands, and one could argue that they have the
> same vagueness/overloading issue that "os" does.

Frankly, this reads as a misunderstanding of all whole thing to me.  Just
picking out a name in isolation of the grand scheme doesn't make sense.

How would "info linux" be implemented?  How would be backend know you're
requesting linux specific data?  What would make "info linux" against a
Windows target return error or nothing, instead of returning Windows
specific tables?  What's the point in making "linux" be in the command
name if the frontend is completely agnostic, by design, to what is beneath
the command?

IOW, renaming the command means implementing something completely different.

-- 
Pedro Alves

Re: 'info os' additions again

[Stan Shebs]

On 5/10/12 11:58 AM, Pedro Alves wrote:
> On 05/10/2012 07:42 PM, Stan Shebs wrote:
>
>> On 5/10/12 11:18 AM, Pedro Alves wrote:
>>> On 05/10/2012 07:12 PM, Stan Shebs wrote:
>>>
>>>> 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.
>>> What kind of decision?  What would exactly be the alternative?
>>>
>> To pick one of "info os" and "info linux".  I don't think there are many other credible alternatives; the subcommand should be a single
>> short word, with the rest of the work to be done by subsubcommands and/or arguments. "info unix" or "info posix" would qualify, but
>> historically we've tended to avoid using those terms in GDB commands, and one could argue that they have the
>> same vagueness/overloading issue that "os" does.
> Frankly, this reads as a misunderstanding of all whole thing to me.  Just
> picking out a name in isolation of the grand scheme doesn't make sense.
>
> How would "info linux" be implemented?  How would be backend know you're
> requesting linux specific data?  What would make "info linux" against a
> Windows target return error or nothing, instead of returning Windows
> specific tables?  What's the point in making "linux" be in the command
> name if the frontend is completely agnostic, by design, to what is beneath
> the command?
>
> IOW, renaming the command means implementing something completely different.
>

Well yes, of course the implementation would be completely different.  
The original objections to the patch were to the user interface, so we 
need to agree on that first.

In practice, an "info linux" would be installed as a target-specific 
command a la "info spu" and the like, and may or may not pass through 
generic table machinery before getting down to the linux-specific 
types.  It would probably be messier than the current design I think, 
but not excessively so.

Stan

Re: 'info os' additions again

[Pedro Alves]

On 05/10/2012 10:07 PM, Stan Shebs wrote:

> On 5/10/12 11:58 AM, Pedro Alves wrote:
>> On 05/10/2012 07:42 PM, Stan Shebs wrote:
>>
>>> On 5/10/12 11:18 AM, Pedro Alves wrote:
>>>> On 05/10/2012 07:12 PM, Stan Shebs wrote:
>>>>
>>>>> 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.
>>>> What kind of decision?  What would exactly be the alternative?
>>>>
>>> To pick one of "info os" and "info linux".  I don't think there are many other credible alternatives; the subcommand should be a single
>>> short word, with the rest of the work to be done by subsubcommands and/or arguments. "info unix" or "info posix" would qualify, but
>>> historically we've tended to avoid using those terms in GDB commands, and one could argue that they have the
>>> same vagueness/overloading issue that "os" does.
>> Frankly, this reads as a misunderstanding of all whole thing to me.  Just
>> picking out a name in isolation of the grand scheme doesn't make sense.
>>
>> How would "info linux" be implemented?  How would be backend know you're
>> requesting linux specific data?  What would make "info linux" against a
>> Windows target return error or nothing, instead of returning Windows
>> specific tables?  What's the point in making "linux" be in the command
>> name if the frontend is completely agnostic, by design, to what is beneath
>> the command?
>>
>> IOW, renaming the command means implementing something completely different.
>>
> 
> Well yes, of course the implementation would be completely different.  The original objections to the patch were to the user interface, so we need to agree on that first.


For me, the main motivation for the change is to have a mechanism in the frontend
what works to display all these objects for random OSs without having to change
GDB or the frontend.  E.g,. if a Nucleus or other OS stub wants to display
some fancy table, it'll feed it to "-info-os", and things just work.
The GNU/Linux tables that are being exposed by the patch in question are
already easily available to the command line user using other mechanisms (like
e.g., ipcs).  Mostly, the patch is just a layer on top of /proc.  The real value is
in shoving them in structured form.  IOW, to me, the Elipse plugin as is, is the
real value added.
Giving up on that, and replacing it with hard coding "info linux foo",
"info linux bar whatnot" is a step backwards, IMNSHO.

> In practice, an "info linux" would be installed as a target-specific command a la "info spu"

> and the like, and may or may not pass through generic table machinery before getting
> down to the linux-specific types.  It would probably be messier than the
> current design I think, but not excessively so.

As I said, we should not assume anything about the tables "info os" returns.
If not using "info os" then it's best to either use a completely
different mechanism, or we need to define standard tables, and put them
in a namespace, like we do with xml target features.

But then again, if not going the "info os" style, we could also
consider making "info proc" list the info, or even consider each
table/object individually -- it might make sense to put different objects
at different FOOs in "info FOO OBJECT", or even in the top level,
like "info WHATEVEROBJECT".

-- 
Pedro Alves

Re: 'info os' additions again

[Matt Rice]

On Fri, May 11, 2012 at 11:06 AM, Pedro Alves <palves@redhat.com> wrote:
> On 05/10/2012 10:07 PM, Stan Shebs wrote:

>> In practice, an "info linux" would be installed as a target-specific command a la "info spu"
>
>> and the like, and may or may not pass through generic table machinery before getting
>> down to the linux-specific types.  It would probably be messier than the
>> current design I think, but not excessively so.
>
> As I said, we should not assume anything about the tables "info os" returns.
> If not using "info os" then it's best to either use a completely
> different mechanism, or we need to define standard tables, and put them
> in a namespace, like we do with xml target features.
>
> But then again, if not going the "info os" style, we could also
> consider making "info proc" list the info, or even consider each
> table/object individually -- it might make sense to put different objects
> at different FOOs in "info FOO OBJECT", or even in the top level,
> like "info WHATEVEROBJECT".

FWIW i'm entirely swayed by Pedro's argument for 'info os',
I'd been considering porting to one of the eros/capros/coyotos family
of OS's at some point
the existing (kernel) debugger has a lot of this style of tabular data:
http://www.capros.org/devel/CrossGuide/kdb-ref.html

between refining terms, and replacing ideas the word used to identify
the things of a given purpose
has been known to change between the OS's though much has stayed the same,
while this is a non-existent port and should be weighed as such, info
os seems to me the best fit proposed,

I'd hate to have a heirarchy for each with much in common under
different 'info FOOs', or inversely try to make do with a single
heirarchy for the entire family under a more specific name with
changing contents, thus at least in this specific sub case the
genericness of the 'info os' name, makes the varying of its contents
somewhat tolerable.

Re: 'info os' additions again

[Joel Brobecker]

> FWIW i'm entirely swayed by Pedro's argument for 'info os',

Yeah, I think that what Pedro suggested makes sense too.

-- 
Joel

RE: 'info os' additions again

[Marc Khouzam]

> -----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
> 
>