From: Eli Zaretskii <eliz@gnu.org>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC PATCH] Allow disabling the default run target.
Date: Fri, 14 Mar 2014 11:47:00 -0000 [thread overview]
Message-ID: <83d2hpc88v.fsf@gnu.org> (raw)
In-Reply-To: <5322E2B8.8080808@redhat.com>
> Date: Fri, 14 Mar 2014 11:06:32 +0000
> From: Pedro Alves <palves@redhat.com>
> CC: gdb-patches@sourceware.org
>
> 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?
"target child" itself, and then the apparent disconnect between that
and the option name, although NEWS says that "'target child' [...]
connects to the default run target". Also, the fact that setting
default-run-target to OFF actually _enables_ something (AFAIU).
> 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".
"target native" is a much better name, IMO.
> Not sure whether djgpp even supports remote debugging
AFAIK, it does, see ser-go32.c. But if you meant remote debugging of
DJGPP programs, then no, this isn't supported, since gdbserver
doesn't, and there's no other stub that could do that instead.
> I'd suggest just removing go32_open, and letting inf-child.c's
> to_open handle pushing the target.
Fine with me. I don't think "target djgpp" was ever important anyway,
I think it's there mostly for completeness.
> 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").
Maybe we should take a step back and discuss why this fallback is
useful. Is it only so native debugging works by default without a
need to say "target native"?
next prev parent reply other threads:[~2014-03-14 11:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-13 19:02 Pedro Alves
2014-03-13 20:17 ` Eli Zaretskii
2014-03-14 11:06 ` Pedro Alves
2014-03-14 11:47 ` Eli Zaretskii [this message]
2014-03-14 12:16 ` Pedro Alves
2014-03-14 13:27 ` Pedro Alves
2014-03-14 14:39 ` Eli Zaretskii
2014-03-14 8:01 ` Joel Brobecker
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=83d2hpc88v.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/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