Re: [PATCH]: add set/show debug, move gdb debugging flags into it

[dan at cgsoftware dot com (Daniel Berlin+list.gdb-patches)]

Eli Zaretskii <eliz@delorie.com> writes:

> > I'm perfectly willing to document them, but personally, i don't think
> > they *should* be documented.
> 
> I cannot disagree more.  I think there should be no undocumented
> commands.  There are at least two good reasons for that:
> 
>   - You never know how useful can a command turn out to be, for
>     someone, somewhere.  What you devise as the sneakiest, dirtiest,
>     for-wizards-only trick, might well enough turn out to be the
>     hottest feature on the block, if someone finds a creative way to
>     use it in some situations.

That's not necessarily a good thing, but i see your point.

> 
>   - We, the maintainers of GDB, need a quick way of finding out about
>     the debugging features when we need them.  GDB is a very large
>     program, and it's unreasonable to expect every maintainer to know
>     every command on every architecture.  And new maintainers are
>     joining the ranks from time to time.

Right, and most understand enough about how gdb works to look at the
output of "help set debug", and know what each command does.
> 
> > In general, with those debug commands, if you can't figure out what
> > they do based on the one sentence docstring, you shouldn't be touching
> > them.
> 
> There's no efficient means in GDB to search the available commands
> using the doc strings.  There's nothing like Emacs' apropos or finder
> commands (or at least I don't know about them--perhaps they are
> undocumented ;-).  Heck, the "help" command doesn't even
> auto-complete!


I'll give you that.
Maybe i'll work on a patch to add apropos while i'm at it.

> 
> This makes the manual the only way to find about commands pertinent to
> a given subject (assuming it's indexed appropriately).

To be honest, i've never used the manual once.
Maybe i'm just odd, i'm willing to accept that i'm a special case.

> 
> > It's hard to say more about what "target debugging" is, except that it
> > enables printing of target debug info.
> 
> Give a couple of examples.  Show sample output.  Describe one or two
> cases where you'd need such a command. 

You wouldn't need it (target debugging) unless you were porting gdb to a new
architecture.
Also, it's impossible for me to produce output for some of the
commands, like remote debugging, arch debugging, etc, because they
enable debugging output for things that my platform doesn't use.


> (After all, you worked on it
> because you needed to use it, right?)  T

Actually, no.
Andrew marked my "#ifdef DEBUG_OVERLOAD" as "not the way to do it",
saying that i should add a "set debug" command for debugging
overloading, but that "set debug" didn't exist yet, of course.

So i made "set debug".
:)

I've used target debugging quite a bit when porting to BeOS, but
haven't used it personally in a few months now.

I noticed it the second i looked at target.h to see what the structure
for target_ops was.

> This is usually enough info,
> since we are talking about commands for GDB maintainers.

Okeydokey, i'll give it a shot.
> 
> > They shouldn't find out they exist, unless specifically instructed by
> > someone.
> 
> Who would that someone be?  I don't have anyone to instruct me how to
> debug GDB, and I don't think the good-willing people here have enough
> time to do that.  I only have the manual, the sources, Grep and
> etags.
> 
> In any case, IMHO using the docs locally is a much more efficient way
> of solving problems than asking on the net.