gdb/testsuite: update gdb.tui/tui-disasm-long-lines.exp
authorAndrew Burgess <aburgess@redhat.com>
Tue, 20 Dec 2022 16:25:33 +0000 (16:25 +0000)
committerAndrew Burgess <aburgess@redhat.com>
Wed, 25 Jan 2023 10:36:53 +0000 (10:36 +0000)
commit843a1a4f735e77147710b307db29a1b5f4e1c707
tree99ca62615baefa6d4c9d43ee68e1b5360017cd29
parentb3b0595ff66d8597637c415f74d43dd459a18cb3
gdb/testsuite: update gdb.tui/tui-disasm-long-lines.exp

Following on from the previous commit, in this commit I am updating
the test script gdb.tui/tui-disasm-long-lines.exp to take account of
the changes in commit:

  commit 9162a27c5f5828240b53379d735679e2a69a9f41
  Date:   Tue Nov 13 11:59:03 2018 -0700

      Change gdb test suite's TERM setting

In the above commit the TERM environment variable was changed to be
'dumb' by default, which means that tests, that previously activated
tui mode, no longer do unless TERM is set to 'ansi'.

As the gdb.tui/tui-disasm-long-lines.exp script didn't do this, the
test stopped working.  As the expect patterns in this script were
pretty generic no tests actually started failing, and we never
noticed.

In this commit I update the script to use Term::clean_restart, which
correctly sets TERM to 'ansi'.  I've also added a check that the asm
box does appear on the screen, which should indicate that tui mode has
correctly activated.

However, I also notice that GDB doesn't appear to fully work
correctly.  The test should display the disassembly for the test
program, but it doesn't.

The test is trying to disassemble some code that (deliberately) uses a
very long symbol name, this eventually results in GDB entering
tui_source_window_base::show_source_content and trying to allocate an
ncurses pad in order to hold the current page of disassembler output.

Unfortunately, due to the very long line, the call to newpad fails,
meaning that tui_source_window_base::m_pad is nullptr.  Luckily non of
the following calls appear to crash when passed a nullptr, however,
all the output that is written to the pad is lost, which is why we
don't see any assembly code written to the screen.

As the test history indicates that the script was originally checking
for a crash in GDB when the long identifier was encountered, I think
there is value in just leaving the test as it is for now, I have a fix
for the issue of the newpad call failing, which I'll post in a follow
up commit later.
gdb/testsuite/gdb.tui/tui-disasm-long-lines.exp