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


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





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