[3/3] gdb/record: minor clean, remove some unneeded arguments
Checks
| Context |
Check |
Description |
| linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 |
success
|
Testing passed
|
| linaro-tcwg-bot/tcwg_gdb_build--master-arm |
success
|
Testing passed
|
| linaro-tcwg-bot/tcwg_gdb_check--master-arm |
success
|
Testing passed
|
| linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 |
success
|
Testing passed
|
Commit Message
I spotted that the two functions:
record_full_open_1
record_full_core_open_1
both took two arguments, neither of which are used.
I stumbled onto this while reviewing how filename_completer is used.
The 'record full restore' command uses filename_completer and invokes
the cmd_record_full_restore function.
The cmd_record_full_restore function calls core_file_command and then
record_full_open, which then calls one of the above functions.
As 'record full restore' takes a filename, this is passed to
cmd_record_full_restore, which forwards the filename to both
core_file_command and record_full_open. However, record_full_open
never actually uses the filename that is passed in.
The record_full_open function is also used for 'target record-full'.
I propose that record_full_open should no longer expect to see any
user supplied arguments passed in (it doesn't use any). In fact, I've
added a check that if we do get any user supplied arguments we'll
throw an error.
Now that we know record_full_open isn't being passed any user
arguments we can stop passing the arguments to record_full_open_1 and
record_full_core_open_1, this will make no user visible difference as
these arguments were not used.
It is possible that a user was previously doing:
(gdb) target record-full blah blah blah
And this previously would work fine, the 'blah blah blah' was
ignored. Now this will give an error. Other than this case there
should be no user visible changes after this commit.
---
gdb/NEWS | 4 ++++
gdb/record-full.c | 15 +++++++-----
gdb/testsuite/gdb.base/record-full-error.exp | 24 ++++++++++++++++++++
3 files changed, 37 insertions(+), 6 deletions(-)
create mode 100644 gdb/testsuite/gdb.base/record-full-error.exp
Comments
> From: Andrew Burgess <aburgess@redhat.com>
> Cc: Andrew Burgess <aburgess@redhat.com>
> Date: Mon, 15 Apr 2024 15:19:28 +0100
>
> I spotted that the two functions:
>
> record_full_open_1
> record_full_core_open_1
>
> both took two arguments, neither of which are used.
>
> I stumbled onto this while reviewing how filename_completer is used.
> The 'record full restore' command uses filename_completer and invokes
> the cmd_record_full_restore function.
>
> The cmd_record_full_restore function calls core_file_command and then
> record_full_open, which then calls one of the above functions.
>
> As 'record full restore' takes a filename, this is passed to
> cmd_record_full_restore, which forwards the filename to both
> core_file_command and record_full_open. However, record_full_open
> never actually uses the filename that is passed in.
>
> The record_full_open function is also used for 'target record-full'.
>
> I propose that record_full_open should no longer expect to see any
> user supplied arguments passed in (it doesn't use any). In fact, I've
> added a check that if we do get any user supplied arguments we'll
> throw an error.
>
> Now that we know record_full_open isn't being passed any user
> arguments we can stop passing the arguments to record_full_open_1 and
> record_full_core_open_1, this will make no user visible difference as
> these arguments were not used.
>
> It is possible that a user was previously doing:
>
> (gdb) target record-full blah blah blah
>
> And this previously would work fine, the 'blah blah blah' was
> ignored. Now this will give an error. Other than this case there
> should be no user visible changes after this commit.
> ---
> gdb/NEWS | 4 ++++
> gdb/record-full.c | 15 +++++++-----
> gdb/testsuite/gdb.base/record-full-error.exp | 24 ++++++++++++++++++++
> 3 files changed, 37 insertions(+), 6 deletions(-)
> create mode 100644 gdb/testsuite/gdb.base/record-full-error.exp
OK for the NEWS part, thanks.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
On 4/15/24 07:19, Andrew Burgess wrote:
> I spotted that the two functions:
>
> record_full_open_1
> record_full_core_open_1
>
> both took two arguments, neither of which are used.
Nice catch. I've looked over this series, and I just have one really
trivial -- if not silly -- comment.
> diff --git a/gdb/record-full.c b/gdb/record-full.c
> index 4c3667f48ba..4ef85b0cdb6 100644
> --- a/gdb/record-full.c
> +++ b/gdb/record-full.c
> @@ -957,11 +957,14 @@ static void record_full_init_record_breakpoints (void);
> /* Open the process record target. */
>
> static void
> -record_full_open (const char *name, int from_tty)
> +record_full_open (const char *args, int from_tty)
> {
> if (record_debug)
> gdb_printf (gdb_stdlog, "Process record: record_full_open\n");
>
> + if (args != nullptr)
> + error (_("trailing junk: '%s'"), args);
> +
> record_preopen ();
>
> /* Reset */
While I am no fan of this type of error, I understand the motive
in terms of consistency. Grep'ping for this string in gdb gives
numerous wordings of this type of error:
ada-lang.c: error (_("Junk at end of expression"));
ada-lang.c: error (_("Junk at end of arguments."));
break-catch-exec.c: error (_("Junk at end of arguments."));
break-catch-fork.c: error (_("Junk at end of arguments."));
break-catch-throw.c: error (_("Junk at end of arguments."));
breakpoint.c: error (_("Junk at end of expression"));
breakpoint.c: error (_("Junk at end of expression"));
breakpoint.c: error (_("Junk after thread keyword."));
breakpoint.c: error (_("Junk after inferior keyword."));
breakpoint.c: error (_("Junk after task keyword."));
breakpoint.c: error (_("Junk at end of arguments."));
breakpoint.c: error (_("Junk after thread keyword."));
breakpoint.c: error (_("Junk after task keyword."));
breakpoint.c: error (_("Junk at end of command."));
breakpoint.c: error (_("Junk at end of arguments."));
breakpoint.c: error (_("Junk at end of arguments."));
btrace.c: error (_("Junk after argument: %s."), arg);
linespec.c: error (_("Junk at end of line specification: %s"), string);
linespec.c: error (_("Junk at end of line specification: %s"), string);
parse.c: error (_("Junk after end of expression."));
psymtab.c: error (_("Junk at end of command"));
record-btrace.c: error (_("Trailing junk: '%s'."), args);
record-btrace.c: error (_("Trailing junk: '%s'."), args);
record-btrace.c: error (_("Trailing junk: '%s'."), args + l2);
record-btrace.c: error (_("Trailing junk: '%s'."), args + l1);
record-btrace.c: error (_("Trailing junk: '%s'."), args);
record.c: error (_("Junk after argument: %s."), arg);
record.c: error (_("Junk after argument: %s."), arg);
record.c: error (_("Junk after argument: %s."), arg);
symfile.c: error (_("Junk after %s"), argv[1]);
symfile.c: error (_("Junk after %s"), argv[0]);
symmisc.c: error (_("Junk at end of command"));
symmisc.c: error (_("Junk at end of command"));
So i guess as far as the record feature goes, the error message should
at least be "Trailing junk: %s". [Yeah, that is one heck of a silly nit,
isn't it?]
Otherwise, LGTM.
Keith
@@ -36,6 +36,10 @@ set unwindonsignal on|off
show unwindonsignal
These commands are now aliases for the new set/show unwind-on-signal.
+target record-full
+ This command now gives an error if any unexpected arguments are
+ found after the command.
+
* New commands
info missing-debug-handler
@@ -910,7 +910,7 @@ record_full_async_inferior_event_handler (gdb_client_data data)
/* Open the process record target for 'core' files. */
static void
-record_full_core_open_1 (const char *name, int from_tty)
+record_full_core_open_1 ()
{
regcache *regcache = get_thread_regcache (inferior_thread ());
int regnum = gdbarch_num_regs (regcache->arch ());
@@ -933,7 +933,7 @@ record_full_core_open_1 (const char *name, int from_tty)
/* Open the process record target for 'live' processes. */
static void
-record_full_open_1 (const char *name, int from_tty)
+record_full_open_1 ()
{
if (record_debug)
gdb_printf (gdb_stdlog, "Process record: record_full_open_1\n");
@@ -957,11 +957,14 @@ static void record_full_init_record_breakpoints (void);
/* Open the process record target. */
static void
-record_full_open (const char *name, int from_tty)
+record_full_open (const char *args, int from_tty)
{
if (record_debug)
gdb_printf (gdb_stdlog, "Process record: record_full_open\n");
+ if (args != nullptr)
+ error (_("trailing junk: '%s'"), args);
+
record_preopen ();
/* Reset */
@@ -971,9 +974,9 @@ record_full_open (const char *name, int from_tty)
record_full_list->next = NULL;
if (current_program_space->core_bfd ())
- record_full_core_open_1 (name, from_tty);
+ record_full_core_open_1 ();
else
- record_full_open_1 (name, from_tty);
+ record_full_open_1 ();
/* Register extra event sources in the event loop. */
record_full_async_inferior_event_token
@@ -2520,7 +2523,7 @@ static void
cmd_record_full_restore (const char *args, int from_tty)
{
core_file_command (args, from_tty);
- record_full_open (args, from_tty);
+ record_full_open (nullptr, from_tty);
}
/* Save the execution log to a file. We use a modified elf corefile
new file mode 100644
@@ -0,0 +1,24 @@
+# This testcase is part of GDB, the GNU debugger.
+#
+# Copyright 2024 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Check an error when passing unexpected arguments to 'target
+# record-full'.
+
+gdb_start
+
+gdb_test "target record-full blah" \
+ "trailing junk: 'blah'"