Until recently when the source window was scrolled the assembler
window would scroll in sync - keeping the disassembly for the current
line in view.
This was broken in commit:
commit b4b49dcbff
Date: Wed Nov 13 16:47:58 2019 -0700
Don't call tui_show_source from tui_ui_out
This commit restores the synchronised scrolling and also maintains the
horizontal scroll within the source view when it is vertically
scrolled, something that was broken before.
This commit does not mean that scrolling the assembler view scrolls
the source view. The connection this way never existed, though maybe
it should, but I'll leave adding this feature for a separate commit.
gdb/ChangeLog:
* tui/tui-source.c (tui_source_window::do_scroll_vertical): Update
all source windows, and maintain horizontal scroll status while
doing so.
gdb/testsuite/ChangeLog:
* gdb.tui/basic.exp: Add more scrolling tests.
Change-Id: I250114a3bc670040a6a759d41905776771b2f818
Hannes Domani pointed out that my previous patch to fix the "list"
command in the TUI instead broke vertical scrolling. While looking at
this, I found that do_scroll_vertical calls print_source_lines, which
seems like a very roundabout way to change the source window. This
patch removes this oddity and fixes the bug at the same time.
I've added a new test case. This is somewhat tricky, because the
obvious approach of sending a dummy command after the scroll did not
work -- due to how the TUI works, sennding a command causes the scroll
to take effect.
gdb/ChangeLog
2019-12-22 Tom Tromey <tom@tromey.com>
PR tui/18932:
* tui/tui-source.c (tui_source_window::do_scroll_vertical): Call
update_source_window, not print_source_lines.
gdb/testsuite/ChangeLog
2019-12-22 Tom Tromey <tom@tromey.com>
PR tui/18932:
* lib/tuiterm.exp (Term::wait_for): Rename from _accept. Return a
meangingful value.
(Term::command, Term::resize): Update.
* gdb.tui/basic.exp: Add scrolling test.
Change-Id: I9636a7c8a8cade37431c6165ee996a9d556ef1c8
Currently if a user starts the tui with 'layout asm' then they will be
presented with the 'src' layout.
What happens is:
1. Layout command enables TUI, selecting the SRC layout by default.
2. As part of tui_enable we call tui_display_main, which calls
tui_get_begin_asm_address, which calls
set_default_source_symtab_and_line. This changes core GDBs
current symtab and line, which triggers a call to the symtab
changed hook tui_symtab_changed, which sets the flag
from_source_symtab.
3. Back in the layout command, the layout is changed from SRC to
ASM. After this the layout command completes and we return to
core GDB which prints the prompt, however...
4. The before prompt hook is called which sees the
from_source_symtab flag is set and forces the SRC window to be
displayed. This switches us back to SRC view.
The solution I propose here is to delay installing the hooks into core
GDB until after we have finished setting up the tui and selecting the
default frame to view. In this way we effectively ignore the first
symtab changed event triggered when making main the default symtab.
gdb/ChangeLog:
* tui/tui.c (tui_enable): Register tui hooks after calling
tui_display_main.
gdb/testsuite/ChangeLog:
* gdb.tui/tui-layout-asm.exp: New file.
Change-Id: I858ab81a17ffb4aa72deb3f36c3755228a9c9d9a
A new test procedure for matching the contents of one screen box
against a regexp. This can be used to match the contents of one TUI
window against a regexp without any of the borders, or other windows
being included in the matched output (as is currently the case with
check_contents).
This will be used in a later commit.
gdb/testsuite/ChangeLog:
* lib/tuiterm.exp (Term::check_box_contents): New proc.
Change-Id: Icf795bf38dd9295e282a34eecc318a9cdbc73926
Split Term::enter_tui into two procedures, a core which does the
setup, but doesn't actually enable tui mode, and the old enter_tui
that calls the new core, and then enables tui mode.
This is going to be useful in a later commit.
gdb/testsuite/ChangeLog:
* lib/tuiterm.exp (Term::prepare_for_tui): New proc.
(Term::enter_tui): Use Term::prepare_for_tui.
Change-Id: I501dfb2ddaa4a4e7246a5ad319ab428e4f42b3af
The Term::dump_screen routine currently dumps the screen using calls
to 'verbose', this means it will only dump the screen when the
testsuite is running in verbose mode.
However, the Term::dump_screen is most often called when a test fails,
in this case I think it is useful to have the screen dumped even when
we're not in verbose mode.
This commit changes the calls to 'verbose' to be 'verbose -log' so we
always get the screen dump.
gdb/testsuite/ChangeLog:
* lib/tuiterm.exp (Term::dump_screen): Always dump the screen when
called.
Change-Id: I5f0a7f5ac2ece04d6fe6e9c5a28ea2a0dda38955
In this commit:
commit 5024637fac
Date: Sun Dec 15 11:05:47 2019 +0100
Fix skip.exp test failure observed with gcc-9.2.0
A race condition was introduced into the gdb.base/skip.exp test when
this line:
gdb_test "step" "foo \\(\\) at.*" "step 3"
Was changed to this:
gdb_test "step" "foo \\(\\) at.*" "step 3" "main \\(\\) at .*" "step"
Before the above change we expected GDB to behave like this:
(gdb) step
foo () at /path/to/gdb/testsuite/gdb.base/skip.c:42
42 return 0;
(gdb)
However, when the test is compiled with GCC 9.2.0 we get a different
behaviour, and so we need a second 'step', like this:
(gdb) step
main () at /path/to/gdb.base/skip.c:32
32 x = baz ((bar (), foo ()));
(gdb) step
foo () at /path/to/gdb/testsuite/gdb.base/skip.c:42
42 return 0;
(gdb)
Now the change to the test matches against 'main () at .*', however if
GDB or expect is being slow then we might only get to see output like
this:
(gdb) step
main () at /path/to/g
This will happily match the question pattern, so we send 'step' to GDB
again. Now GDB continues to produce output which expect accepts, we
now see this:
b.base/skip.c:32
32 x = baz ((bar (), foo ()));
(gdb)
This has carried on from where the previous block of output left off.
This doesn't match the final pattern 'foo \\(\\) at.*', but it does
match the prompt pattern that gdb_test_multiple adds, and so we report
the test as failing.
The solution is to simply ensure that the question consumes everything
up to, and including the prompt. This ensures that the prompt can't
then match the failure case. The new test line becomes:
gdb_test "step" "foo \\(\\) at.*" "step 3" \
"main \\(\\) at .*\r\n$gdb_prompt " "step"
gdb/testsuite/ChangeLog:
* gdb.base/skip.exp: Fix race condition in test.
Change-Id: I9f0b0b52ef1b4f980bfaa8fe405ff06d520f3482
Recent MinGW versions require -lssp when using _FORTIFY_SOURCE, which
gdb does (in common-defs.h)
https://github.com/msys2/MINGW-packages/issues/5868#issuecomment-544107564
To avoid all the complications with checking for -lssp and making sure it's
linked statically, just don't define it.
gdb/ChangeLog:
2020-01-09 Christian Biesinger <cbiesinger@google.com>
* gdbsupport/common-defs.h: Don't define _FORTIFY_SOURCE on MinGW.
Change-Id: Ide6870ab57198219a2ef78bc675768a789ca2b1d
The body of this this big "for" loop is missing an indentation level,
this patch fixes that.
gdb/ChangeLog:
* thread.c (print_thread_info_1): Fix indentation.
compute_and_set_names would only free the name if we did not find the name
in the hashtable, but it needs to always free it. Solve this by moving the
smart pointer outside the if.
Thanks to PhilippeW for finding this.
gdb/ChangeLog:
2020-01-09 Christian Biesinger <cbiesinger@google.com>
* symtab.c (general_symbol_info::compute_and_set_names): Move the
unique_xmalloc_ptr outside the if to always free the demangled name.
Change-Id: Id7c6b8408432183700ccb5ff634818d6c5a3ac95
This replaces two instances of manual string management in
dwarf2read.c with std::string.
gdb/ChangeLog
2020-01-08 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (parse_macro_definition): Use std::string.
(parse_macro_definition): Likewise.
Change-Id: Iec437100105484aa4a116fb5d651d7ed52ee9d81
This removes some manual memory management from
abbrev_table_read_table, replacing it with a std::vector.
gdb/ChangeLog
2020-01-08 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (abbrev_table_read_table): Use std::vector.
(ATTR_ALLOC_CHUNK): Remove.
Change-Id: I0b0e70ac2281d89a78f4d6a642700c9f0506871d
This changes fixup_go_packaging to use unique_xmalloc_ptr. I kept
this patch separate as it is slightly more complicated than the
previous changes.
gdb/ChangeLog
2020-01-08 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (fixup_go_packaging): Use unique_xmalloc_ptr.
Change-Id: I0c553d0c6579db478c27bc40fc21133a61e1a4d9
I noticed a few spots in dwarf2read.c that could be improved by moving
to unique_xmalloc_ptr or, in one case, std::vector.
gdb/ChangeLog
2020-01-08 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (add_partial_symbol): Use unique_xmalloc_ptr.
(dwarf2_compute_name, open_dwo_file): Likewise.
(process_enumeration_scope): Use std::vector.
(guess_partial_die_structure_name): Use unique_xmalloc_ptr.
(partial_die_info::fixup, dwarf2_start_subfile)
(guess_full_die_structure_name, dwarf2_name): Likewise.
(determine_prefix): Update.
(guess_full_die_structure_name): Make return type const.
(partial_die_full_name): Return unique_xmalloc_ptr.
(DW_FIELD_ALLOC_CHUNK): Remove.
Change-Id: I1cb278c608041ef36ef1f77c7e7565c921038d08
PR build/24937 concerns an error given by the clang provided by a
particular version of macOS. In particular, it reports
error: default initialization of an object of const type 'const
stap_static_probe_ops' without a user-provided default constructor
Although (at least according to sources I found online) this was
resolved as a bug in the standard, it seemed simple enough to work
around this.
Given that this is a trivial build fix, I think it should go on the
gdb 9 branch as well.
gdb/ChangeLog
2020-01-07 Tom Tromey <tromey@adacore.com>
PR build/24937:
* stap-probe.c (class stap_static_probe_ops): Add constructor.
Change-Id: I18f180c17850f420e9b66afc67f9cb3d8dceb0b3
Cygwin meets the expectations of gdb for styling (if TERM is set and not
'DUMB', the terminal supports 'ANSI' (ECMA-48) escape sequences.
gdb/ChangeLog:
2020-01-02 Jon Turney <jon.turney@dronecode.org.uk>
* cli/cli-style.c: Set cli_styling to 'true' in the Cygwin build.
In this commit:
commit ec8e2b6d30
Date: Fri Jun 14 23:43:00 2019 +0100
gdb: Don't allow annotations to influence what else GDB prints
A change was accidentally made that moved a call to do_gdb_disassembly
out of an if block guarded by 'if (source_print && sal.symtab)'. The
result was that if a user has 'set disassemble-next-line on' then the
backtrace would now include some disassembly of a few instructions in
each frame.
This change was not intentional, but was not spotted by any tests.
This commit restores the old behaviour and adds a test to ensure this
doesn't break again in the future.
gdb/ChangeLog:
* stack.c (print_frame_info): Move disassemble_next_line code
inside source_print block.
gdb/testsuite/ChangeLog:
* gdb.base/backtrace.c: New file.
* gdb.base/backtrace.exp: New file.
Change-Id: I47c52a202fa74be138382646b695827940178689
gdb/ChangeLog
2020-01-06 Eli Zaretskii <eliz@gnu.org>
* gdbsupport/gdb_wait.c: Include <signal.h> instead of
gdb/signals.h, as we are now using native signal symbols.
In tui_disasm_window::addr_is_displayed(), there can be situations
where "content" is empty. For instance, it can happen when the
"content" was not filled in tui_disasm_window::set_contents(),
because tui_disassemble() threw an exception. Usually this exception
is the result of fetching invalid PC addresses like the ones beyond
the end of the program.
Having "content.size ()" zero leads to an overflow in this condition
check inside tui_disasm_window::addr_is_displayed():
int i = 0;
while (i < content.size () - threshold ...) {
... content[i] ...
}
"threshold" is 2 and there are times that "content.size ()" is 0.
This results into an overflow and the loop is entered whereas it
should have been skipped. Finally, "content[i]" access leads to
a segmentation fault.
Same problem applies to tui_source_window::line_is_displayed().
The issue has been discussed at length in bug 25345:
https://sourceware.org/bugzilla/show_bug.cgi?id=25345
This commit avoids the segmentation faults with an early check:
if (content.size () < SCROLL_THRESHOLD)
return false;
Moreover, those functions have been overhauled to a leaner code.
gdb/ChangeLog:
2020-01-06 Shahab Vahedi <shahab@synopsys.com>
* tui/tui-disasm.c (tui_disasm_window::addr_is_displayed): Avoid
overflow by an early check of content vs threshold.
* tui/tui-source.c (tui_source_window::line_is_displayed):
Likewise.
Don't try to read the PE export table when no section contains the RVA
for it.
(I have a PE executable [1] packed with UPX, where the export table data
directory entry contains a RVA which doesn't correspond to any section.
Mistakenly trying to debug this with gdb makes it crash.)
[1] https://cygwin.com/setup/setup-2.898.x86_64.exe
gdb/ChangeLog:
2020-01-02 Jon Turney <jon.turney@dronecode.org.uk>
* coff-pe-read.c (read_pe_exported_syms): Don't try to read the
export table if no section contains it's RVA.
The variable last_line_listed is never set when print_source_lines_base is
called in TUI mode, so the search always started from the last line printed
outside of TUI mode.
gdb/ChangeLog:
2020-01-06 Hannes Domani <ssbssa@yahoo.de>
* source.c (print_source_lines_base): Set last_line_listed.
When a Windows program is terminated by a fatal exception, its exit
code is the value of that exception, as defined by the various
EXCEPTION_* symbols in the Windows API headers. This commit emulates
WTERMSIG etc. by translating the fatal exception codes to more-or-less
equivalent Posix signals.
gdb/ChangeLog:
2020-01-06 Eli Zaretskii <eliz@gnu.org>
Pedro Alves <palves@redhat.com>
* Makefile.in (COMMON_SFILES): Add gdbsupport/gdb_wait.c.
* windows-tdep.c: New enumeration of WINDOWS_SIG* signals.
(windows_gdb_signal_to_target): New function, uses the above
enumeration to convert GDB internal signal codes to equivalent
Windows codes.
(windows_init_abi): Call set_gdbarch_gdb_signal_to_target.
* windows-nat.c: Include "gdb_wait.h".
(get_windows_debug_event): Extract the fatal exception from the
exit status and convert to the equivalent Posix signal number.
* cli/cli-cmds.c (exit_status_set_internal_vars): Account for the
possibility that WTERMSIG returns GDB_SIGNAL_UNKNOWN.
* gdbsupport/gdb_wait.c: New file, implements
windows_status_to_termsig.
* gdbsupport/gdb_wait.h (WIFEXITED, WIFSIGNALED, WEXITSTATUS)
(WTERMSIG) [__MINGW32__]: Separate definitions for MinGW.
gdb/gdbserver/ChangeLog:
2020-01-06 Eli Zaretskii <eliz@gnu.org>
Pedro Alves <palves@redhat.com>
* win32-low.c (get_child_debug_event): Extract the fatal exception
from the exit status and convert to the equivalent Posix signal
number.
(win32_wait): Allow TARGET_WAITKIND_SIGNALLED status as well.
* Makefile.in (OBS, SFILES): Add gdb_wait.[co].
When calling tui_add_win_to_layout, use tui_set_layout not show_layout
so that window focus is correctly updated. If the focus is not
correctly maintained then GDB can be crashed like this:
start
tui enable
layout asm
list SOME_FUNCTION
At this point GDB will have "popped up" the source window to
display SOME_FUNCTION. Previously no window would have focus at this
point, and so if the user now does 'focus next' or 'focus prev', then
GDB would crash.
Calling tui_set_layout ensures that focus is correctly calculated as
the source window is "popped up", and this fixes the issue.
gdb/ChangeLog:
* tui/tui-layout.c (tui_add_win_to_layout): Use tui_set_layout not
show_layout.
gdb/testsuite/ChangeLog:
* gdb.tui/list.exp: Test 'focus next' after 'list main'.
Change-Id: Id0b13f99b0e889261efedfd0adabe82020202f44
While investigating some SVE code, i noticed the use of two spu bfd variables.
This looks like an oversight, as the "id" field is available for non-spu
architectures as well, even though its primary use was the Cell BE
architecture.
gdb/ChangeLog:
2020-01-05 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-nat.c
(aarch64_linux_nat_target::thread_architecture): Use bfd_arch_aarch64
and bfd_mach_aarch64.
While handling the comments of Tom related to
[RFC] Have an option to tell GDB to detect and possibly handle mismatched exec-files.
https://sourceware.org/ml/gdb-patches/2019-12/msg00621.html
I saw that GDB warnings are produced ignoring the given styles.
This patch:
* ensures that style markups are properly handled by "warning".
* changes 'set/show data-directory' so that file style is used
in warnings and in 'show message'
* changes all other messages in top.c to use file style when appropriate.
* Uses the above data-directory changes in gdb.base/style.exp
2020-01-03 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* ui-file.c (stdio_file::can_emit_style_escape)
(tee_file::can_emit_style_escape): Ensure style is used also on
gdb_stderr when gdb_stderr is a tty supporting styling, similarly
to gdb_stdout.
* main.c (set_gdb_data_directory): Use file style to output the
warning that the given pathname is not a directory.
* top.c (show_history_filename, gdb_safe_append_history)
(show_gdb_datadir): Use file style.
2020-01-03 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/style.exp: Test that warnings are styled.
gdb/ChangeLog:
2020-01-03 Hannes Domani <ssbssa@yahoo.de>
* solib-target.c (struct lm_info_target):
Change offsets to be a unique_xmalloc_ptr.
(solib_target_relocate_section_addresses): Update.
While reading some code i noticed we're still referencing Cell BE in a couple
parts. This patch removes those.
v2: Update comment in gdb/target.h.
gdb/ChangeLog:
2020-01-02 Luis Machado <luis.machado@linaro.org>
* proc-service.c (get_ps_regcache): Remove reference to obsolete
Cell BE architecture.
* target.h (struct target_ops) <thread_architecture>: Likewise.
Change-Id: I7a9ccc603b00db22a6275bc5ab69e1417148cb72
The variable INSTALL_PROGRAM_ENV sets up STRIPPROG for the cross-compiler.
If this is not done, the host 'strip' is used, and fails:
/bin/sh /c/src/repos/binutils-gdb.git/install-sh -c -s gdb.exe \
/gdb/gdb64-git/bin/$transformed_name.exe
strip.exe:C:/gdb/gdb64-git/bin/_inst.33599_: file format not recognized
With this change, it's fine:
STRIPPROG='x86_64-w64-mingw32-strip' \
/bin/sh /c/src/repos/binutils-gdb.git/install-sh -c -s gdb.exe \
/gdb/gdb64-git/bin/$transformed_name.exe
gdb/ChangeLog:
2020-01-01 Hannes Domani <ssbssa@yahoo.de>
* Makefile.in: Use INSTALL_PROGRAM_ENV.
gdb/gdbserver/ChangeLog:
2020-01-01 Hannes Domani <ssbssa@yahoo.de>
* Makefile.in: Use INSTALL_PROGRAM_ENV.
These are files that need to be updated by hand, because the copyright.py
script isn't able to handle them automatically.
gdb/ChangeLog:
* gdbarch.sh: Update copyright year range of generated files.
gdb/doc/ChangeLog:
* gdb.texinfo, refcard.tex: Update copyright year range.
This changes a few TUI globals to be "static". Tested by rebuilding.
gdb/ChangeLog
2019-12-30 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_border_mode_translate)
(tui_border_kind_translate_vline, tui_border_kind_translate_hline)
(tui_border_kind_translate_ulcorner)
(tui_border_kind_translate_urcorner)
(tui_border_kind_translate_llcorner)
(tui_border_kind_translate_lrcorner, tui_active_border_mode)
(tui_border_mode, tui_border_kind): Now static.
Change-Id: Ibb49a0df195dfe780a5ba1f90e9125ab5f6b7ce1
This changes a few spots in the TUI to use "bool" rather than "int".
Tested on x86-64 Fedora 28.
gdb/ChangeLog
2019-12-30 Tom Tromey <tom@tromey.com>
* tui/tui-interp.c (tui_start_enabled): Now bool.
(_initialize_tui_interp): Update.
* tui/tui-hooks.c (tui_refreshing_registers): Now bool.
(tui_register_changed)
(tui_refresh_frame_and_register_information): Update.
* tui/tui-win.c (tui_update_variables): Return bool.
* tui/tui-win.h (tui_update_variables): Return bool.
* tui/tui.c (tui_get_command_dimension): Return bool.
* tui/tui.h (tui_get_command_dimension): Return bool.
Change-Id: I55b7f2d62d2ef88da3587dc914ada9f463ad8d2b
This removes code that was present from the very first git revisison
7b4ac7e1ed from 1988. It was in the
gdb/dbxread.c at the time (and makes more sense for dbx line info format
since line numbers are 16-bit entities in that debug format and debugging
files with more than 65535 lines would not work anyway) but moved from
there to gdb/buildsym.c which is used for dwarf line info as well, and
excluding an arbitrary line number does certainly not make sense nowadays.
Add a test case for line 65535
gdb:
2019-12-29 Bernd Edlinger <bernd.edlinger@hotmail.de>
* buildsym.c (buildsym_compunit::record_line): Do no longer ignore
line 65535.
gdb/testsuite:
2019-12-29 Bernd Edlinger <bernd.edlinger@hotmail.de>
* gdb.base/line65535.exp: New file.
* gdb.base/line65535.c: New file.
This test verifies that GDB correctly identifies the run-time type of
"s" as being the type "Circle". However, that can only be done
correctly if the GNAT runtime has been compiled and shipped with debug
information, so that GDB can poke in its internal data structures.
Currently the test fails when when running against a GNAT runtime
without debug info. This is the case, for example, on Arch Linux using
the distribution package.
This patch adds a helper in lib/ada.exp to check whether the GNAT
runtime has debug info or not. It then uses it in
gdb.ada/ptype_tagged_param.exp to expect a different result, depending
on whether we have debug info or not in the runtime.
At first, I made it so we would XFAIL the test, in the absence of debug
info, but then I thought that we might as well test for the output we
expect in the absence of debug info instead.
gdb/testsuite/ChangeLog:
* lib/ada.exp (gnat_runtime_has_debug_info): New proc.
* lib/gnat_debug_info_test.adb: New file.
* gdb.ada/ptype_tagged_param.exp: Use
gnat_runtime_has_debug_info, expect a different output if
runtime does not have debug info.
I found some dead code in the TUI -- some using #if 0, and some
commented-out code. There's no reason to keep this, so this patch
removes it.
gdb/ChangeLog
2019-12-27 Tom Tromey <tom@tromey.com>
* tui/tui-source.c (tui_source_window::do_scroll_vertical): Remove
commented-out code.
* tui/tui.c: Remove #if 0 code.
Change-Id: Ie00933b2ba498417ce22e5da3f62f5a40c234f33
I noticed that print_disassembly has two #if blocks for TUI code,
where one would do. This patch rearranges the code slightly to remove
a #if.
gdb/ChangeLog
2019-12-27 Tom Tromey <tom@tromey.com>
* cli/cli-cmds.c (print_disassembly): Reorder "if".
Change-Id: I36f3f682f5685b3d9b148da5aed26eb3cc7d598e
This changes tui_active and tui_finish_init to have type "bool".
gdb/ChangeLog
2019-12-27 Tom Tromey <tom@tromey.com>
* tui/tui.c (tui_active): Now bool.
(tui_finish_init): Likewise.
(tui_enable): Update.
(tui_disable): Update.
(tui_is_window_visible): Update.
* tui/tui.h (tui_active): Now bool.
Change-Id: Ia159ae9beb041137e34956b77f5bcf4e83eaf2b9
tui_gen_win_info::viewport_height is only used in a couple of spots,
and is redundant with "height". This patch removes viewport_height.
gdb/ChangeLog
2019-12-27 Tom Tromey <tom@tromey.com>
* tui/tui-source.c (tui_source_window::maybe_update): Update.
* tui/tui-regs.c (tui_data_window::display_registers_from):
Update.
* tui/tui-layout.c (tui_gen_win_info::resize): Update.
* tui/tui-data.h (struct tui_gen_win_info) <viewport_height>:
Remove.
* tui/tui-command.c (tui_cmd_window::resize): Update.
Change-Id: I020e026fbe289adda8e2fdfebca91bdbdbc312e8
