| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Every time we update the gdb version number, test-case gdb.base/default.exp
needs updating because it matches the values of convenience variables
$_gdb_{major,minor} using hardcoded expected values:
...
{$_gdb_major = 17} \
{$_gdb_minor = 1} \
...
I'm assuming the values were hardcoded because gdb_test_list_exact was used.
Since the previous patch, that's not longer the case, so use regexps instead,
getting rid of this annoyance [1].
Tested on x86_64-linux.
[1] https://sourceware.org/pipermail/gdb-patches/2019-October/160935.html
|
|
I ran test-case gdb.base/default.exp with make-check-all.sh, and noticed a
FAIL with host/target board local-remote-host-native:
...
FAIL: $exp: show convenience ($_colorsupport = "monochrome" not found)
...
The problem is that part of the test-case relies on "setenv TERM dumb", and
setenv, which is a tcl command (which runs on build), only has effect in gdb
(which runs on host), if build == host, in other words, local host.
I grepped for test-cases using setenv, and ran them with the host/target
board, and fixed the FAILs I saw.
All FAILs have the same cause as I described above, except for
proc test_data_directory in gdb.python/py-parameter.exp, which handles files
assuming local host. I chose to leave it that way, and bail out but add a
comment.
Implementationwise, the change to test-case gdb.base/default.exp is the most
intrusive: it replaces a use of proc gdb_test_list_exact with a use of proc
gdb_get_lines_no_pass, because it allows specifying a regexp match.
In the process, I found out gdb_test_list_exact has a bug, filed as PR33038.
Because of this bug, I had to add matching of convenience variable $_tbl.
Tested on x86_64-linux.
|
|
While re-testing the TUI tests on x86_64-freebsd, I found that commit
06a53717f7c ("[gdb/testsuite] Handle unrecognized escape sequences better in
tuiterm") broke most test-cases.
Fix this by rewriting this gdb_test_multiple clause:
...
-re "^($re_csi_prefix?)($re_csi_args*)($re_csi_cmd)" {
...
into:
...
-re "^($re_csi_cmd)" {
...
-re "^($re_csi_args*)($re_csi_cmd)" {
...
-re "^($re_csi_prefix?)($re_csi_args*)($re_csi_cmd)" {
...
Tested on x86_64-linux and x86_64-freebsd.
|
|
When encountering an unrecognized escape sequence in Term::accept_gdb_output,
a warning is issued:
...
WARNING: timeout in accept_gdb_output
...
and 0 is returned.
Subsequent calls run into the same problem, so matching doesn't progress.
Consequently, figuring out what the unrecognized escape sequence actually is
depends on analyzing gdb's output as echoed into gdb.log.
In the test added in this commit, gdb (well, a script gdb.tcl emulating gdb)
outputs escape sequence "ESC ( B", which doesn't show up in recognizable form
in gdb.log:
...
foo^M^M
...
and as mentioned the tuiterm screen only show:
...
foo
...
because matching doesn't progress beyond the unrecognized sequence.
Fix this by rewriting accept_gdb_output to match gdb output using a phased
approach that echoes unmatched escape sequences, giving us instead on the
tuiterm screen:
...
foo^[(B
...
[ Since "ESC ( B" is now supported, the test-case has been updated to use
"ESC ( % 5" instead. ]
Tested on x86_64-linux.
PR testsuite/33218
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33218
|
|
The variable Term::_last_char is meant to represent the last char inserted by
Term::_insert, but setting it is done alongside the only call to _insert in
lib/tuiterm.exp:
...
_insert $expect_out(0,string)
variable _last_char
set _last_char [string index $expect_out(0,string) end]
...
Fix this by moving the setting of _last_char to inside _insert.
Tested on x86_64-linux.
|
|
Add test-case gdb.tui/tui-mode-switch.exp, a regression test for
PR tui/30523.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30523
|
|
Add Term::with_term that allows us to override the default TERM used in
tuiterm:
...
Term::with_term xterm {
Term::clean_restart 12 40
}
...
|
|
Add support for:
- DECKPAM (Application Keypad)
ESC =
- DECKPNM (Normal Keypad)
ESC >
|
|
Add support for:
- Designate G0 Character Set, USASCII
ESC ( B
- Designate G0 Character Set, DEC Special Character and Line Drawing Set
ESC ( 0
|
|
Add support for:
- Set Scrolling Region (DECSTBM)
CSI r
|
|
Add support for:
- Window manipulation (XTWINOPS)
CSI t
|
|
Add support for:
- DECSET
CSI ? h
- DECRST
CSI ? l
|
|
Add support for:
- Set Mode (SM)
CSI h
- Reset Mode (RM)
CSI l
|
|
This commit continues the theme of the previous commit, restoring the
behaviour of forward-search and reverse-search to what it was before
GDB 10, but adds tests to guard the behaviour. I believe this
restored behaviour is inline with the documentation of the two search
commands.
This time, I'm looking at what happens when no source lines end up
being printed. This can happen for two reasons, a request is made to
list a line number outside the file, or, a request is made to list a
reverse series of lines (e.g. line 100 to line 50).
Before GDB 10, a 'list' command that resulted in no lines being
printed would not change the notion of the last line listed. As a
result a future forward or reverse search would continue from the
previous last line. As an example, here's current master branch
behaviour:
(gdb) list 50
45 /* Line 45 */
46 /* Line 46 */
47 /* Line 47 */
48 /* Line 48 */
49 /* Line 49 */
50 /* Line 50 */
51 /* Line 51 */
52 /* Line 52 */
53 /* Line 53 */
54 /* Line 54 */
(gdb) list 1000
Line number 995 out of range; long-file.c has 101 lines.
(gdb) forward-search Line
Expression not found
(gdb)
But on GDB 9, the forward-search instead acts like this:
(gdb) forward-search Line
55 /* Line 55 */
(gdb)
Similarly, reverse-search reports "Expression not found" on master,
but would return line 53 on GDB 9.
The reverse-search result for master might be a little surprising,
surely, if we tried to list line 1000, then every line before that
should be searched.
The problem is that last_line_listed ends up being set to 995 (which
is 1000 minus half the listsize). Then, when the reverse-search kicks
in GDB tried to read line 994, fails, and abandons the search.
This problem was introduced with commit:
commit 8b7fcda2744145f2380af01c9db8e11986f7af6d
Date: Sun Dec 22 14:58:22 2019 +0100
Fix search in TUI
This commit wants last_line_listed updated so that the search
functions would work correctly (see notes below) when GDB is in TUI
mode. Without this commit last_line_listed would never be updated in
TUI mode, and so every search would effectively start from the
beginning of the file.
The fix I propose is to delay updating the current_source_location
until the source code has been printed successfully. That is, just
before we leave print_source_lines_base, after a successful print.
This update happens inside the 'if (noprint)' block, a the return here
isn't really considered an error condition, this is a specific choice
_not_ to print the source code.
However, in the 'if (stopline <= line)' block, the
current_source_location is not updated, that's because this 'if'
represents an error condition.
The last_line_listed is also updated at the end of the function still,
which is the path taken in CLI mode when source lines are actually
printed.
I've added some CLI tests to confirm the forward/reverse search
behaviour. And I've also added some TUI tests to check search works
within the TUI. The TUI tests cover more than just the fix for this
issue.
There is one slight issue with the TUI. At this point you should
definitively go read the previous commit. OK, so, the forward and
reverse searches are supposed to search from the last line listed.
The previous commit fixed this for CLI mode, but for the TUI the
last_line_listed is _still_ being set to the first line displayed.
The problem is that print_source_lines_base doesn't know the size of
the TUI src window, and so, doesn't know what the last line listed
will be, and so cannot set last_line_listed correctly.
This indicates to me that setting last_line_listed from the core GDB
code is likely the wrong approach, or, at least, the way it is done
now is the wrong approach.
Currently the 'list' command converts the arguments into a set of
lines to be printed based on the CLI environment, e.g. using the
'listsize' if necessary. But the 'listsize' doesn't make sense for
the TUI, where the src window height really overrides the 'listsize'.
The list command then calls the core GDB print_source_lines
function to do the printing, but for the TUI we don't actually print
anything, we just update the internal state (including
last_line_listed) and are done.
I think that the current interpreter, CLI or TUI, needs to get
involved in the 'list' command implementation much sooner. This would
allow, for example, the CLI to use 'listsize' and the TUI to use the
src window height. It might then be up to the interpreter to track
the last line listed maybe?
I mention all this only to acknowledge this issue. The problem
existed before this commit, and continues to exist after this commit.
I'm not proposing to fix this problem right now.
The TUI forward/reverse search continue to work as well as they have
since commit 8b7fcda2744.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The forward-search and reverse-search commands were broken by this
commit:
commit a75cd9a2c129dfc086cbe570ef9cff9b84570bbd
Date: Thu Nov 14 16:11:15 2019 -0700
Add observable to watch current source symtab
while builds on the work in this commit:
commit 1dd588507782591478882a891f64945af9e2b86c
Date: Thu Aug 1 09:34:40 2019 -0600
Make current_source_* per-program-space
both of these commits went into GDB 10.
The documentation for these commands is pretty clear:
'forward-search REGEXP'
'search REGEXP'
The command 'forward-search REGEXP' checks each line, starting with
the one following the last line listed, for a match for REGEXP. It
lists the line that is found. You can use the synonym 'search
REGEXP' or abbreviate the command name as 'fo'.
'reverse-search REGEXP'
The command 'reverse-search REGEXP' checks each line, starting with
the one before the last line listed and going backward, for a match
for REGEXP. It lists the line that is found. You can abbreviate
this command as 'rev'.
Both searches should start searching based on the last line listed.
But currently:
(gdb) list 3
1 int
2 main (void)
3 {
4 /* Line 4 */
5 /* Line 5 */
6 /* Line 6 */
7 /* Line 7 */
8 /* Line 8 */
9 /* Line 9 */
10 /* Line 10 */
(gdb) forward-search Line
4 /* Line 4 */
(gdb)
This should have found line 11. And for reverse-search:
(gdb) list 3
1 int
2 main (void)
3 {
4 /* Line 4 */
5 /* Line 5 */
6 /* Line 6 */
7 /* Line 7 */
8 /* Line 8 */
9 /* Line 9 */
10 /* Line 10 */
(gdb) reverse-search Line
Expression not found
(gdb)
The reverse-search should have returned line 9.
This new behaviour started with the above commits in GDB 10. On GDB 9
we see behaviour that matches the documentation.
Where the forward and reverse searches start from is controlled by a
global, last_line_listed, found in source.c.
Before commit 1dd588507782, in print_source_lines_base, the
last_line_listed variable was updated as each source line was printed,
and it was updated with the current line being printed.
After commit 1dd588507782, the current symtab and line are moved into
a current_source_location object, but the symtab and line member
variables are public. The last_line_listed is still set based on the
value held in the current_source_location object, and this object is
updated each time around the source printing loop. So despite the
restructure, the logic, and behaviour, is unchanged.
After commit a75cd9a2c129, the member variables of
current_source_location are now private. The source printing loop in
print_source_lines_base uses a local variable, new_lineno, to track
the current source line number, and updates the
current_source_location at the end of print_source_lines_base.
However, last_line_listed is still updated inside the loop, using the
original line value within current_source_location, which is no longer
being updated each time around the loop.
As a result, last_line_listed is now just the first line listed!
This didn't show up in testing because, as far as I can tell, the
last_line_listed is _only_ used for forward and reverse searching, and
the testing for these commands is minimal.
In this commit I move the setting of last_line_listed outside of the
source printing loop, this only needs to be updated once, when we have
finished printing the source lines.
I've also done a couple of other cleanups in the same area, I moved
'buf' a local variable into the most inner scope where it is required,
and I converted the 'while' loop into a 'for' loop, moving the
increment out of the loop body.
There's now a test which does some more detailed checks of the forward
and reverse search commands.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
With test-case gdb.base/dlmopen.exp and target board native-gdbserver, I get:
...
(gdb) info breakpoints 3^M
Num Type Disp Enb Address What^M
3 breakpoint keep y 0x00007ffff7fc8000 ^M
stop only if (0) (target evals)^M
(gdb) FAIL: $exp: test_solib_unmap_events: check b/p status
...
The problem is that the regexp doesn't allow for the "(target evals)" part:
...
-re -wrap "$bpnum\\s+breakpoint\\s+keep\\s+y\\s+$::hex\\s*\[^\r\n\]+\r\n\\s+stop o
nly if \\(0\\)" {
...
Fix this by updating the regexp.
While we're at it:
- rewrite the regexp using multiline, string_to_regexp, join and string cat to
make it more readable, and
- remove the redundant failure clause from the same gdb_test_multiple.
Tested on x86_64-linux using make-check-all.sh.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
With test-case gdb.tui/basic.exp and target board native-extended-gdbserver I
get:
...
status line: '<reverse:1>extended-r No process (asm) In: L?? PC: ?? <reverse:0>'
FAIL: gdb.tui/basic.exp: status window: reverse
...
because the regexp:
...
gdb_assert { [regexp "^<.*>exec" $status] == 1 } \
...
tries to match:
...
status line: '<reverse:1>exec No process (asm) In: L?? PC: ?? <reverse:0>'
...
Fix this by updating the regexp to allow both exec and extended-r.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I ran gdb/copyright.py and these were changed.
Change-Id: If0cfb538eff45cbb51863b963405002689512285
|
|
In lib/tuiterm.exp we have:
...
namespace eval Term {
variable ...
...
}
...
with everything within the namespace (which is basically the entire file)
indented, which wastes screen space and makes editing more involved.
We could maybe fix this by moving the "namespace eval Term" to tuiterm_env,
but I don't think it's a good idea to move it out of the file.
Another idea is to have the file include itself, wrapped in the namespace:
...
if { ![info exists Term::_in_namespace] } {
namespace eval Term {
# Read the rest of this file, wrapped in this namespace.
variable _in_namespace
set _in_namespace 1
source $::srcdir/lib/tuiterm.exp
unset _in_namespace
return
}
}
variable ...
...
but this was considered unnecessarily complex.
Fix this in the style of lib/ton.tcl and lib/completion-support.exp:
- only declare the variables in the namespace, and
- define the procs using a Term:: prefix.
As a side-effect, this works around an emacs bug that makes editing
lib/tuiterm.exp in its current form problematic because the auto-indentation
keeps removing required indentation of all but the first proc [1].
Tested on x86_64-linux.
[1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-11/msg01674.html
|
|
On x86_64-freebsd, with test-case gdb.tui/main.exp, I ran into a failure to
match the output of the file command, for which I submitted a patch [1].
However, after switching to TERM=ansiw for bsd, I could no longer reproduce
the problem.
Investigation showed that the difference was caused by CLI styling.
A command:
...
(gdb) file <filename>
...
gives an output:
...
Reading symbols from <filename>...
(gdb)
...
On x86_64-linux, with CLI styling I get:
...
Reading symbols from ^[[32m/data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.tui/main/main^[[39m^[[0;10m...
...
After disabling CLI styling using "set style enabled off", I simply get:
...
Reading symbols from /data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.tui/main/main...
...
and run into the same failure as on x86_64-freebsd.
The extra csi sequence "^[[32m" causes an additional matching attempt in
Term::wait_for, and the way we're currently matching relies on this:
...
send_gdb "file [standard_output_file $testfile]\n"
gdb_assert { [Term::wait_for "Reading symbols from"] } "file command"
...
Make the TUI testsuite more stable and matching more simple by disabling CLI
styling by default, and:
- fix the resulting fallout in test-cases gdb.tui/main.exp and
gdb.tui/new-layout.exp, and
- re-enable CLI styling in the one test-case that needs it:
gdb.tui/tui-disasm-styling.exp.
Tested on x86_64-linux.
[1] https://sourceware.org/pipermail/gdb-patches/2025-June/218942.html
|
|
On x86_64-freebsd, I run into:
...
Box Dump (80 x 24) @ (0, 0):
0 (gdb) maint info screen
1 Number of characters gdb thinks are in a line is 90.
2 Number of characters readline reports are in a line is 89.
3 Number of characters curses thinks are in a line is 90.
4 Number of characters environment thinks are in a line is 90 (COLUMNS).
5 Number of lines gdb thinks are in a page is 40.
6 Number of lines readline reports are in a page is 40.
7 Number of lines curses thinks are in a page is 40.
8 Number of lines environment thinks are in a page is 40 (LINES).
9 Readline wrapping mode: readline (terminal is not auto wrap capable, last column
10 .
11 (gdb) tui disable
12 (gdb) tui disable
13 (gdb) maint info screen
14
15
16
17
18
19
20
21
22
23
FAIL: gdb.tui/resize-2.exp: again: curses width 80
...
The problem is that the prompt matching in Term::wait for is not strict enough.
It will accept a line:
...
(gdb) foo
...
as long as the cursor is pointing just after the prompt, like so:
...
(gdb) foo
^
...
Fix this by also checking that the line is empty.
Tested on x86_64-linux.
|
|
With a gdb build with gcc 15.1.1 and "-O2 -flto=auto -g", I run into:
...
UNTESTED: gdb.gdb/selftest.exp: \
Cannot set breakpoint at captured_main, skipping testcase.
UNTESTED: gdb.gdb/python-helper.exp: \
Cannot set breakpoint at captured_main, skipping testcase.
...
I don't know why we're trying to stop in captured_main.
Stopping in main also works, and main is more likely to be present in an lto
build.
Fix this by using main instead.
This requires us to update the expected file name from main.c to gdb.c in
selftest_setup.
After doing so, we get:
...
XFAIL: gdb.gdb/selftest.exp: \
run until breakpoint at main (line numbers scrambled?)
XFAIL: gdb.gdb/python-helper.exp: \
run until breakpoint at main (line numbers scrambled?)
...
because main is reported to be in run-on-main-thread.c instead of gdb.c:
.
Breakpoint 1, main (...) at gdb/run-on-main-thread.c:120^M
...
This is due to picking the last line entry for pc == 0x455e40 that has
is_stmt == true:
...
File name Line number Starting address View Stmt
gdb/gdb.c:
gdb.c 25 0x455e40 x
gdb.c 30 0x455e40 1 x
gdb/run-on-main-thread.c:
run-on-main-thread.c 116 0x455e40 2 x
run-on-main-thread.c 120 0x455e40 3 x
gdb/gdb.c:
gdb.c 25 0x455e40 4
/usr/include/c++/15/bits/std_thread.h:
std_thread.h 366 0x455e4b
...
While we're at it, update the corresponding gdb_test_multiple in
selftest_setup using multi_line and -wrap.
Tested on x86_64-linux.
|
|
PR cli/21690 reports the following: say we start gdb:
...
$ gdb -q
(gdb)
...
and press ^R for reverse-i-search:
...
(reverse-i-search)`':
...
Pressing the p key has the effect of showing both the pressed key and a
matching entry, which happens to be up:
...
(reverse-i-search)`p': up
...
Now we press ^C to cancel the search:
...
(reverse-i-search)`p': u❌️ Quit
(gdb)
...
and type "down".
We expected to get:
...
(gdb) down
...
but instead we get:
...
(failed reverse-i-search)`pdown':
...
So we're stuck in reverse-i-search, until we use the workaround of ^G.
The same problem happened with python [1], was reported upstream [2], and
fixed in cpython commit d6990d221b0 ("Issue #24266: Cancel history search mode
with Ctrl+C in Readline 7") using rl_callback_sigcleanup.
Fix this likewise in quit using rl_callback_sigcleanup, a new callback
function in readline 7.0:
...
i. rl_callback_sigcleanup: a new application function that can clean up and
unset any state set by readline's callback mode. Intended to be used
after a signal.
...
giving us instead:
...
$ gdb
(gdb) u❌️ Quit
(gdb) down
...
Remove the corresponding kfail in gdb.tui/pr30056.exp.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21690
[1] https://bugs.python.org/issue24266
[2] https://lists.gnu.org/archive/html/bug-readline/2015-05/msg00014.html
|
|
In test-case gdb.base/watchpoint-unaligned.exp, in function write_size8twice,
two adjacent 8-byte vars are written. For aarch64, we use a single stp
instruction for that.
If we do the same in function read_size8twice for two adjacent 8-byte var reads
using aarch64 insn ldp, on an aarch64-linux M1 system we get a hang:
...
(gdb) continue^M
Continuing.^M
FAIL: $exp: fun=read_size8twice: offset=0: index=1: continue (timeout)
FAIL: $exp: fun=read_size8twice: offset=0: index=1: $got_hit
...
The same problem was observed for stp in PR tdep/29423, fixed by commit
9a03f218534 ("[gdb/tdep] Fix gdb.base/watchpoint-unaligned.exp on aarch64").
See that commit for an explanation of the hang.
That commit introduced max_access_size in aarch64_stopped_data_address:
...
The access size also can be larger than that of the watchpoint
itself. For instance, the access size of an stp instruction is 16.
So, if we use stp to store to address p, and set a watchpoint on
address p + 8, the reported ADDR_TRAP can be p + 8 (observed on
RK3399 SOC). But it also can be p (observed on M1 SOC). Checking
for this situation introduces the possibility of false positives,
so we only do this for hw_write watchpoints. */
const CORE_ADDR max_access_size = type == hw_write ? 16 : 8;
...
If we say that hangs are worse than false positives, then we should also fix
this case.
Fix this by setting max_access_size to 16 for all watchpoint types.
Tested on aarch64-linux, both on an M1 SOC and an RK3399 SOC.
Approved-By: Luis Machado <luis.machado.foss@gmail.com>
|
|
Extend the part of gdb.base/watchpoint-unaligned.exp handling
write_size8twice to also check read hardware watchpoints.
Tested on x86_64-linux.
Approved-By: Luis Machado <luis.machado.foss@gmail.com>
|
|
Improve the part of gdb.base/watchpoint-unaligned.exp handling
write_size8twice:
- move the code into a proc
- use -wrap
- use $decimal more often
- don't use gdb_test_multiple $test $test
- add comments
- start test when entering write_size8twice function, instead of main
- finish test when leaving write_size8twice function, instead of main
- add insn in between:
- insn triggering watchpoint, and
- insn triggering breakpoint
to ensure that the watchpoint triggers before the breakpoint, and
add a comment explaining this.
Tested on x86_64-linux.
|
|
A buildbot pointed out that my changes to gdb.dap/scopes.exp caused a
test failure. The new code iterates over all the registers, fetching
their children (when possible). The failure comes because this code
failed to consider that a register might have "indexed" children,
which I believe can occur when a register is vector-like.
This patch fixes the problem by arranging to fetch indexed children
when indicated.
|
|
PR dap/33228 points out a failure that occurs when the DAP client
requests more children of a variable than actually exist. Currently,
gdb throws a somewhat confusing exception. This patch changes this
code to throw a DAPException instead, resulting in a more ordinary and
readable failure.
The spec seems to be silent on what to do in this case. I chose an
exception on the theory that it's easier to be strict now and lift the
restriction later (if needed) than vice versa.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33228
|
|
While investigating a different bug, I noticed that the DAP code would
report a "void *"-typed register as having children -- however,
requesting the children of this register would fail.
The issue here is that a plain "void *" can't be dereferenced. This
patch changes the default visualizer to treat a "void *" as a scalar.
This adds a new test; but also arranges to examine all the returned
registers -- this was the first thing I attempted and it seemed
reasonable to have a test that double-checks that all the registers
really can be dereferenced as appropriate.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33228
|
|
should_validate_memtags uses value_as_address to evalute
whether an address for a value is tagged. The comments for
that function simply say, "Extract a value as a C pointer."
While that sounds innoncuous, that function calls coerce_array,
which will dereference any references. This is not what is
desired here.
This can be demonstrated on an MTE-enabled host, such as aarch64-
based Ampere (example taken from tests introduced in this patch):
(gdb) p b.get_foo ()
Could not validate memory tag: Value can't be converted to integer.
$2 = (const foo &) @0xffffffffed88: {m_a = 42}
While the command completes, gdb didn't actually attempt to
evaluate any memory tags.
Fix this by using unpack_pointer instead.
Tested on x86_64 Fedora 40 and aarch64 RHEL 9.6.
|
|
With test-case gdb.tui/basic.exp and TERM=ansis, I run into (with some logging
added):
...
status line: '<reverse:1><intensity:dim>exec No process (asm) In:
L?? PC: ?? <reverse:0><intensity:normal>'
FAIL: gdb.tui/basic.exp: status window: reverse
...
The status window uses ncurses attribute standout, which can differ between
different terminal settings.
Fix this by making the matching less strict.
Tested on x86_64-linux.
|
|
When running test-case gdb.tui/main-2.exp with TERM=ansis, I get:
...
screen line 6: 'B+><fg:black><intensity:bold> 21 <reverse:1><fg:default><intensity:normal> return 0;<reverse:0> '
FAIL: gdb.tui/main-2.exp: highlighted line in middle of source window
...
The test tries to check the highlighting of the source line, but also gets the
part with the line number, which makes it more complicated to parse.
Fix this by getting just the part with the source line:
...
screen line 6: '<reverse:1> return 0;<reverse:0> \
'
...
Tested on x86_64-linux.
|
|
While investigating using TERM=ansiw for freebsd, I also came across
TERM=ansis which unlike ansiw is present on both linux and freebsd.
Add initial support for TERM=ansi in tuiterm:
- handle ansis in Term::_have_bw
- add Term::_csi_x to support (well, ignore) DECREQTPARM
(Request Terminal Parameters)
This is sufficient to make the TUI testsuite pass on x86_64-freebsd.
|
|
The test-case gdb.tui/tui-layout-asm-short-prog.exp uses an assembly file
gdb.tui/tui-layout-asm-short-prog.S that it compiles using -nostdlib and
-nostartfiles.
However, on x86_64-linux the resulting executable still has dependencies on
libm and libc:
...
$ ldd outputs/gdb.tui/tui-layout-asm-short-prog/tui-layout-asm-short-prog
linux-vdso.so.1 (0x00007ffddf3ec000)
libm.so.6 => /lib64/libm.so.6 (0x00007f8b13406000)
libc.so.6 => /lib64/libc.so.6 (0x00007f8b13000000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8b1350f000)
...
due -lm being added by default_target_compile.
On x86_64-freebsd, using -nostdlib and -nostartfiles in combination with -lm
causes the compilation to fail.
Fix this by using -static as well.
Tested on x86_64-linux and x86_64-freebsd.
|
|
On x86_64-freebsd, with test-case gdb.base/exprs.exp I get:
...
(gdb) print 23
yydebug: state 0, reading 257 (INT)
yydebug: state 0, shifting to state 1
yydebug: state 1, reducing by rule 94 (exp : INT)
yydebug: after reduction, shifting from state 0 to state 59
yydebug: state 59, reading 0 (end-of-file)
yydebug: state 59, reducing by rule 7 (exp1 : exp)
yydebug: after reduction, shifting from state 0 to state 60
yydebug: state 60, reducing by rule 1 (start : exp1)
yydebug: after reduction, shifting from state 0 to state 58
$220 = 23
(gdb) FAIL: gdb.base/exprs.exp: print with debugging
...
The test fails because it's not finding the string "Starting parse".
In this case, the .y files are processed used byacc. I suppose the testcase
matches the case that bison is used.
Fix this by grepping for something more generic: shift or Shift.
Tested on x86_64-linux and x86_64-freebsd.
|
|
After updating the documentation in commit cf03713dd1c ("[gdb/cli] Document
\001 and \002 usage for set prompt"), I started to wonder if I could reproduce
the CLI issue described in PR cli/28887 using the TUI.
That turned out not to be the case, but I noticed handling of the markers in
tui_puts and tui_puts_internal, and no test-case exercising this, so I
decided to add this.
After doing so in gdb.tui/color-prompt.exp, I realized I could use the same
code to test the CLI case.
Add test-case gdb.base/color-prompt.exp that shares code with
gdb.tui/color-prompt.exp in gdb.tui/color-prompt.exp.tcl.
For the CLI case, I was hoping to reproduce the behaviour described in the PR,
but it didn't trigger.
FTR, I manually reproduced the behaviour and used script to record it. I
observed the following sequence after the C-a:
- ^M (CR) : go to start of line
- ^[[K (EL) : erase line
- ^M (CR) : go to start of line
- ^[[31m(gdb) ^[[0m : output prompt
- some long command : output text
- ^M (CR) : go to start of line
- ^[[C, 15 times (CUF): cursor forward 15 times
giving me:
...
(gdb) some long command
^
...
Perhaps we'll trigger this on some other os, or once we start using a
different TERM value.
Tested on x86_64-linux.
|
|
In ppc64_sysv_abi_return_value I came across this if clause:
...
/* Small character arrays are returned, right justified, in r3. */
if (valtype->code () == TYPE_CODE_ARRAY
&& !valtype->is_vector ()
&& valtype->length () <= 8
&& valtype->target_type ()->code () == TYPE_CODE_INT
&& valtype->target_type ()->length () == 1)
...
I decided to write a test-case to try and trigger this.
AFAIU, in C/C++, we're not allowed to return an array, so I wrote an Ada
test-case instead, with a function returning this type:
...
type T is new String (1 .. 4);
...
After doing so I realized that the clause above is not triggering because
valtype->target_type ()->code () == TYPE_CODE_CHAR. Fix this by allowing
both TYPE_CODE_INT and TYPE_CODE_CHAR.
Then I realized that the specific "small character array" handling comes from
the v1 abi. Add a check for this as well.
Tested on ppc64le-linux, with v2 abi.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
While trying out gccrs, I noticed that gdb_simple_compile does not use
the ".rs" extension for Rust sources. This patch fixes the problem,
which lets gccrs get a little further in the test suite.
|
|
The ANSI escape sequence translation layer in TUI mode strips italic
or underlined text modes silently. You cannot output text formatted
like that using `TuiWindow.write` in Python at the moment.
Parse the ANSI escape sequences for italic and underlined text into
the `ui_file_style` structure and apply it to the TUI window when
applying styles, similar to preserving the bold/dim state already.
A script like this shows italic and underlined text correctly now.
```python
import gdb
class TestTUIWindow:
_tui_window: gdb.TuiWindow
def __init__(self, tui_window: gdb.TuiWindow) -> None:
self._tui_window = tui_window
self._tui_window.title = "colors test"
def render(self) -> None:
self._tui_window.write("""
\x1b[4mThis is underlined.\x1b[24m And normal text.
\x1b[3mThis is italic.\x1b[23m And normal text.
""", True)
gdb.register_window_type("colortest", TestTUIWindow)
```
And launching it with
```
source the_above_script.py
tui new-layout test colortest 1 cmd 1
layout test
```
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On x86_64-freebsd, with test-case gdb.base/style.exp I run into:
...
(gdb) print $_colorsupport
[36;49;22;27m$1[m = "monochrome"
(gdb) FAIL: $exp: colorsupport_8color: color support is 8 color
...
Fix this by applying the same fix as for tuiterm: use TERM=ansiw instead of
TERM=ansi for bsd, getting us instead:
...
(gdb) print $_colorsupport
[36;49;22;27m$1[m = "monochrome,ansi_8color"
(gdb) PASS: $exp: colorsupport_8color: color support is 8 color
...
Tested on x86_64-freebsd.
|
|
This patch started as a fix for PR 29518 ("GDB doesn't handle
DW_FORM_ref_addr DIE references correctly with .debug_types sections")
[1], but the scope has expanded a bit to fix the problem more generally,
after I spotted a few issues related to the order of all_units. The
first version of this patch is here [2].
PR 29518 shows that dwarf2_find_containing_comp_unit can erroneously
find a type unit. The obvious problem is that the
dwarf2_find_containing_comp_unit function searches the whole all_units
vector (containing both comp and type units), when really it should just
search the compilation units. A simple solution would be to make it
search the all_comp_units view (which is removed in a patch earlier in
this series).
I then realized that in DWARF 5, since type units are in .debug_info
(versus .debug_types in DWARF 4), type units can be interleaved with
comp type in the all_units vector. That would make the all_comp_units
and all_type_units views erroneous, and dwarf2_find_containing_comp_unit
could still return something wrong. In v1, I added a sort in
finalize_all_units to make sure all_units is in the order that
dwarf2_find_containing_comp_unit expects:
- comp units from the main file
- type units from the main file
- comp units from the dwz file
- type units from the dwz file (not actually supported, see PR 30838)
Another problem I spotted is that the .gdb_index reader creates units in
this order:
- comp units from .gdb_index from main file
- comp units from .gdb_index from dwz file
- type units from .gdb_index from main file
This isn't the same order as above, so it would need the same sort step.
Finally, I'm not exactly sure if and when it happens, but it looks like
lookup_signatured_type can be called at a later time (after the initial
scan and creation of dwarf2_per_cu object creation), when expanding a
symtab. And that could lead to the creation of a new type unit (see
function add_type_unit), which would place the new type unit at the end
of the all_units vector, possibly screwing up the previous order.
To handle all this in a nice and generic way, Tom Tromey proposed to
change the all_units order, so that units are sorted by section, then
section offset. This is what this patch implements. The sorting is
done in finalize_all_units.
This works well, because when looking up a unit by section offset, the
caller knows which section the unit is in. Passing down a (section,
section offset) tuple makes it clear and unambiguous what unit the
caller is referring to. It should help eliminate some bugs where the
callee used the section offset in the wrong section. Passing down the
section along with the section offset replaces the "is_dwz" flag passed
to dwarf2_find_containing_comp_unit and a bunch of other functions in a
more general way.
dwarf2_find_containing_comp_unit can now legitimately find and return
type units even though it should be needed (type units are typically
referred to by signature). But I don't think there is harm for this
function to be more generic than needed. I therefore I renamed it to
dwarf2_find_containing_unit.
The sort criterion for "section" can be anything, as long as we use the
same for sorting and searching. In this patch, I use the pointer to
dwarf2_section_info, because it's easy. The downside is that the actual
order depends on what the memory allocator decided to return, so could
change from run to run, or machine to machine. Later, I might change it
so that sections are ordered based on their properties, making the order
stable across the board. This logic is encapsulated in the
all_units_less_than function, so it's easy to change.
The .debug_names reader can no longer rely on the order of the all_units
vector for its checks, since all_units won't be the same order as found
in the .debug_names lists. In fact, even before, it wasn't: this check
assumed that .debug_info had all CUs before TUs, and that the index
listed them in the exact same order. When I build a file with gcc and
"-gdwarf-5 -fdebug-types-section", type units appear first in
.debug_info. This caused GDB to reject a .debug_names index that is had
produced:
$ GDB="./gdb -nx -q --data-directory=data-directory" /home/smarchi/src/binutils-gdb/gdb/contrib/gdb-add-index.sh -dwarf-5 hello.so
$ ./gdb -nx -q --data-directory=data-directory hello.so
Reading symbols from hello.so...
⚠️ warning: Section .debug_names has incorrect entry in CU table, ignoring .debug_names.
To make it work, add a new dwarf2_find_unit function that allows looking
up a unit by start address (unlike dwarf2_find_containing_unit, which
can find by any containing address), and make the .debug_names reader
use it. It might make the load time of .debug_names a bit longer (the
build and check step is now going to be O(n*log(n)) instead of O(n)
where n is the number of units, or something like that), but I think
it's important to be correct here.
This patch adds a test
(gdb.dwarf2/dw-form-ref-addr-with-type-units.exp), which tries to
replicate the problem as shown by PR 29518.
gdb.base/varval.exp needs a small change, because an error message
changes (for the better, I think)
gdb.dwarf2/debug-names-non-ascending-cu.exp now fails, because GDB no
longer rejects a .debug_names index which lists CUs in a different order
than .debug_info. Given the change I did to the .debug_names reader,
explained above, I don't think this is a problem anymore (GDB can accept
an index like that). I also don't think that DWARF 5 mandates that CUs
are in ascending order. Delete this test.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=29518
[2] https://inbox.sourceware.org/gdb-patches/20250218193443.118139-1-simon.marchi@efficios.com/
Change-Id: I45f982d824d3842ac1eb73f8cce721a0a24b5faa
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I found a line in tuiterm.exp that causes Emacs paren-matching to go
awry. This patch fixes the problem by changing some apparent nested
double quotes (which I think isn't really possible in Tcl but this
seems to be the intent) to be more correct; which fixes the Emacs
issue as well.
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
With a gdb build with gcc 7.5.0 and "-O2 -flto=auto -g", I run into:
...
(outer-gdb) PASS: gdb.gdb/python-helper.exp: print varobj_table
print inferior_list
$5 = {m_front = 0x212e830, m_back = 0x2e39aa0}
(outer-gdb) FAIL: gdb.gdb/python-helper.exp: print inferior_list
...
The problem is that the type of inferior_list:
...
(outer-gdb) what inferior_list^M
type = intrusive_list^M
(outer-gdb)
...
is not descriptive enough to trigger the pretty pretter.
Note that with a gdb build with -O0, we'd get instead:
...
(outer-gdb) what inferior_list^M
type = intrusive_list<inferior, intrusive_base_node<inferior> >
(outer-gdb)
...
Fix this by detecting this situation, and declaring the test unsupported.
Tested on x86_64-linux.
|
|
While working on gnat-llvm, gdb.ada/operator_call.exp has many
timeouts. This happens because gnat-llvm's DWARF output is still
incomplete, and so gdb emits an unexpected error in this test.
This patch improves the test by having it recognize this output and
issue a failure rather than a timeout. This greatly speeds up
testing.
|
|
While reading a gdb.log for test-case gdb.tui/main-2.exp, I noticed that this
line was somewhat hard to read:
...
screen line 6: '<fg:cyan><intensity:bold>|<fg:default><intensity:normal>B+> 21 <reverse:1> return 0;<reverse:0> <fg:cyan><intensity:bold>|<fg:default><intensity:normal>'
...
because of the border attributes.
Then I realized that the test-case is only interested in the text between the
borders, so I added a proc Term::get_string_with_attrs that allows me to drop
the borders, getting us instead:
...
screen line 6: 'B+> 21 <reverse:1> return 0;<reverse:0> '
...
Tested on aarch64-linux.
|
|
TERM=ansi is different on freebsd and linux. Consequently, many TUI
test-cases (gdb.tui/*.exp and gdb.python/tui*.exp) fail on freebsd.
One of the problems is that send_gdb "<cmd>\r\n" is needed instead of
send_gdb "<cmd>\n".
This is because gdb_send "layout regs\n" translates to
"layout regs<KEY_DOWN>", which evidently missing the carriage return part.
While we can work around this, there are other problems. There is no color
support, and the cursor keys fail to scroll the source window.
So I went looking for an alternative to TERM=ansi on freebsd, and came across
TERM=ansiw. Using this didn't work out of the box, but with the fixes in
this series it now does.
I also briefly looked at TERM=ansis, which is interesting because it's
available on both linux and freebsd, but ansiw is a better choice for now.
I've filed PR33179 to document what I learned, with the aim to eventually
follow up and address two test-case failures with TERM=ansis on linux.
Tested on x86_64-freebsd.
|
|
Proc Term::_log_cur logs the cursor update of code in its body argument:
...
proc _ctl_0x08 {} {
_log_cur "Backspace" {
variable _cur_col
if {$_cur_col > 0} {
incr _cur_col -1
}
}
}
...
giving us for instance:
...
+++ Backspace, cursor: (2, 0) -> (2, 0)
...
But if we rewrite the code to use a return:
...
if { $_cur_col == 0 } {
return
}
incr _cur_col -1
...
and the return is triggered, the log message disappears.
Fix this by wrapping the "uplevel $body" in a catch:
...
- uplevel $body
+ set code [catch {uplevel $body} result]
...
Tested on aarch64-linux.
|
|
When calling Term::_csi_m with no args, default behaviour needs to be applied,
which is equivalent to "Term::_csi_m 0" [1].
However, while "Term::_csi_m 0" works, as well as 'Term::_csi_m ""', calling
Term::_csi_m with no args has no effect.
Fix this by implementing the default behaviour in Term::_csi_m.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://vt100.net/docs/vt510-rm/SGR.html
|
|
The terminal capability bw (aka as auto_left_margin) controls whether a
backspace at the start of a line wraps to the last column of the previous
line.
For tuiterm, we use TERM=ansi, and on linux at least that capability is off.
Consequently the current implementation of Term::_ctl_0x08 doesn't wrap.
Add this capability in Term::_ctl_0x08, and add a unit test.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I ran the tui testsuite on freebsd with TERM=ansiw, and investigated the first
failure, in test-case gdb.tui/tui-init-source.exp.
The problem turned out to be the lack of handling a Horizontal Position
Absolute [1] sequence "^[[80`" in tuiterm.
Add Term::_csi_`, forwarding to Term::_csi_G which handles Cursor Horizontal
Absolute [2].
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://vt100.net/docs/vt510-rm/HPA.html
[2] https://vt100.net/docs/vt510-rm/CHA.html
|
