[gdb/testsuite] Reimplement Term::command_no_prompt_prefix
authorTom de Vries <tdevries@suse.de>
Wed, 21 Jun 2023 13:31:37 +0000 (15:31 +0200)
committerTom de Vries <tdevries@suse.de>
Wed, 21 Jun 2023 13:31:37 +0000 (15:31 +0200)
commit9f889c4856f38db1eade7efa2d12eb7994f2c55e
tree76402ddd26f7d9cfd47bf53f1629fbc62b1e6ccc
parentc9966f7a8e71f182734e97a7d149237f2eb89c23
[gdb/testsuite] Reimplement Term::command_no_prompt_prefix

Say we run test-case gdb.tui/basic.exp.  It calls Term::enter_tui, which does:
...
command_no_prompt_prefix "tui enable"
...

The proc command_no_prompt_prefix is documented as:
...
    # As proc command, but don't wait for an initial prompt.  This is used for
    # initial terminal commands, where there's no prompt yet.
...

Indeed, before the "tui enable" command, the tuiterm is empty, so there is no
prompt and just before switching to TUI we have in the tuiterm:
...
tui enable
...

The reason that there is no prompt, is that:
- in order for tuiterm to show something, its input processing procs need to
  be called, and
- the initial gdb prompt, and subsequent prompts generated by gdb_test-style
  procs, are all consumed by those procs instead.

This is in principle not a problem, but the absence of a prompt makes a
tuiterm session look less like a session on an actual xterm.

Add a new proc gen_prompt, that:
- generates a prompt using echo
- consumes the response before the prompt using gdb_expect
- consumes the prompt using Term::wait_for "".

This allows us to reimplement Term::command_no_prompt_prefix using
Term::command, and just before switching to TUI we have in the tuiterm:
...
(gdb) tui enable
...

Tested on x86_64-linux.
gdb/testsuite/lib/tuiterm.exp