Bug 30288 - [gdb/cli, editing off] FAIL: gdb.base/trace-commands.exp: nested trace-commands test (pattern 2)
Summary: [gdb/cli, editing off] FAIL: gdb.base/trace-commands.exp: nested trace-comman...
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: testsuite (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: 14.1
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-03-29 16:45 UTC by Tom de Vries
Modified: 2023-03-31 15:33 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom de Vries 2023-03-29 16:45:29 UTC
I wrote a target board that sets editing to off by default, and ran the testsuite.

With test-case gdb.base/trace-commands.exp, I ran into trouble, with tests that send several commands at a time, using gdb_test_sequence to match the output.

I did this to get a clear look at what happens (because the output of gdb_test_sequence confuses me):
...
 # Nested test
+send_gdb "if 1\nset \$i = 0\nwhile \$i < 5\nfunc \$i\nset \$i += 1\nend\nend\n"
+gdb_test "" ".*" "test"
+exit
+
...

With the default, editing on, I get:
...
(gdb) PASS: gdb.base/trace-commands.exp: simple trace-commands test
if 1
+if 1
 >set $i = 0
 >while $i < 5
  >func $i
  >set $i += 1
  >end
 >end
++set $i = 0
++while $i < 5
+++func $i
++++echo in func $i\n
in func $i
+++set $i += 1
+++func $i
++++echo in func $i\n
in func $i
+++set $i += 1
+++func $i
++++echo in func $i\n
in func $i
+++set $i += 1
+++func $i
++++echo in func $i\n
in func $i
+++set $i += 1
+++func $i
++++echo in func $i\n
in func $i
+++set $i += 1
(gdb) PASS: gdb.base/trace-commands.exp: test
...

With editing off, I get instead:
...
(gdb) PASS: gdb.base/trace-commands.exp: simple trace-commands test
if 1
set $i = 0
while $i < 5
func $i
set $i += 1
end
end
+if 1
 > >  >  >  > >++set $i = 0
++while $i < 5
+++func $i
++++echo in func $i\n
in func $i
+++set $i += 1
+++func $i
++++echo in func $i\n
in func $i
+++set $i += 1
+++func $i
++++echo in func $i\n
in func $i
+++set $i += 1
+++func $i
++++echo in func $i\n
in func $i
+++set $i += 1
+++func $i
++++echo in func $i\n
in func $i
+++set $i += 1
(gdb) PASS: gdb.base/trace-commands.exp: test
...

If I do an interactive session with editing set to off, and issue one command at a time, I do see the expected output.

Tentatively marking this as component cli, but perhaps this is a testsuite issue.

If it's a testsuite issue, we should error out in send_gdb if the command string contains more than one "\n".
Comment 1 Tom de Vries 2023-03-30 04:14:47 UTC
This looks like a similar issue:
...
(gdb) PASS: gdb.threads/threadapply.exp: thread_set=all: try remove 2: thread 1.1
define remove-again^M
Type commands for definition of "remove-again".^M
End with a line saying just "end".^M
>remove-inferiors 2^M
end^M
>(gdb) FAIL: gdb.threads/threadapply.exp: thread_set=all: try remove 2: define remove-again (timeout)
...
Comment 2 Sourceware Commits 2023-03-31 15:15:39 UTC
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=89447229c7961dd99d5167f2ebcc5d8973d5d5ae

commit 89447229c7961dd99d5167f2ebcc5d8973d5d5ae
Author: Tom de Vries <tdevries@suse.de>
Date:   Fri Mar 31 17:15:37 2023 +0200

    [gdb/testsuite] Fix gdb.threads/threadapply.exp with editing off
    
    With test-case gdb.threads/threadapply.exp and editing set to on, we have:
    ...
    (gdb) define remove^M
    Type commands for definition of "remove".^M
    End with a line saying just "end".^M
    >remove-inferiors 3^M
    >end^M
    (gdb)
    ...
    but with editing set to off, we run into:
    ...
    (gdb) define remove^M
    Type commands for definition of "remove".^M
    End with a line saying just "end".^M
    >remove-inferiors 3^M
    end^M
    >(gdb) FAIL: gdb.threads/threadapply.exp: thread_set=all: try remove: \
      define remove (timeout)
    ...
    
    The commands are issued by this test:
    ...
            gdb_define_cmd "remove" {
                "remove-inferiors 3"
            }
    ...
    which does:
    - gdb_test_multiple "define remove", followed by
    - gdb_test_multiple "remove-inferiors 3\nend".
    
    Proc gdb_test_multiple has special handling for multi-line commands, which
    splits it up into subcommands, and for each subcommand issues it and then
    waits for the resulting prompt (the secondary prompt ">" for all but the last
    subcommand).
    
    However, that doesn't work as expected in this case because the initial
    gdb_test_multiple "define remove" fails to match all resulting output, and
    consequently the secondary prompt resulting from "define remove" is counted as
    if it was the one resulting from "remove-inferiors 3".
    
    Fix this by matching the entire output of "define remove", including the
    secondary prompt.
    
    Tested on x86_64-linux.
    
    PR testsuite/30288
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30288
Comment 3 Sourceware Commits 2023-03-31 15:15:44 UTC
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=103409bb38502b95cb60475939a49c2b059673d5

commit 103409bb38502b95cb60475939a49c2b059673d5
Author: Tom de Vries <tdevries@suse.de>
Date:   Fri Mar 31 17:15:37 2023 +0200

    [gdb/testsuite] Fix gdb.base/trace-commands.exp with editing off
    
    With test-case gdb.base/trace-commands.exp and editing off, I run into fails
    because multi-line commands are issued using gdb_test_sequence, which
    doesn't handle them correctly.
    
    Fix this by using gdb_test instead.
    
    Tested on x86_64-linux.
    
    PR testsuite/30288
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30288
Comment 4 Tom de Vries 2023-03-31 15:16:40 UTC
Fixed.
Comment 5 Tom de Vries 2023-03-31 15:33:44 UTC
(In reply to Tom de Vries from comment #0)
> If it's a testsuite issue, we should error out in send_gdb if the command
> string contains more than one "\n".

I've looked into this, but there are a couple of locations that seem to do this intentionally, to try and trigger a bug, so I've dropped this idea.