| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The bindings for the reverse execution commands are the same letters
as the forward execution command, but with the opposite case. This way
one can simply hold down the Shift modifier key or tap the Caps Lock key
to change the direction of execution.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In tui_layout_split::apply I noticed that for variable-size layouts we take
share_box into account by decreasing used_size:
...
used_size += info[i].size;
if (info[i].share_box)
--used_size;
...
but not for fixed-size layouts:
...
if (info[i].min_size == info[i].max_size)
available_size -= info[i].min_size;
...
Fix this by increasing available_size for fixed-size layouts with shared box.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The focused window is highlighted by using active-border-kind instead of
border-kind.
But if the focused window is the cmd window (which is an unboxed window), then
no highlighting is done, and it's not obvious from looking at the screen which
window has the focus. Instead, you have to notice the absence of highlighting
on boxed windows, and then infer that the focus is on the unboxed window.
That approach stops working if there are multiple unboxed windows.
Likewise if highlighting is switched off by setting active-border-kind to the
same value as border-kind.
Make it more explicit which window has the focus by mentioning it in the status
window, like so:
...
native process 8282 (src) In: main L7 PC: 0x400525
...
Tested on x86_64-linux and ppc64le-linux.
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
A TUI src window is displaying either:
- the source for the current frame,
- the source for main, or
- the string "[ No Source Available ]".
Since commit 03893ce67b5 ("[gdb/tui] Fix resizing of terminal to 1 or 2 lines")
we're able to resize the TUI to 1 line without crashing.
I noticed that if TUI is displaying main, and we resize to 1 line (destroying
the src window) and then back to a larger terminal (reconstructing the src
window), the TUI displays "[ No Source Available ]" instead of main.
Fix this by moving the responsibility for showing main from tui_enable to
tui_source_window_base::rerender.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed that after resizing to a narrow window, I got:
...
┌────────────────┐
│ │
│[ No Source Avail
able ] │
│ │
└────────────────┘
...
Fix this by adding two new functions:
- tui_win_info::display_string (int y, int x, const char *str)
- tui_win_info::display_string (const char *str)
that make sure that borders are not overwritten, which get us instead:
...
┌────────────────┐
│ │
│[ No Source Avai│
│ │
│ │
└────────────────┘
...
Tested on x86_64-linux.
|
|
I noticed in gdb/tui/tui-stack.c a source-level micro-optimization where
strlen with a string literal argument:
...
strlen ("bla")
...
is replaced with sizeof:
...
sizeof ("bla") - 1
...
The benefit of this is that the optimization is also done at O0, but the
drawback is that it makes the expression harder to read.
Use const std::string to encapsulate the string literals, and use
std::string::size () instead.
I tried making the string names (PROC_PREFIX, LINE_PREFIX, PC_PREFIX and
SINGLE_KEY) lower-case, but that clashed with a pre-existing pc_prefix, so
I've left them upper-case.
Tested on x86_64-linux.
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
When starting TUI in a terminal with 3 lines:
...
$ echo $LINES
3
$ gdb -q -tui
...
and resizing the terminal to 2 lines we run into a segfault.
The problem is that for the source window:
- the minimum height is 3 (the default), but
- the maximum height is only 2 because there are only 2 lines.
This discrepancy eventually leads to a call to newwin in make_window with:
...
(gdb) p height
$1 = 3
(gdb) p width
$2 = 56
(gdb) p y
$3 = -1
(gdb) p x
$4 = 0
...
which results in a nullptr.
This violates the assumption here in tui_apply_current_layout:
....
/* Get the new list of currently visible windows. */
std::vector<tui_win_info *> new_tui_windows;
applied_layout->get_windows (&new_tui_windows);
...
that get_windows only returns visible windows, which leads to tui_windows
holding a dangling pointer, which results in the segfault.
Fix this by:
- making sure get_windows only returns visible windows, and
- detecting the situation and dropping windows from the layout if
there's no room for them.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR tui/31044
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31044
|
|
When starting TUI in a terminal with 2 lines (likewise with 1 line):
...
$ echo $LINES
2
$ gdb -q -tui
...
we run into this assert in tui_apply_current_layout:
...
/* This should always be made visible by a layout. */
gdb_assert (TUI_CMD_WIN != nullptr);
...
The problem is that for the command window:
- the minimum height is 3 (the default), but
- the maximum height is only 2 because there are only 2 lines.
This discrepancy eventually leads to a call to newwin in make_window with:
...
(gdb) p height
$1 = 3
(gdb) p width
$2 = 66
(gdb) p y
$3 = -1
(gdb) p x
$4 = 0
(gdb)
...
which results in a nullptr, which eventually triggers the assert.
The easiest way to fix this is to change the minimum height of the command
window to 1. However, that would also change behaviour for the case that the
screen size is 3 lines or more. For instance, in gdb.tui/winheight.exp the
number of lines in the terminal is 24, and the test-case checks that the user
cannot increase the source window height to the point that the command window
height would be less than 3.
Fix this by calculating the minimum height of the command window as follows:
- the default (3) if max_height () allows it, and
- max_height () otherwise.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR tui/31044
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31044
|
|
Given that GDB now requires a C++17, replace all uses of
gdb::string_view with std::string_view.
This change has mostly been done automatically:
- gdb::string_view -> std::string_view
- #include "gdbsupport/gdb_string_view.h" -> #include <string_view>
One things which got brought up during review is that gdb::stging_view
does support being built from "nullptr" while std::sting_view does not.
Two places are manually adjusted to account for this difference:
gdb/tui/tui-io.c:tui_getc_1 and
gdbsupport/format.h:format_piece::format_piece.
The above automatic change transformed
"gdb::to_string (const gdb::string_view &)" into
"gdb::to_string (const std::string_view &)". The various direct users
of this function are now explicitly including
"gdbsupport/gdb_string_view.h". A later patch will remove the users of
gdb::to_string.
The implementation and tests of gdb::string_view are unchanged, they will
be removed in a following patch.
Change-Id: Ibb806a7e9c79eb16a55c87c6e41ad396fecf0207
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>
|
|
Since GDB now requires C++17, we don't need the internally maintained
gdb::optional implementation. This patch does the following replacing:
- gdb::optional -> std::optional
- gdb::in_place -> std::in_place
- #include "gdbsupport/gdb_optional.h" -> #include <optional>
This change has mostly been done automatically. One exception is
gdbsupport/thread-pool.* which did not use the gdb:: prefix as it
already lives in the gdb namespace.
Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>
|
|
I noticed that tui_locator_window has an empty do_scroll_vertical and
do_scroll_horizontal, like tui_cmd_window, but unlike tui_cmd_window doesn't
have:
...
bool can_scroll () const override
{
return false;
}
...
I suspect that it probably doesn't matter, but regardless it's good to have
the same implementations of basic properties in all windows.
Ensure this by adding a class tui_noscroll_window, that has:
- an empty do_scroll_vertical and do_scroll_horizontal, and
- a can_scroll returning false
which both tui_locator_window and tui_cmd_window inherit.
Make all methods final to ensure no accidental overrides are left in the
inheriting classes.
Likewise add new classes representing basic window properties:
- tui_nofocus_window,
- tui_oneline_window,
- tui_nobox_window,
- tui_norefresh_window, and
- tui_always_visible_window.
The changes are only a refactoring, apart from adding the "final", which does
limit the range of behaviours for subclasses.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Currently left_margin does not match its documentation:
...
/* Return the size of the left margin space, this is the space used to
display things like breakpoint markers. */
int left_margin () const
{ return box_width () + TUI_EXECINFO_SIZE + extra_margin (); }
...
It is stated that the left margin is reserved to display things, but
the box_width is not used for that.
Fix this by dropping box_width () from the left_margin calculation.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In tui_source_window::set_contents we have:
...
/* Take hilite (window border) into account, when
calculating the number of lines. */
int nlines = height - 2;
...
The '2' represents the total size of the window border (or box, in can_box
terms), in this case one line at the top and one line at the bottom.
Likewise, '1' is used to represent the width of the window border.
Introduce new functions:
- tui_win_info::box_width () and
- tui_win_info::box_size ()
that can be used instead instead of these hardcoded constants.
Implement these such that they return 0 when can_box () == false.
Tested patch completeness by making all windows unboxed:
...
@@ -85,7 +85,7 @@ struct tui_win_info
/* Return true if this window can be boxed. */
virtual bool can_box () const
{
- return true;
+ return false;
}
int box_width () const
...
and test-driving TUI.
This required eliminating an assert in
tui_source_window_base::show_source_content, I've included that part as well.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Currently the call to prefresh in tui_source_window_base::refresh_window looks
like:
...
prefresh (m_pad.get (), 0, pad_x, y + 1, x + left_margin,
y + m_content.size (), x + left_margin + view_width - 1);
...
This is hard to parse. It's not obvious what the arguments mean, and there's
repetition in the argument calculation.
Fix this by rewriting the call as follows:
- use sminrow, smincol, smaxrow and smaxcol variables for the last
4 arguments, and
- calculate the smaxrow and smaxcol variables based on the sminrow and
smincol variables.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When building gdb with -O2, we run into:
...
gdb/tui/tui-disasm.c: In function ‘CORE_ADDR tui_find_disassembly_address \
(gdbarch*, CORE_ADDR, int)’:
gdb/tui/tui-disasm.c:293:7: warning: ‘last_addr’ may be used uninitialized \
in this function [-Wmaybe-uninitialized]
if (last_addr < pc)
^~
...
The warning triggers since commit 72535eb14bd ("[gdb/tui] Fix segfault in
tui_find_disassembly_address").
Fix the warning by ensuring that last_addr is initialized at the point of
use:
...
+ last_addr = asm_lines.back ().addr;
if (last_addr < pc)
...
Tested on x86_64-linux.
|
|
In tui_find_disassembly_address we find an assert:
...
if (asm_lines.size () < max_lines)
{
if (!possible_new_low.has_value ())
return new_low;
/* Take the best possible match we have. */
new_low = *possible_new_low;
next_addr = tui_disassemble (gdbarch, asm_lines, new_low, max_lines);
last_addr = asm_lines.back ().addr;
gdb_assert (asm_lines.size () >= max_lines);
}
...
The comment right above:
...
/* If we failed to disassemble the required number of lines then the
following walk forward is not going to work, it assumes that
ASM_LINES contains exactly MAX_LINES entries. Instead we should
consider falling back to a previous possible start address in
POSSIBLE_NEW_LOW. */
...
claims that the more strict asm_lines.size () == max_line is required.
Update the assert to reflect this, and move it to after the if because it's
supposed to hold in general, not just when entering the if.
Tested on x86_64-linux.
|
|
Make the inferior's gdbarch field private, and add getters and setters.
This helped me by allowing putting breakpoints on set_arch to know when
the inferior's arch was set. A subsequent patch in this series also
adds more things in set_arch.
Change-Id: I0005bd1ef4cd6b612af501201cec44e457998eec
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
The new_objfile observer is currently used to indicate both when a new
objfile is added to program space (when passed non-nullptr) and when all
objfiles of a program space were just removed (when passed nullptr).
I think this is confusing (and Andrew apparently thinks so too [1]).
Add a new "all_objfiles_removed" observer to remove the second role from
"new_objfile".
Some existing users of new_objfile do nothing if the passed objfile is
nullptr. For them, we can simply drop the nullptr check. For others,
add a new all_objfiles_removed callback, and refactor things a bit to
keep the existing behavior as much as possible.
Some callbacks relied on current_program_space, and following
the refactoring now use either objfile->pspace or the pspace passed to
all_objfiles_removed. I think this should be relatively safe, and in
general a step in the right direction.
On the notify side, I found only one call site to change from
new_objfile to all_objfiles_removed, in clear_symtab_users. It is not
entirely clear to me that this is entirely correct. clear_symtab_users
appears to be called in spots that don't remove all objfiles
(functions finish_new_objfile, remove_symbol_file_command, reread_symbols,
do_module_cleanups). But I think that this patch at least makes the
current code clearer.
[1] https://gitlab.com/gnutools/binutils-gdb/-/commit/a0a031bce0527b1521788b5dad640e7883b3a252
Change-Id: Icb648f72862e056267f30f44dd439bd4ec766f13
Approved-By: Tom Tromey <tom@tromey.com>
|
|
PR29040 describes a FAIL for test-case gdb.threads/next-fork-other-thread.exp
and target board unix/-m32.
The FAIL happens due to the test executable running into an assert, which is
caused by a forked child segfaulting, like so:
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00000000 in ?? ()
...
I tried to reproduce the segfault with exec next-fork-other-thread-fork, using
TUI layout asm.
I set a breakpoint at fork and ran to the breakpoint, and somewhere during the
following session I ran into a gdb segfault here in
tui_find_disassembly_address:
...
/* Disassemble forward. */
next_addr = tui_disassemble (gdbarch, asm_lines, new_low, max_lines);
last_addr = asm_lines.back ().addr;
...
due to asm_lines being empty after the call to tui_disassemble, while
asm_lines.back () assumes that it's not empty.
I have not been able to reproduce that segfault in that original setting, I'm
not sure of the exact scenario (though looking back it probably involved
"set detach-on-fork off").
What likely happened is that I managed to reproduce PR29040, and TUI (attempted
to) display the disassembly for address 0, which led to the gdb segfault.
When gdb_print_insn encounters an insn it cannot print because it can't read
the memory, it throws a MEMORY_ERROR that is caught by tui_disassemble.
The specific bit that causes the gdb segfault is that if gdb_print_insn throws
a MEMORY_ERROR for the first insn in tui_disassemble, it returns an empty
asm_lines.
FWIW, I did manage to reproduce the gdb segfault as follows:
...
$ gdb -q \
-iex "set pagination off" \
/usr/bin/rustc \
-ex "set breakpoint pending on" \
-ex "b dl_main" \
-ex run \
-ex "up 4" \
-ex "layout asm" \
-ex "print \$pc"
...
<TUI>
...
$1 = (void (*)()) 0x1
(gdb)
...
Now press <up>, and the segfault triggers.
Fix the segfault by handling asm_lines.empty () results of tui_disassemble in
tui_find_disassembly_address.
I've written a unit test that exercises this scenario.
Tested on x86_64-linux.
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
PR tui/30823
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30823
|
|
I noticed a comment by an include and remembered that I think these
don't really provide much value -- sometimes they are just editorial,
and sometimes they are obsolete. I think it's better to just remove
them. Tested by rebuilding.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Rationale:
I use the mouse with my terminal to select and copy text. In gdb, I use
the mouse to select a function name to set a breakpoint, or a variable
name to print, for example.
When gdb is compiled with ncurses mouse support, gdb's TUI mode
intercepts mouse events. Left-clicking and dragging, which would
normally select text, seems to do nothing. This means I cannot select
text using my mouse anymore. This makes it harder to set breakpoints,
print variables, etc.
Solution:
I tried to fix this issue by editing the 'mousemask' call to only enable
buttons 4 and 5. However, this still caused my terminal (gnome-terminal)
to not allow text to be selected. The only way I could make it work is
by calling 'mousemask (0, NULL);'. But doing so disables the mouse code
entirely, which other people might want.
I therefore decided to make a setting in gdb called 'tui mouse-events'.
If enabled (the default), the behavior is as it is now: terminal mouse
events are given to gdb, disabling the terminal's default behavior.
If disabled (opt-in), the behavior is as it was before the year 2020:
terminal mouse events are not given to gdb, therefore the mouse can be
used to select and copy text.
Notes:
I am not attached to the setting name or its description. Feel free to
suggest better wording.
Testing:
I tested this change in gnome-terminal by performing the following steps
manually:
1. Run: gdb --args ./myprogram
2. Enable TUI: press ctrl-x ctrl-a
3. Click and drag text with the mouse. Observe no selection.
4. Input: set tui mouse-events off
5. Click and drag text with the mouse. Observe that selection works now.
6. Input: set tui mouse-events on.
7. Click and drag text with the mouse. Observe no selection.
|
|
In test-case gdb.tui/long-prompt.exp, with a prompt of 40 chars, the same size
as the terminal width, we get a superfluous newline at line 19:
...
16 (gdb) set prompt 123456789A123456789B123
17 456789C123456789>
18 123456789A123456789B123456789C123456789>
19
20 123456789A123456789B123456789C123456789>
21 set prompt (gdb)
22 (gdb)
...
as well as a superfluous repetition of the prompt at line 20 once we type the
's' starting "set prompt".
I traced the superfluous newline back to readline's readline_internal_setup,
that does:
...
/* If we're not echoing, we still want to at least print a prompt, because
rl_redisplay will not do it for us. If the calling application has a
custom redisplay function, though, let that function handle it. */
if (_rl_echoing_p == 0 && rl_redisplay_function == rl_redisplay)
...
else
{
if (rl_prompt && rl_already_prompted)
rl_on_new_line_with_prompt ();
else
rl_on_new_line ();
(*rl_redisplay_function) ();
...
and then we hit the case that calls rl_on_new_line_with_prompt, which does:
...
/* If the prompt length is a multiple of real_screenwidth, we don't know
whether the cursor is at the end of the last line, or already at the
beginning of the next line. Output a newline just to be safe. */
if (l > 0 && (l % real_screenwidth) == 0)
_rl_output_some_chars ("\n", 1);
...
This doesn't look like a readline bug, because the behaviour matches the
comment.
[ And the fact that the output of the newline doesn't happen in the scope of
tui_redisplay_readline means it doesn't get the prompt wrap detection
treatment, causing start_line to be incorrect, which causes the superfluous
repetition of the prompt. ]
I looked at ways to work around this, and managed by switching off
rl_already_prompted, which we set to 1 in tui_rl_startup_hook:
...
/* Readline hook to redisplay ourself the gdb prompt.
In the SingleKey mode, the prompt is not printed so that
the command window is cleaner. It will be displayed if
we temporarily leave the SingleKey mode. */
static int
tui_rl_startup_hook (void)
{
rl_already_prompted = 1;
if (tui_current_key_mode != TUI_COMMAND_MODE
&& !gdb_in_secondary_prompt_p (current_ui))
tui_set_key_mode (TUI_SINGLE_KEY_MODE);
tui_redisplay_readline ();
return 0;
}
...
Then I started looking at why rl_already_prompted is set to 1.
The use case for rl_already_prompted seems to be:
- app (application, the readline user) outputs prompt,
- app sets rl_already_prompted to 1, and
- app calls readline, which calls rl_on_new_line_with_prompt, which figures
out how long the prompt is, and sets a few readline variables accordingly,
which can be used in the following call to rl_redisplay_function.
AFAICT, TUI does not fit this pattern. It does not output an initial prompt,
rather it writes the prompt in every rl_redisplay_function. It doesn't use
the variables set by rl_on_new_line_with_prompt, instead it figures stuff out
by itself.
Fix this by removing the rl_already_prompted setting.
Also remove the call to tui_redisplay_readline, it's not necessary, the
function is called anyway.
Tested on x86_64-linux, no regressions.
|
|
This commit builds on this earlier work:
commit 9fe01a376b2fb096e4836e985ba316ce9dc02399
Date: Thu Jun 29 11:26:55 2023 -0600
Update TUI window title when changed
and makes tui_win_info::title private, renaming to m_title at the same
time. There's a new tui_win_info::title() member function to provide
read-only access to the title.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The tui border-kind setting allows values acs, ascii and space.
The values ascii and space however don't work well with !HAVE_WBORDER.
Fix this by removing the !HAVE_WBORDER case, which was introduced for Ultrix
support, which is now obsolete.
Tested on x86_64-linux.
PR tui/30580
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30580
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The only use of "entry = translate (...)" is entry->value.
Simplify using the function by returning entry->value instead.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The tables:
- tui_border_kind_translate_ulcorner
- tui_border_kind_translate_urcorner
- tui_border_kind_translate_llcorner
- tui_border_kind_translate_lrcorner
are identical.
Merge and rename to tui_border_kind_translate_corner.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In function tui_update_variables we have the somewhat inconvenient:
...
entry = translate (tui_border_kind, tui_border_kind_translate_lrcorner);
int val = (entry->value < 0) ? ACS_LRCORNER : entry->value;
...
Add a new function translate_acs, that allows us to do the more straighforward:
...
int val = translate_acs (tui_border_kind, tui_border_kind_translate_lrcorner,
ACS_LRCORNER);
...
By special-casing "acs" in translate_acs, we can now remove the acs entries
from the translation tables.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The TUI translation tables contain default entries at the end:
...
static struct tui_translate tui_border_kind_translate_hline[] = {
{ "space", ' ' },
{ "ascii", '-' },
{ "acs", -1 },
{ 0, 0 },
{ "ascii", '-' }
};
...
A simpler way of implementing this would be to to declare the first (or last)
entry the default, but in fact these default entries are not used.
Make this explicit by removing the default entries, and asserting in translate
that an entry will always be found.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I wrote a TUI window in Python, and I noticed that setting its title
did not result in a refresh, so the new title did not appear. This
patch corrects this problem.
|
|
Simplify tui_update_variables by using template function
assign_return_if_changed.
Tested on x86_64-linux.
|
|
Replace macro HELP_ATTRIBUTE_MODE with a std::string.
Tested on x86_64-linux.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
Simplify tui_puts_internal by using continue, as per this [1] coding standard
rule, making the function more readable and easier to understand.
No functional changes.
Tested on x86_64-linux.
[1] https://llvm.org/docs/CodingStandards.html#use-early-exits-and-continue-to-simplify-code
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
Say we're in TUI mode, and type "sun":
...
(gdb) sun
...
After switching to SingleKey mode using C-x s, we have just:
...
sun
...
After typing "d", we get:
...
sun
Undefined command: "sundown". Try "help".
...
The SingleKey "d" is supposed run the "down" command.
Fix this by clearing the readline line buffer when switching to SingleKey
mode.
Tested on x86_64-linux.
PR tui/30522
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30522
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
I noticed that the help texts for tui border-mode and tui active-border-mode
are similar.
Factor out the common part into macro HELP_ATTRIBUTE_MODE.
Tested on x86_64-linux.
|
|
Fix some more typos:
- distinquish -> distinguish
- actualy -> actually
- singe -> single
- frash -> frame
- chid -> child
- dissassembler -> disassembler
- uninitalized -> uninitialized
- precontidion -> precondition
- regsiters -> registers
- marge -> merge
- sate -> state
- garanteed -> guaranteed
- explictly -> explicitly
- prefices (nonstandard plural) -> prefixes
- bondary -> boundary
- formated -> formatted
- ithe -> the
- arrav -> array
- coresponding -> corresponding
- owend -> owned
- fials -> fails
- diasm -> disasm
- ture -> true
- tpye -> type
There's one code change, the name of macro SIG_CODE_BONDARY_FAULT changed to
SIG_CODE_BOUNDARY_FAULT.
Tested on x86_64-linux.
|
|
Fix a few typos:
- implemention -> implementation
- convertion(s) -> conversion(s)
- backlashes -> backslashes
- signoring -> ignoring
- (un)ambigious -> (un)ambiguous
- occured -> occurred
- hidding -> hiding
- temporarilly -> temporarily
- immediatelly -> immediately
- sillyness -> silliness
- similiar -> similar
- porkuser -> pokeuser
- thats -> that
- alway -> always
- supercede -> supersede
- accomodate -> accommodate
- aquire -> acquire
- priveleged -> privileged
- priviliged -> privileged
- priviledges -> privileges
- privilige -> privilege
- recieve -> receive
- (p)refered -> (p)referred
- succesfully -> successfully
- successfuly -> successfully
- responsability -> responsibility
- wether -> whether
- wich -> which
- disasbleable -> disableable
- descriminant -> discriminant
- construcstor -> constructor
- underlaying -> underlying
- underyling -> underlying
- structureal -> structural
- appearences -> appearances
- terciarily -> tertiarily
- resgisters -> registers
- reacheable -> reachable
- likelyhood -> likelihood
- intepreter -> interpreter
- disassemly -> disassembly
- covnersion -> conversion
- conviently -> conveniently
- atttribute -> attribute
- struction -> struct
- resonable -> reasonable
- popupated -> populated
- namespaxe -> namespace
- intialize -> initialize
- identifer(s) -> identifier(s)
- expection -> exception
- exectuted -> executed
- dungerous -> dangerous
- dissapear -> disappear
- completly -> completely
- (inter)changable -> (inter)changeable
- beakpoint -> breakpoint
- automativ -> automatic
- alocating -> allocating
- agressive -> aggressive
- writting -> writing
- reguires -> requires
- registed -> registered
- recuding -> reducing
- opeartor -> operator
- ommitted -> omitted
- modifing -> modifying
- intances -> instances
- imbedded -> embedded
- gdbaarch -> gdbarch
- exection -> execution
- direcive -> directive
- demanged -> demangled
- decidely -> decidedly
- argments -> arguments
- agrument -> argument
- amespace -> namespace
- targtet -> target
- supress(ed) -> suppress(ed)
- startum -> stratum
- squence -> sequence
- prompty -> prompt
- overlow -> overflow
- memember -> member
- languge -> language
- geneate -> generate
- funcion -> function
- exising -> existing
- dinking -> syncing
- destroh -> destroy
- clenaed -> cleaned
- changep -> changedp (name of variable)
- arround -> around
- aproach -> approach
- whould -> would
- symobl -> symbol
- recuse -> recurse
- outter -> outer
- freeds -> frees
- contex -> context
Tested on x86_64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
I noticed:
...
(gdb) help show tui tab-width
Show the tab witdh, in characters, for the TUI.
This variable controls how many spaces are used to display a tab character.
...
a typo: "witdh".
Fix this by using "width" instead.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
I added a cmd-only layout:
...
(gdb) tui new-layout cmd cmd 1
...
and set it:
...
(gdb) layout cmd
...
which gave me the expect result: only the cmd window in the screen.
However, after going back to layout src:
...
(gdb) layout src
...
I got a source window with only one line in it, and the cmd window taking most
of the screen.
I traced this back to tui_set_layout, where for both the old and the new
layout the fingerprint of the cmd window in the layout is taken. If the
fingerprint is the same, an effort will be done to preserve the command
window size.
The fingerprint is "VC" for both the old (cmd) and new (src) layouts, which
explains the behaviour.
I think this is essentially a bug in the finger print calculation, and it
should be "C" for the cmd layout.
Fix this by not adding a V or H in the fingerprint if the list size is one.
Tested on x86_64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
Remove the breakpoint_pointer_iterator layer. Adjust all users of
all_breakpoints and all_tracepoints to use references instead of
pointers.
Change-Id: I376826f812117cee1e6b199c384a10376973af5d
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
|
|
Remove the bp_location_pointer_iterator layer. Adjust all users of
breakpoint::locations to use references instead of pointers.
Change-Id: Iceed34f5e0f5790a9cf44736aa658be6d1ba1afa
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
|
|
Add convenience first_loc methods to struct breakpoint (const and
non-const overloads). A subsequent patch changes the list of locations
to be an intrusive_list and makes the actual list private, so these
spots would need to change from:
b->loc
to something ugly like:
*b->locations ().begin ()
That would make the code much heavier and not readable. There is a
surprisingly big number of places that access the first location of
breakpoints. Whether this is correct, or these spots fail to consider
the possibility of multi-location breakpoints, I don't know. But
anyhow, I think that using this instead:
b->first_loc ()
conveys the intention better than the other two forms.
Change-Id: Ibbefe3e4ca6cdfe570351fe7e2725f2ce11d1e95
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
|
|
I noticed a buglet in tui_update_variables:
...
entry = translate (tui_border_kind, tui_border_kind_translate_lrcorner);
if (tui_border_lrcorner != (chtype) entry->value)
{
tui_border_lrcorner = (entry->value < 0) ? ACS_LRCORNER : entry->value;
...
When assigning the new value to tui_border_lrcorner, an entry->value of -1 is
taken into account, but not when comparing to the current value of
tui_border_lrcorner.
Fix this by introducing:
...
int val = (entry->value < 0) ? ACS_LRCORNER : entry->value;
...
and using this in both comparison and assignment.
Tested on x86_64-linux.
|
|
Currently, for a source file containing only 5 lines, we also show line
numbers 6 and 7 if they're in scope of the source window:
...
0 +-compact-source.c----------------+
1 |___3_{ |
2 |___4_ return 0; |
3 |___5_} |
4 |___6_ |
5 |___7_ |
6 +---------------------------------+
...
Fix this by not showing line numbers not in a source file, such that we have instead:
...
0 +-compact-source.c----------------+
1 |___3_{ |
2 |___4_ return 0; |
3 |___5_} |
4 | |
5 | |
6 +---------------------------------+
...
Tested on x86_64-linux.
Suggested-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Andrew pointed out that the behaviour as tested in gdb.tui/compact-source.exp
is incorrect:
...
0 +-compact-source.c--------------------------------------------------------+
1 |___3_{ |
2 |___4_ return 0; |
3 |___5_} |
4 |___6_ |
5 |___7_ |
6 |___8_ |
7 |___9_ |
8 +-------------------------------------------------------------------------+
...
The last line number in the source file is 5, and there are 7 lines to display
source lines, so if we'd scroll all the way down, the first line number in the
source window would be 5, and the last one would be 11.
To represent 11 we'd need 2 digits, so we expect to see ___04_ here instead of
___4_, even though all line numbers currently in the src window (3-9) can be
represented with only 1 digit.
Fix this in tui_source_window::set_contents, by updating the computation of
max_line_nr:
...
- int max_line_nr = std::max (lines_in_file, last_line_nr_in_window);
+ int max_line_nr = lines_in_file + nlines - 1;
...
Tested on x86_64-linux.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Consider a hello.c, with less than 10 lines:
...
$ wc -l hello.c
8 hello.c
...
and compiled with -g into an a.out.
With compact-source off:
...
$ gdb -q a.out \
-ex "set tui border-kind ascii" \
-ex "maint set tui-left-margin-verbose on" \
-ex "set tui compact-source off" \
-ex "tui enable"
...
we get:
...
+-./data/hello.c-----------------------+
|___000005_{ |
|___000006_ printf ("hello\n"); |
|___000007_ return 0; |
|___000008_} |
|___000009_ |
|___000010_ |
|___000011_ |
...
but with compact-source on:
...
+-./data/hello.c-----------------------+
|___5{ |
|___6 printf ("hello\n"); |
|___7 return 0; |
|___8} |
|___9 |
|___1 |
|___1 |
...
There are a couple of problems with compact-source.
First of all the documentation mentions:
...
The default display uses more space for line numbers and starts the
source text at the next tab stop; the compact display uses only as
much space as is needed for the line numbers in the current file, and
only a single space to separate the line numbers from the source.
...
The bit about the default display and the next tab stop looks incorrect. The
source doesn't start at a tab stop, instead it uses a single space to separate
the line numbers from the source.
Then the documentation mentions that there's single space in the compact
display, but evidently that's missing.
Then there's the fact that the line numbers "10" and "11" are both abbreviated
to "1" in the compact case.
The abbreviation is due to allocating space for <lines in source>, which is
8 for this example, and takes a single digit. The line numbers though
continue past the end of the file, so fix this by allocating space for
max (<lines in source>, <last line in window>), which in this example takes 2
digits.
The missing space is due to some confusion about what the "1" here in
tui_source_window::set_contents represent:
...
double l = log10 ((double) offsets->size ());
m_digits = 1 + (int) l;
...
It could be the trailing space that's mentioned in tui-source.h:
...
/* How many digits to use when formatting the line number. This
includes the trailing space. */
int m_digits;
...
Then again, it could be part of the calculation for the number of digits
needed for printing. With this minimal example:
...
int main () {
for (int i = 8; i <= 11; ++i) {
double l = log10 ((double) i);
printf ("%d %d\n", i, (int)l);
}
return 0;
}
...
we get:
...
$ ./a.out
8 0
9 0
10 1
11 1
...
which shows that the number of digits needed for printing i is
"1 + (int)log10 ((double) i)".
Fix this by introducing named variables needed_digits and trailing_space, each
adding 1.
With the fixes, we get for compact-source on:
...
+-./data/hello.c-----------------------+
|___05_{ |
|___06_ printf ("hello\n"); |
|___07_ return 0; |
|___08_} |
|___09_ |
|___10_ |
|___11_ |
|...
Also fix the documentation and help text to actually match effect of
compact-source.
Tested on x86_64-linux.
|
|
I'd like to move some things so they become methods on struct ui. But
first, I think that struct ui and the related things are big enough to
deserve their own file, instead of being scattered through top.{c,h} and
event-top.c.
Change-Id: I15594269ace61fd76ef80a7b58f51ff3ab6979bc
|
|
With TERM=ansi, when resizing a TUI window from LINES/COLUMNS 31/118
(maximized) to 20/78 (de-maximized), I get a garbled screen (that ^L doesn't
fix) and a message:
...
@@ resize done 0, size = 77x20
...
with the resulting width being 77 instead of the expected 78.
[ The discrepancy also manifests in CLI, filed as PR30346. ]
The discrepancy comes from tui_resize_all, where we ask readline for the
screen size:
...
rl_get_screen_size (&screenheight, &screenwidth);
...
As it happens, when TERM is set to ansi, readline decides that the terminal
cannot auto-wrap lines, and reserves one column to deal with that, and as a
result reports back one less than the actual screen width:
...
$ echo $COLUMNS
78
$ TERM=xterm gdb -ex "show width" -ex q
Number of characters gdb thinks are in a line is 78.
$ TERM=ansi gdb -ex "show width" -ex q
Number of characters gdb thinks are in a line is 77.
...
In tui_resize_all, we need the actual screen width, and using a screenwidth of
one less than the actual value garbles the screen.
This is currently not causing trouble in testing because we have a workaround
in place in proc Term::resize. If we disable the workaround:
...
- stty columns [expr {$_cols + 1}] < $::gdb_tty_name
+ stty columns $_cols < $::gdb_tty_name
...
and dump the screen we get the same type of screen garbling:
...
0 +---------------------------------------+|
1 ||
2 ||
3 ||
...
Another way to reproduce the problem is using command "maint info screen".
After starting gdb with TERM=ansi, entering TUI, and issuing the command, we
get:
...
Number of characters curses thinks are in a line is 78.
...
and after maximizing and demaximizing the window we get:
...
Number of characters curses thinks are in a line is 77.
...
If we use TERM=xterm, we do get the expected 78.
Fix this by:
- detecting when readline will report back less than the actual screen width,
- accordingly setting a new variable readline_hidden_cols,
- using readline_hidden_cols in tui_resize_all to fix the resize problem, and
- removing the workaround in Term::resize.
The test-case gdb.tui/empty.exp serves as regression test.
I've applied the same fix in tui_async_resize_screen, the new test-case
gdb.tui/resize-2.exp serves as a regression test for that change. Without
that fix, we have:
...
FAIL: gdb.tui/resize-2.exp: again: gdb width 80
...
Tested on x86_64-linux.
PR tui/30337
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30337
|
|
Latest libc++[1] causes transitive include to <locale> when
<mutex> or <thread> header is included. This causes
gdb to not build[2] since <locale> defines isupper/islower etc.
functions that are explicitly macroed-out in safe-ctype.h to
prevent their use.
Use the suggestion from libc++ to include <locale> internally when
building in C++ mode to avoid build errors.
Use safe-gdb-ctype.h as the include instead of "safe-ctype.h"
to keep this isolated to gdb since rest of binutils
does not seem to use much C++.
[1]: https://reviews.llvm.org/D144331
[2]: https://issuetracker.google.com/issues/277967395
|
|
In commit 5d10a2041eb ("gdb: add string_file::release method") this was added:
...
+ std::string string_val = string.release ();
...
without updating subsequent uses of string.size (), which returns 0 after the
string.release () call.
Fix this by:
- using string_val.size () instead of string.size (), and
- adding an assert that would have caught this regression.
Tested on x86_64-linux.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
PR tui/30389
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30389
|
|
The m_digits member of tui_source_window is documented as having semantics:
...
/* How many digits to use when formatting the line number. This
includes the trailing space. */
...
The commit 1b6d4bb2232 ("Redraw both spaces between line numbers and source
code") started printing two trailing spaces instead:
...
- xsnprintf (text, sizeof (text), "%*d ", m_digits - 1, lineno);
+ xsnprintf (text, sizeof (text), "%*d ", m_digits - 1, lineno);
...
Now that PR30325 is fixed, this no longer has any effect.
Fix this by reverting to the original behaviour: print one trailing space
char.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
