From: Andrew Burgess <aburgess@redhat.com>
To: Tom de Vries <tdevries@suse.de>, gdb-patches@sourceware.org
Subject: Re: [PATCH v2 1/2] [gdb/testsuite] Simplify core_find
Date: Tue, 29 Sep 2026 09:25:55 +0100 [thread overview]
Message-ID: <875wzo1n1o.fsf@redhat.com> (raw)
In-Reply-To: <20260927054254.1986148-2-tdevries@suse.de>
Tom de Vries <tdevries@suse.de> writes:
> In proc core_find we have:
> ...
> catch "system \"(cd ${coredir}; ulimit -c unlimited; $coredump_filter_cmd; ${binfile} ${arg}; true) >${output_file} 2>&1\""
> ...
>
> We can rewrite this into something more readable with less quote and escape
> magic:
I'm not opposed to this change, but I don't understand the motivation.
Is the "magic" to which you refer the \" ? Or maybe you getting ahead
of yourself and referencing the change in
gdb.base/corefile-exec-context.exp, which does seem like a nice
cleanup. To me, the original core_find code was clearer, but the extra
complexity seems worth if for the improvements possible in the test
scripts.
> ...
> set arg [subst -nocommands -novariables $arg]
> set cmd [subst_vars {
> (cd ${coredir};
> ulimit -c unlimited;
> $coredump_filter_cmd;
> ${binfile} ${arg};
> true) \
> >${output_file} 2>&1}]
> catch {
> system $cmd
> }
> ...
>
> The "set arg [subst ... $arg]" is a bit awkward, and dropping it allows us to
> update test-case gdb.base/corefile-exec-context.exp to use a bit more typical
> setup with string_to_regex.
typo: string_to_regex -> string_to_regexp
Thd discussion of "set arg [subst ... $arg]" confusing. You introduce
it, then say it's dropped, but never explain why it was introduced, you
just assume the reason is self-evident. It's not. At least, not to
me. I think you should probably just remove that line and explain why
the new code is better -- this would be great as others (me) could read
your commit and learn from it.
>
> Note that what is being tested hasn't changed.
>
> We can print the effective value of arg by adding to the command passed to
> system. Without this patch using:
> ...
> echo \\\"$arg\\\;
> ...
> and with this patch using:
> ...
> echo "$arg";
> ...
> and in both cases we get:
> ...
> aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e
> ...
> ---
> .../gdb.base/corefile-exec-context.exp | 13 +++++++---
> gdb/testsuite/lib/gdb.exp | 26 ++++++++++++++++---
> 2 files changed, 31 insertions(+), 8 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.base/corefile-exec-context.exp b/gdb/testsuite/gdb.base/corefile-exec-context.exp
> index 9b018533b68..56c68a6a5cd 100644
> --- a/gdb/testsuite/gdb.base/corefile-exec-context.exp
> +++ b/gdb/testsuite/gdb.base/corefile-exec-context.exp
> @@ -69,7 +69,7 @@ gdb_test_multiple "core-file $corefile_1" "load core file no args" {
> }
>
> # Generate a core file, this time pass some arguments to the inferior.
> -set args "aaaaa bbbbb ccccc ddddd e\\\\ e\\\\ e\\\\ e\\\\ e"
> +set args {aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e}
> set corefile [core_find $binfile {} $args]
> if {$corefile == ""} {
> untested "unable to create corefile"
> @@ -82,8 +82,11 @@ remote_exec build "mv $corefile $corefile_2"
> # argument list are seen.
> clean_restart $testfile
> set saw_generated_line false
> +set re_args [string_to_regexp $args]
> +set re_cmd "[string_to_regexp $binfile] $re_args"
> +set re_line [subst_vars {^Core was generated by `$re_cmd'\.\r\n}]
> gdb_test_multiple "core-file $corefile_2" "load core file with args" {
> - -re "^Core was generated by `[string_to_regexp $binfile] $args'\\.\r\n" {
> + -re $re_line {
> set saw_generated_line true
> exp_continue
> }
> @@ -99,7 +102,8 @@ gdb_test_multiple "core-file $corefile_2" "load core file with args" {
>
> # Also, the argument list should be available through 'show args'.
> gdb_test "show args" \
> - "Argument list to give program being debugged when it is started is \"$args\"\\."
> + [subst_vars \
> + {Argument list to give program being debugged when it is started is "$re_args"\.}]
>
> # Move up to 'main'. Do it this way because we cannot know how many
> # frames up 'main' actually is.
> @@ -178,8 +182,9 @@ proc check_for_env_var { var_name var_value } {
> gdb_assert { ![check_for_env_var $env_var_name $env_var_value] } \
> "environment variable is not set before core file load"
>
> +set re_cmd "[string_to_regexp $binfile] $re_args"
I don't think this line is needed. Has RE_CMD changed since it was
first computed? I don't think BINFILE has, and RE_ARGS is new, and only
computed the once above. If this line is necessary then maybe a comment
explaining why would be good.
Thank,
Andrew
> gdb_test "core-file $corefile_3" \
> - "Core was generated by `[string_to_regexp $binfile] $args'\\.\r\n.*" \
> + [subst_vars {Core was generated by `$re_cmd'\.\r\n.*}] \
> "load core file for environment test"
>
> gdb_assert { [check_for_env_var $env_var_name $env_var_value] } \
> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index 9ade9a16818..2cfdbdda09d 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -10312,8 +10312,18 @@ proc core_find {binfile {deletefiles {}} {arg ""} {output_file "/dev/null"}} {
> }
> }
>
> - # tclint-disable command-args
> - catch "system \"(cd ${coredir}; ulimit -c unlimited; $coredump_filter_cmd; ${binfile} ${arg}; true) >${output_file} 2>&1\""
> + set cmd [subst_vars {
> + (cd ${coredir};
> + ulimit -c unlimited;
> + $coredump_filter_cmd;
> + ${binfile} ${arg};
> + true) \
> + >${output_file} 2>&1}]
> + verbose -log "Executing on build: $cmd"
> + catch {
> + system $cmd
> + }
> +
> # remote_exec host "${binfile}"
> set binfile_basename [file tail $binfile]
> foreach i [list \
> @@ -10343,8 +10353,16 @@ proc core_find {binfile {deletefiles {}} {arg ""} {output_file "/dev/null"}} {
> # ulimit here if we didn't find a core file above.
> # Oh, I should mention that any "braindamaged" non-Unix system has
> # the same problem. I like the cd bit too, it's really neat'n stuff.
> - # tclint-disable command-args
> - catch "system \"(cd ${objdir}/${subdir}; ${binfile}; true) >/dev/null 2>&1\""
> + set cmd [subst_vars {
> + (cd ${objdir}/${subdir};
> + ${binfile};
> + true) \
> + >/dev/null 2>&1}]
> + verbose -log "Executing on build: $cmd"
> + catch {
> + system $cmd
> + }
> +
> foreach i "${objdir}/${subdir}/core ${objdir}/${subdir}/core.coremaker.c ${binfile}.core" {
> if {[remote_file build exists $i]} {
> remote_exec build "mv $i $destcore"
> --
> 2.51.0
next prev parent reply other threads:[~2026-09-29 8:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-27 5:42 [PATCH v2 0/2] [gdb/testsuite] Use try instead of catch Tom de Vries
2026-09-27 5:42 ` [PATCH v2 1/2] [gdb/testsuite] Simplify core_find Tom de Vries
2026-09-29 8:25 ` Andrew Burgess [this message]
2026-09-27 5:42 ` [PATCH v2 2/2] [gdb/testsuite] Use try instead of catch Tom de Vries
2026-09-29 8:40 ` Andrew Burgess
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=875wzo1n1o.fsf@redhat.com \
--to=aburgess@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=tdevries@suse.de \
/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