[RFC PATCH] Allow disabling the default run target.

[Pedro Alves]

On 03/13/2014 08:16 PM, Eli Zaretskii wrote:
>> From: Pedro Alves <palves@redhat.com>
>> Date: Thu, 13 Mar 2014 19:02:48 +0000
>>
>> Wonder what people think of this.
> 
> FWIW, the names of commands and options confused me a lot.

Thanks Eli.  I battled with several different namings, and
all the others seemed worse.  :-)  But I do think we should
try to come up with something better -- always a bad sign
to me when a GDB maintainer is confused.  Probably users
will be even more.

Can you point out specifically what confused you?

I've been pondering renaming "target child" to something else.
"child" is a little lie in case of "attach".
By best suggestion so far is "target native".  I worry a little
that "native" might be a lie too if some port comes up with
a default target that can run but is not really native.  But
I think that's a very minor issue, we can consider that native
means the default built in target that gdb supports, instead of
saying that's the target that debugs host native processes.

BTW, not all native targets are called "child" yet.  djgpp is
one that isn't (it's "target djgpp").  Would you mind if that
target's name was changed?  Hmm, I now see that go32-nat.c
implements a to_open hook:

static void
go32_open (char *name, int from_tty)
{
  printf_unfiltered ("Done.  Use the \"run\" command to run the program.\n");
}

It says "Done", kind of implying that has connected to the
target, but it really hasn't, since a push_target call is
missing.   Given this prints instead of erroring out like
"target child" does currently (and with a similar message), it looks
like "target djgpp"'s ends up having a similar effect my patch has
(expect it doesn't make sure the target stays connected after the
program exits).  (Not sure whether djgpp even supports remote
debugging, or who would want to use it that way, so I don't see
the point of "target djgpp" as is today).  If my patch goes in,
I'd suggest just removing go32_open, and letting inf-child.c's
to_open handle pushing the target.

For the toggle option itself, I considered putting "enable" in the name:

 set enable-default-run-target

But disabling this isn't really disabling the target, only
the falling back is disabled.  Adding "fallback" and/to "to"
seems to help.  Like:

 set enable-fallback-to-default-run-target
 set enable-fallback-default-run-target
 set fallback-to-default-run-target
 set fallback-default-run-target

Seemed a little too long, so I ended up dropping the "fallback".
Dunno, maybe tab completion makes that a non-issue.

Assuming using "native" instead would be OK, I think we could
dispense with "default", like:

 set enable-fallback-to-native-target
 set enable-fallback-native-target
 set fallback-to-native-target
 set fallback-native-target
 set native-target-fallback

(and then "target child" renamed to "target native").

> 
>> +By default, if not connected to any target yet (e.g., with
>> +@code{target remote}), the @code{run} command starts your program
>> +under @value{GDBN}, on your local machine.  When you're sure you don't
>                                                ^^^^
> I think you meant "If", not "When".
> 
>> +In case you connected explicitly to the @code{target child} target,
>                                                  ^^^^^^^^^^^^^^^^^^^^
> This doesn't look right.
> 
> The rest of the docs parts look OK to me.

Thanks, I've fixed these locally.

-- 
Pedro Alves