Re: 'info os' additions again

[Pedro Alves <palves@redhat.com>]

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