From: Pedro Alves <alves.ped@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: stanshebs@earthlink.net, gdb-patches@sourceware.org
Subject: Re: [PATCH] Add extra 'info os' information types for Linux (trunk and 7.4)
Date: Mon, 02 Jan 2012 19:31:00 -0000 [thread overview]
Message-ID: <4F0205F9.2040900@gmail.com> (raw)
In-Reply-To: <E1Rhh6v-0007lW-95@fencepost.gnu.org>
On 01/02/2012 12:35 PM, Eli Zaretskii wrote:
>> Date: Mon, 02 Jan 2012 12:08:37 +0000
>> From: Pedro Alves<alves.ped@gmail.com>
>> CC: Eli Zaretskii<eliz@gnu.org>, gdb-patches@sourceware.org
>>
>> 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.
>
> As I already wrote, I have absolutely no problems with that, provided
> that we apply this logic consistently. Doing so would mean that we
> should gather all the OS-specific "info MyOS SOMETHING" under the
> single "info os" roof, and remove "info dos", "info w32", etc.
Provided those commands output tabular form data, and, have no
dependency on current inferior context (e.g., apply to the
current inferior only), then it would work. I don't think at
least "info w32" is not a good fit for that reason. "info os"
really lists info about everything (all processes, threads, etc.)
running on the target. E.g., on GNU/Linux, "info os sem" lists
all semaphores in the system, not just the current inferior's.
Also, "info os" is not 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".
--
Pedro Alves
next prev parent reply other threads:[~2012-01-02 19:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-12 18:29 [PATCH] Add extra 'info os' information types for Linux Kwok Cheung Yeung
2011-10-21 23:38 ` Tom Tromey
2011-11-23 18:00 ` Kwok Cheung Yeung
2011-12-27 4:56 ` [PATCH] Add extra 'info os' information types for Linux (trunk and 7.4) Stan Shebs
2011-12-27 9:32 ` Eli Zaretskii
2011-12-27 21:30 ` Mark Kettenis
2011-12-27 23:23 ` Eli Zaretskii
2011-12-28 20:48 ` Mark Kettenis
2011-12-28 0:05 ` Stan Shebs
2011-12-28 3:51 ` Joel Brobecker
2011-12-28 6:02 ` Eli Zaretskii
2012-01-02 12:08 ` Pedro Alves
2012-01-02 12:35 ` Eli Zaretskii
2012-01-02 19:31 ` Pedro Alves [this message]
2012-01-03 3:05 ` Joel Brobecker
2012-01-02 18:15 ` Doug Evans
2012-01-02 19:19 ` Pedro Alves
2012-01-02 19:41 ` Tom Tromey
2011-12-29 20:34 ` Doug Evans
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F0205F9.2040900@gmail.com \
--to=alves.ped@gmail.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=stanshebs@earthlink.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox