diff options
author | Tom de Vries <tdevries@suse.de> | 2023-06-21 15:31:37 +0200 |
---|---|---|
committer | Tom de Vries <tdevries@suse.de> | 2023-06-21 15:31:37 +0200 |
commit | 9f889c4856f38db1eade7efa2d12eb7994f2c55e (patch) | |
tree | 76402ddd26f7d9cfd47bf53f1629fbc62b1e6ccc /gold/defstd.cc | |
parent | c9966f7a8e71f182734e97a7d149237f2eb89c23 (diff) | |
download | binutils-9f889c4856f38db1eade7efa2d12eb7994f2c55e.zip binutils-9f889c4856f38db1eade7efa2d12eb7994f2c55e.tar.gz binutils-9f889c4856f38db1eade7efa2d12eb7994f2c55e.tar.bz2 |
[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.
Diffstat (limited to 'gold/defstd.cc')
0 files changed, 0 insertions, 0 deletions