From: Andrew Burgess <aburgess@redhat.com>
To: Guinevere Larsen <guinevere@redhat.com>, gdb-patches@sourceware.org
Cc: Guinevere Larsen <guinevere@redhat.com>,
Ciaran Woodward <ciaranwoodward@xmos.com>,
Tom Tromey <tom@tromey.com>
Subject: Re: [PATCH v5 2/2] gdb: Improve warning when no native target is available
Date: Tue, 17 Mar 2026 11:29:51 +0000 [thread overview]
Message-ID: <87ecli7ky8.fsf@redhat.com> (raw)
In-Reply-To: <20260310142323.2619350-4-guinevere@redhat.com>
I see you already go an approval for this patch, so take all of the
below with a huge pinch of salt. I really don't want to spend forever
painting the bike shed. Given the niche that this patch is addressing I
don't really care if it goes in or not. That said...
Guinevere Larsen <guinevere@redhat.com> writes:
> Currently, if a user attempts to debug a program without access to a
> native debugger, the error message will just be:
>
> Don't know how to <command>. try "help target"
I think you must have written this by hand, it would actually be:
Don't know how to <command>. Try "help target".
>
> This message is too generic, and doesn't help a user without internal
> knowledge of GDB.
Disagree with this assessment. I don't see what internal knowledge is
required to grok this error message. I'd rewrite the second sentence so
we had:
Don't know how to <command>. Use "help target" for more details.
Or some such. But this is clear, and gives guidance on what to do next
to resolve the issue (run the help command).
> The present commit changes that message to be more informative for a
> user who is unfamiliar with GDB and installed it in an unsupported
> system, such as in a mac with M-series chips.
When making a change like this I usually include my improved output in
the commit message.
>
> Reviewed-By: Ciaran Woodward <ciaranwoodward@xmos.com>
> Approved-By: Tom Tromey <tom@tromey.com>
> ---
> gdb/inf-child.c | 7 ++++++-
> gdb/target.c | 5 ++++-
> gdb/testsuite/gdb.base/auto-connect-native-target.exp | 6 ++++--
> 3 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/gdb/inf-child.c b/gdb/inf-child.c
> index 7983ecb0d92..ae2cadc5e2b 100644
> --- a/gdb/inf-child.c
> +++ b/gdb/inf-child.c
> @@ -42,7 +42,12 @@
> static const target_info inf_child_target_info = {
> "native",
> N_("Native process"),
> - N_("Native process (started by the \"run\" command).")
> + N_("Native process.\n\
> +\n\
> +This gives GDB the ability to control the execution of binaries in the\n\
> +current CPU architecture. It is installed automatically when you attempt\n\
> +to \"run\" or \"start\" a program, if the CPU architecure is supported by\n\
> +GDB.")
The second sentence isn't totally correct here. At least, if I
understand things correctly. The native target is automatically
selected when the user tries to start an inferior that has no other
target selected. Using 'target remote ...' is going to prevent 'run' or
'start' from working as that target doesn't support these commands. Or
'target extended-remote' or 'target sim' that do support 'run' and
'start' are going to service these commands themselves.
Maybe this is all being too picky, but this text isn't part of an error
message that needs to be kept short. This is the "help target native"
text, so I'm inclined to think that we should favour correctness over
simplicity.
Also, by reducing the first line of the help from "Native process
(started by the \"run\" command)." to just "Native process." this
reduces what is show for 'help target'. I agree with the idea of
dropping the mention of 'run' here, but what about something like
"Control native processes of this computer."? I worried about the work
"computer" here, my first instinct was to write "host", but I worried
that might not be super clear.
> };
>
> const target_info &
> diff --git a/gdb/target.c b/gdb/target.c
> index 77a562aa919..6fc1872685f 100644
> --- a/gdb/target.c
> +++ b/gdb/target.c
> @@ -2899,7 +2899,10 @@ find_default_run_target (const char *do_mesg)
> return the_native_target;
>
> if (do_mesg != NULL)
> - error (_("Don't know how to %s. Try \"help target\"."), do_mesg);
> + error (_("\
> +No native target available, unable to %s. Try \"help target native\".\n\
> +This may be because your CPU architecture is not supported, use\n\
> +\"help set architecture\" for a list of supported architectures."), do_mesg);
If you rebuild GDB without a native target then 'help target native'
will print:
(gdb) help target native
Undefined target command: "native". Try "help target".
Which I guess does redirect the user, but isn't ideal. You probably
need to stick to suggesting 'help target' here.
I feel like I might have said this on an earlier revision of the patch,
but I guess it wasn't the direction you wanted to go. I'll say it again
anyway, because every time I look at this patch I have the exact same
though: I think the original error message is fine, it's short and to
the point. I think that improving the help text for _both_ 'help
target' and 'help target native' would be a better solution to the
problem you have. If a user sees this error and _doesn't_ immediately
try 'help target' then I have very limited sympathy for their confusion,
assuming of course, that 'help target' actually explains what they need
to know. Which is probably doesn't right now.
Another thought that this change inspires, but definitely not something
for you to do here is this: I've long thought we should make our error
objects better, allowing for two strings to be carried around. A single
line ( < 80 characters ) short summary of the error. Then an optional,
multi-line help text style description of the error and how it could be
resolved. Obviously not every (or many) errors will actually need the
second string, but errors like this, that are triggered directly, or
almost directly, from user input, often benefit from an extended, "this
is what you did wrong, and this is how you should fix it" text. The
problem this solves (I think) is that multi-line error messages just
don't format that well. But this is a future problem I think.
Thanks,
Andrew
> return NULL;
> }
>
> diff --git a/gdb/testsuite/gdb.base/auto-connect-native-target.exp b/gdb/testsuite/gdb.base/auto-connect-native-target.exp
> index 26434396cc6..65696f0167c 100644
> --- a/gdb/testsuite/gdb.base/auto-connect-native-target.exp
> +++ b/gdb/testsuite/gdb.base/auto-connect-native-target.exp
> @@ -105,7 +105,8 @@ kill_program "kill"
> gdb_test_no_output "set auto-connect-native-target off"
>
> # Commands that rely on the native target auto-connecting should no longer work.
> -gdb_test "start" "Don't know how to run.*" "start no longer works"
> +gdb_test "start" "No native target available, unable to run.*" \
> + "start no longer works"
>
> # Explicitly connect to the native target.
> gdb_test "target native" \
> @@ -181,7 +182,8 @@ with_test_prefix "disconnect" {
> fail $test
> }
>
> - gdb_test "start" "Don't know how to run.*" "start no longer works"
> + gdb_test "start" "No native target available, unable to run.*" \
> + "start no longer works"
> }
>
> # Reenable auto-connecting to the native target. Plain "start" should
> --
> 2.53.0
prev parent reply other threads:[~2026-03-17 11:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-10 14:23 [PATCH v5 0/2] Add warning if the native target is not supported Guinevere Larsen
2026-03-10 14:23 ` [PATCH v5 1/2] gdb: improve help text for set commands with limited options Guinevere Larsen
2026-03-17 13:58 ` Andrew Burgess
2026-04-16 18:17 ` Guinevere Larsen
2026-03-10 14:23 ` [PATCH v5 2/2] gdb: Improve warning when no native target is available Guinevere Larsen
2026-03-17 11:29 ` Andrew Burgess [this message]
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=87ecli7ky8.fsf@redhat.com \
--to=aburgess@redhat.com \
--cc=ciaranwoodward@xmos.com \
--cc=gdb-patches@sourceware.org \
--cc=guinevere@redhat.com \
--cc=tom@tromey.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