| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
When the PikeOS osabi sniffer was added, Pedro suggested that a target
could omit stepping from its vCont? reply packet to tell gdb that
software single-step must be used:
https://sourceware.org/legacy-ml/gdb-patches/2018-09/msg00312.html
This patch implements this idea by moving the call to
target_can_do_single_step into maybe_software_singlestep.
I've also removed some FIXME comments from gdbarch_components.py, and
slightly updated the documentation for gdbarch_software_single_step.
I think these comments are somewhat obsolete now that
target_can_do_single_step exists -- the current approach isn't exactly
what the comments intended, but on the other hand, it exists and
works.
Following review comments from Andrew, this version changes
record-full to use maybe_software_singlestep, and then combines
maybe_software_singlestep with insert_single_step_breakpoint.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28440
|
|
|
|
|
|
Update some entries in the gdb/MAINTAINERS file.
|
|
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>
|
|
The order of all_units can't be relied on when writing the CU and TU
lists to .gdb_index or .debug_names.
Both the .gdb_index and .debug_names writers expect that all_units
contains comp units followed by type units. As of this commit, when
reading a DWARF 5 .debug_info, the all_units vector is ordered based on
the order the units appear in .debug_info, where type units can be
interleaved with comp units.
It probably worked fine with DWARF 4, where type units were in a section
of their own (.debug_types). They were read after comp units, and
therefore after them in the all_units vector.
Change the writers to use a common function that splits the units in two
lists (comp units and type units). Sort both lists by section offset.
This is more than required, but it should help produce a stable and
predictable output.
Change-Id: I5a22e2e354145e3d6b5b2822dc2a3af2f9d6bb76
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The .gdb_index reader currently uses per_bfd::all_units when translating
a numerical index (as found in an index entry) to a dwarf2_per_cu. The
order of per_bfd::all_units is going to change in a subsequent patch, so
the indices as found in the index won't map to the right unit in
all_units. Change the .gdb_index reader to maintain its own vector,
with the units in the same order as found in the .gdb_index header.
This is similar to what the .debug_names reader does. But unlike
.debug_names, .gdb_index treats the CUs and TUs as a single list, as far
as the numerical indices are concerned, so we only need a single list
here (versus two for .debug_names).
Change-Id: I235e9b99bf02fc160dfcdaa610c9aca471f298a7
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The all_comp_units_index_cus and all_comp_units_index_tus vectors
contain the CU and TU lists as found in the .debug_names list. It seems
like they are meant to be used by the .debug_names reader when handling
a DW_IDX_compile_unit or DW_IDX_type_unit attribute. The value of the
attribute would translate directly into an index into one of these
vectors.
However, it looks like these vectors aren't actually used in practice.
They are used in the dwarf2_per_bfd::get_index_{c,t}u methods, which in
turn aren't used anywhere.
The handlers of DW_IDX_compile_unit and DW_IDX_type_unit use the
dwarf2_per_bfd::get_unit method, with the assumption that
dwarf2_per_bfd::all_units has comp units before type units. This is not
the case: the .debug_names reader creates the units in
dwarf2_per_bfd::all_units using the create_all_units function, which
creates the units in the order found in .debug_info, where type units
can be interleaved with comp units.
Since those vectors are specific to the .debug_names reader, move them
to the mapped_debug_names_reader struct. Then, update the handlers of
DW_IDX_compile_unit and DW_IDX_type_unit to actually use them.
Change-Id: Ie7db81f4442f634ac6d02280a60c6c671bcd22a5
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In DWARF 5, type units appear in the .debug_info section, interleaved
with comp units, and the order in all_units reflects that. The
all_comp_units and all_type_units views are wrong in that case
(all_comp_units contains some type units, and vice-versa).
It would be possible to manually sort all_units to ensure that type
units follow comp units, but this series takes the approach of sorting
the units by section and section offset.
Remove those views, and replace their uses with num_comp_units and
num_type_units. It appears that the views were only used to know the
number of each kind.
The finalize_all_units function is now empty, but I am keeping it
because a subsequent patch adds a call to std::sort in there to sort the
all_units vector.
Change-Id: I42a65b6f1b6192957b55cea0e2eaff097e13a33b
Approved-By: Tom Tromey <tom@tromey.com>
|
|
A subsequent commit will remove the all_comp_units and all_type_units
array views, since it's not possible to assume that that all_units
vector is segmented between comp and type units. Some callers still
need to know the number of each kind, so track that separately.
Change-Id: I712fbdfbf10b333c431b688b881cc0987e74f688
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.
|
|
In bash I have the following terminal settings:
...
$ stty
speed 38400 baud; line = 0;
-brkint -imaxbel iutf8
...
and then in gdb using the shell command likewise:
...
(gdb) shell stty
speed 38400 baud; line = 0;
-brkint -imaxbel iutf8
(gdb)
...
and likewise using a shell session:
...
(gdb) shell
$ stty
speed 38400 baud; line = 0;
-brkint -imaxbel iutf8
$
...
But in TUI, we get different settings (removed runaway indentation for
readability):
...
(gdb) shell sttyspeed 38400 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel iutf8
-onlcr
-icanon -echo
(gdb)
...
and consequently the shell is not really usable. This is PR tui/18215.
The easiest way to fix this is to just temporarily leave TUI while in the shell,
leaving the output of the commands in CLI mode, but that's a bit confusing.
Fix this (as suggested in the PR) by restoring the initial terminal settings
while in the shell command, such that also in TUI we have:
...
(gdb) shell sttyspeed 38400 baud; line = 0;
-brkint -imaxbel iutf8
(gdb)
...
Tested on x86_64-linux.
Reported-By: Doug Evans <dje@google.com>
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18215
|
|
I noticed that my MinGW GDB did not have the "maint set
console-translation-mode" command, even though the code to register it
is in gdb/mingw-hdep.c.
The problem is that gdb/mingw-hdep.c is not using INIT_GDB_FILE. This
fixes it.
Change-Id: I3aa305c517e100d4733b391a110a1b20b89fdb7f
|
|
The "location_completer" function has been available for a long time,
but it was seemingly never used as the completer for the list function.
A quick check through git history shows that a similar completer was
available for the "edit" command but wasn't added to "list" with no
reasoning for it.
I think "list" should use the location_completer, as it is more aware of
the locspec grammar.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Change-Id: Ia03b286d9544a209197e58e59e752dc3d2715359
|
|
My mistake, I forgot to update this when merging my patch series.
Change-Id: I67691c962d91221bd9a684febd7296b4b9b5999f
|
|
constant block
Since commit 420d030e88 ("Handle field with dynamic bit offset"), I see:
$ make check TESTS="gdb.trace/unavailable-dwarf-piece.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d x
FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d y
FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d z
The first FAIL is:
p/d x
$4 = {a = 0, b = <unavailable>, c = <unavailable>, d = <unavailable>, e = <unavailable>, f = <unavailable>, g = <unavailable>, h = <unavailable>, i = <unavailable>, j = 0}
(gdb) FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d x
When we should see:
p/d x
$4 = {a = 0, b = <unavailable>, c = 0, d = 0, e = 0, f = 0, g = 0, h = 0, i = 0, j = 0}
(gdb) PASS: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d x
The structure we print is:
0x0000004f: DW_TAG_structure_type
DW_AT_name [DW_FORM_string] ("t")
DW_AT_byte_size [DW_FORM_sdata] (3)
DW_AT_decl_file [DW_FORM_udata] (0)
DW_AT_decl_line [DW_FORM_udata] (1)
0x00000055: DW_TAG_member
DW_AT_name [DW_FORM_string] ("a")
DW_AT_type [DW_FORM_ref4] (0x00000019 "unsigned char")
DW_AT_data_member_location [DW_FORM_exprloc] (DW_OP_plus_uconst 0x0)
0x0000005f: DW_TAG_member
DW_AT_name [DW_FORM_string] ("b")
DW_AT_type [DW_FORM_ref4] (0x00000019 "unsigned char")
DW_AT_byte_size [DW_FORM_sdata] (1)
DW_AT_bit_size [DW_FORM_sdata] (1)
DW_AT_bit_offset [DW_FORM_sdata] (7)
DW_AT_data_member_location [DW_FORM_exprloc] (DW_OP_plus_uconst 0x1)
...
The particularity of field "b" (and the following ones, not shown here)
is that they have:
- a DW_AT_data_member_location of expression form, but that GDB reduces
to a constant
- a DW_AT_bit_offset
What I think happens is that the code path taken in this particular
scenario never ends up using the DW_AT_bit_offset value. Fix it by
calling apply_bit_offset_to_field, like what is done when
data_member_location_attr is using a constant form.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33136
Change-Id: I18e838e6c56a548495d3af332aeff3051188eaa9
Approved-By: Tom Tromey <tom@tromey.com>
|
|
For legibility, use more specific names for attribute variables and
don't reuse them for different attributes.
Change-Id: I98d8bb32fc64b5f6357fbc88f6fe93f2ddc8ef7c
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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
|
|
I looked at the tuiterm implementation of Cursor Horizontal Absolute:
...
proc _csi_G {args} {
set arg [_default [lindex $args 0] 1]
_log_cur "Cursor Horizontal Absolute ($arg)" {
variable _cur_col
variable _cols
set _cur_col [expr {min ($arg - 1, $_cols)}]
}
}
...
and noticed a problem with the clipping behavior.
If we have say $_cols == 80, and we do _csi_G 81 we get $_cur_col == 80, while
$_cur_col is zero-based and should be in the 0..79 range.
Fix this by using:
...
set _cur_col [expr {min ($arg, $_cols)} - 1]
...
which gets us $_cur_col == 79.
Add two boundary tests to gdb.tui/tuiterm.exp.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I wanted to change one of these, so I searched for more similar
instances, while at it. I think this looks a bit tidier, over unpacking
the pairs by hand.
Change-Id: Ife4b678f7a6aed01803434197c564d2ab93532a7
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Modernize test-case gdb.base/command-line-input.exp using clean_restart,
multi_line and string_to_regexp.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Gdb has the ability to gather input over several lines [1], for instance this:
...
(gdb) print 1
$1 = 1
(gdb)
...
can also be typed as:
...
(gdb) print\
1
$2 = 1
(gdb)
...
Furthermore, if we type a command but change our mind, we can abort using ^C
and start over using a fresh gdb prompt [2]:
...
(gdb) print 1❌️ Quit
(gdb) echo 1\n
1
(gdb)
...
Now say we type a multi-line command but abort it, we get:
...
(gdb) print\
1❌️ Quit
(gdb) echo 1\n
❌️ Undefined command: "printecho". Try "help".
(gdb)
...
Using "set trace-commands on", we can see what happened:
...
+printecho 1\n
..
Gdb has prepended the first line of the cancelled multi-line command to the
following command.
Fix this by clearing current_ui->line_buffer on catching a gdb_exception in
start_event_loop.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR cli/33063
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33063
[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Output.html
[2] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Quitting-GDB.html
|
|
As I was working on an unrelated patch, I noticed that all calls to
make_source_files_completion_list had both parameters of the function
call being the same pointer. I think we can remove that redundancy and
make that call with just one parameter.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Change-Id: I63f78f359f55ec15fb3296a1a9ce28c9d01d663b
|
|
Change-Id: I02c7daed3740e319ee27d3512a2b941f666b103b
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
I found these two small nits while working in this file.
Change-Id: Ibdaa57262f3fe363b039fbad746e285fa7b52f8b
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Running the standalone test `gdb.reverse` with the target board configuration `unix/-fPIE/-pie` leads to the following failure:
'''
FAIL: gdb.reverse/i386-avx-reverse.exp: verify ymm15 before vbroadcastsd
'''
This happens because the test expects values stored in `dyn_buf0`, but instead (in the test source) the address of the buffer itself
got broadcast to xmm15 (and thus to ymm15).
This happened because the pointer to the start of `dyn_buf0` wasn't dereferenced (see 'vpbroadcast_test' in 'i386-avx-reverse.c'):
'''
asm volatile ("vbroadcastss %0, %%xmm15": : "m" (dyn_buf0));
^
'''
and this consequently lead to the test failing for the next instruction (`vbroadcastsd`), which depended on the correct value being broadcast to the register.
Also, updated the corresponding expected output (gdb.reverse/i386-avx-reverse.exp) to match.
Tested on x86-64 Linux.
Signed-off-by: Shiven Kashyap <shivenkashyap24@gmail.com>
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
Remove a bunch of includes reported as unused by clangd.
Change-Id: I3f05f98a298036fadf1acce4ddc198405ec056ee
|
|
The type is already lm_info_svr4.
Change-Id: Id681eb1685462610b202c76147739ac885555f6b
|
|
These method declarations are unused, remove them. I guess that when
writing a previous patch, changed some free functions to be methods,
then changed my mind, and forgot to remove the declarations.
Change-Id: I7452bb773af0f32c4aae2fe6a4fc663ec65c3f15
|
|
PR cli/28887 reports the following problem when using a custom prompt.
First, we set up the custom prompt (with ^ marking the position of the
blinking cursor on the line above):
...
$ gdb -q -ex "set prompt \033[31mgdb$ \033[0m"
gdb$
^
...
Then we type some string, and enter it into the command history:
...
gdb$ some long command
❌️ Undefined command: "some". Try "help".
gdb$
^
...
We use C-p to fetch the previous command:
...
gdb$ some long command
^
...
Sofar, so good.
Finally, we use C-a which should move the cursor to just after the prompt, but
instead we get:
...
gdb$ some long command
^
...
This is fixed by using \001 and \002:
...
(gdb) set prompt \001\033[31m\002gdb$ \001\033[0m\002
...
aka as RL_PROMPT_START_IGNORE and RL_PROMPT_END_IGNORE [1].
Add an example to the documentation showing the use of these markers.
The added example is the equivalent of the "\[\e[0;34m\](gdb)\[\e[0m\]"
example documented at gdb.prompt.substitute_string that can be used with
"set extended-prompt".
While working on this, I noticed that "show prompt" doesn't show back the
original string, using '\e' instead of '\033':
...
gdb$ show prompt
Gdb's prompt is "\001\e[31m\002gdb$ \001\e[0m\002".
...
and that the shown string can't be used as an argument to "set prompt":
...
gdb$ set prompt \001\e[31m\002gdb$ \001\e[0m\002
e[31mgdb$ e[0m
...
I've filed this as PR cli/33184.
Approved-By: Eli Zaretskii <eliz@gnu.org>
[1] https://tiswww.case.edu/php/chet/readline/readline.html
|
|
I noticed that the test names in test-case
gdb.base/backtrace-through-cu-nodebug.exp are a bit inconsistent:
...
PASS: $exp: no-cfi: maint frame-unwinder disable ARCH
PASS: $exp: verify no-filters unwind fail without CFI
PASS: $exp: maint flush register-cache
PASS: $exp: verify unwind fail without CFI
PASS: $exp: cfi: maint frame-unwinder disable ARCH
PASS: $exp: Verify unwinding works based only on CFI information
...
There's both a no-cfi prefix, and "without CFI".
Fix this by using proc_with_prefix, getting us a consistent prefix:
...
PASS: $exp: no-cfi: maint frame-unwinder disable ARCH
PASS: $exp: no-cfi: verify no-filters unwind fail
PASS: $exp: no-cfi: maint flush register-cache
PASS: $exp: no-cfi: verify unwind fail
PASS: $exp: cfi: maint frame-unwinder disable ARCH
PASS: $exp: cfi: Verify unwinding works
...
While we're at it, use multi_line to make a regexp more readable.
Tested on aarch64-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
support
With a gdb build without python support, and test-case
gdb.base/backtrace-through-cu-nodebug.exp I run into:
...
(gdb) bt^M
Required frame unwinder may have been disabled, \
see 'maint info frame-unwinders'^M
(gdb) FAIL: $exp: verify unwind fail without CFI
...
With a gdb build with python support we have instead:
...
(gdb) bt^M
Python Exception <class 'gdb.error'>: \
Required frame unwinder may have been disabled, \
see 'maint info frame-unwinders'^M
(gdb) PASS: $exp: verify unwind fail without CFI
...
but if I change the "bt" into "bt -no-filters" I get the same FAIL and
corresponding output.
So there are two scenarios here.
In the first:
- the bt command is called
- frame #0 is printed
- trying to get the next frame fails and an error is thrown, aborting the
backtrace
- the error is caught and printed
In the second:
- the bt command is called
- the frame filter is applied
- doing so triggers the same error, which is caught and printed by
gdbpy_apply_frame_filter, returning EXT_LANG_BT_NO_FILTERS
- frame #0 is printed
- getting the next frame fails, and the backtrace stops
It seems worthwhile to exercise both scenarios if possible, so add a
"bt -no-filters" test.
Fix the FAIL by updating the regexp to allow both scenarios.
Tested on aarch64-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
With a gdb build without python support and test-case
gdb.multi/pending-bp.exp, I run into:
...
(gdb) python bp=[b for b in gdb.breakpoints() if b.number == 5][0]^M
Python scripting is not supported in this copy of GDB.^M
(gdb) FAIL: $exp: py_test_toggle_thread: find Python gdb.Breakpoint object
...
Fix this by requiring python support for part of the test-case.
Tested on aarch64-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
With a gdb build without xml support and test-case gdb.base/break-dbg.exp, I
run into:
...
(gdb) catch syscall^M
warning: Can not parse XML syscalls information; \
XML support was disabled at compile time.^M
Catchpoint 11 (any syscall)^M
(gdb) FAIL: $exp: catch syscall
...
Fix this by updating the regexp.
Tested on aarch64-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
On x86_64-freebsd, with test-case gdb.arch/amd64-disp-step-self-call.exp, I
run into:
...
(gdb) continue
Continuing.
Program received signal SIGBUS, Bus error.
Object-specific hardware error.
0x000000080051492c in alarm () from /lib/libc.so.7
(gdb) FAIL: $exp: continue to breakpoint: test_call
...
The behaviour is not specific to gdb, it can be reproduced by running the
test-case executable:
...
$ ./outputs/gdb.arch/amd64-disp-step-self-call/amd64-disp-step-self-call
Bus error (core dumped)
$
...
The bus error happens when executing this instruction in alarm:
...
0000000000093910 <alarm>:
...
9392c: 0f 29 45 d0 movaps %xmm0, -0x30(%rbp)
...
because $rbp is not 16-byte aligned.
This can be fixed by adding the missing frame setup instructions at the start
of main in amd64-disp-step-self-call.S:
...
main:
+ pushq %rbp
+ movq %rsp, %rbp
...
Instead, fix this by moving main from the assembly file to the c file, which
has the same effect.
Also remove the done label, which looks like a copy-past left-over. Instead,
add an unreachable function and use it where appropriate.
Do the same for i386 case (which makes the source files identical for the
amd64 and i386 case, but I decided to leave it like that).
Tested on x86_64-freebsd and x86_64-linux.
|
|
Emit a line in the gdb.log file each time a new gdb.in.NUM command log
is started. The gdb.log line includes the full filename for the new
gdb.in.NUM file.
This change will make it trivial to go from a FAIL in the gdb.log file
to the gdb.in.NUM file that (should) reproduce the failure. When I
encounter a failing test one of my first steps is usually to identify
the gdb.in.NUM file and try re-running it to see if that reproduces
the failure. Some tests create many very similar gdb.in.NUM files, so
finding the exact one can sometimes be difficult. With this patch
that task is now trivial.
There should be no change in what is tested after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
In some test-cases, matching the pagination prompt is split up to address a
matching race but that's no longer necessary, thanks to commit c3f814a1433
("Fix paginate-*.exp races").
Fix this by using the pagination_prompt variable.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
In test-case gdb.base/style.exp, we have proc test_pagination_prompt_styling,
which:
- determines a "desired width" by parsing the output of "info files",
- sets width to the "desired width", and
- runs "info files" again.
The "desired width" on my system is 88, but if I override it to 65, I run
into:
...
(gdb) info files^M
Symbols from "^[[32;49;22;27m/data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.base/style/style^[[m".^M
--Type <RET> for more, q to quit, c to continue without paging--^M
^MFAIL: gdb.base/style.exp: check pagination prompt styling (timeout)
...
with make target check, and with check-read1 into:
...
(gdb) info files^M
Symbols from "^[[32;49;22;27m/data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.base/style/style^[[m".^M
--Type <RET> for more, q to quit, c to continue without paging--^M
^M^[[A^M
Native process:^M
Using the running image of child process 6179.^M
--Type <RET> for more, q to quit, c to continue without paging--ERROR: Window too small.
UNRESOLVED: gdb.base/style.exp: check pagination prompt styling
...
This is caused by the following.
The size of the pagination prompt is 64:
...
1 2 3 4 5 6
1234567890123456789012345678901234567890123456789012345678901234
--Type <RET> for more, q to quit, c to continue without paging--
...
and because we have TERM=ansi and width == 65, readline wraps at 64:
...
(gdb) maint info screen
Number of characters gdb thinks are in a line is 65.
Number of characters readline reports are in a line is 64.
...
In other words, readline wraps when printing the pagination prompt.
This causes some unusual output, and the test is not prepared to handle this.
Fix this by requiring that desired_width is at least
<length of pagination prompt> + 2.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR testsuite/33167
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33167
|
|
In test-case gdb.base/style.exp, we have proc test_pagination_prompt_styling,
which:
- determines a "desired width" by parsing the output of "info files",
- sets width to the "desired width", and
- runs "info files" again.
The "desired width" on my system is 88, but if I override it to 66, I run into:
...
FAIL: gdb.base/style.exp: check pagination prompt styling
...
due to the test classifying this line as a bad line:
...
$hex - $hex is .init_array in --Type <RET> for more, ...
...
This is due to a bug in this regexp:
...
# For lines that don't match this pattern, we cannot comment on
# where the style reset should occur, so lets just claim the line
# is fine.
if { ![regexp "\\s+$::hex - $::hex is \[^\r\n\]+ in " $str] } {
return true
}
...
which is supposed to determine whether the line needs to contain a style
reset.
For aforementioned line, the regexp matches, so the test concludes that the
line should have a style reset, and because it hasn't, it classifies it as a
bad line.
Fix this by making the regexp more strict:
...
if { ![regexp "\\s+$::hex - $::hex is \[^\r\n\]+ in \033" $str] } {
...
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
