| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
|
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>
|
|
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
|
|
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>
|
|
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>
|
|
With test-case gdb.base/style.exp, I get:
...
PASS: gdb.base/style.exp: set width 88
...
The 88 is not a constant, it's a variable:
...
gdb_test_no_output "set width $desired_width"
...
which is calculated by parsing the output of "info files".
When running with target board unix/-m32, I get instead:
...
PASS: gdb.base/style.exp: set width 67
...
Stabilize the test name by using instead:
...
PASS: gdb.base/style.exp: set width to desired width
...
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This commit adds support for a few more vmov instructions:
* VMOV[LH|HL]PS
* VMOVLPD
* VMOVHP[S|D]
* VMOVDDUP
And associated tests. The testsuite had some minor re-working, adding a
function to zero buffers, to make later tests less fragile.
|
|
WIP
This commit adds support for instructions to convert from one type to
another, which are in the form:
* VCVTDQ2[PS|PD]
* VCVTPS2[DQ|PD]
* VCVTPD2[PS|DQ]
* VCVTSD2[SI|SS]
* VCVTSI2[SS|SD]
* VCVTSS2[SD|SI]
* VCVTTP[S|D]2DQ
* VCVTTS[S|D]2SI
It also adds support to vpsadbw, since it was trivial and only one
instruction. Finally, I have slightly reorder the case statements to
keep them in numerical order.
|
|
This commit adds support for the following instructions VPACK[S|U]S[WB|DW] and associated tests.
|
|
This commit adds support for the following instructions:
* VCOMIS[S|D]
* VUCOMIS[S|D]
And associanted tests.
|
|
This commit supports for the following instructions:
* VBLENDP[S|D]
* VBLENDVP[S|D]
* VPBLEND[D|W|VB]
and test them.
|
|
This patch adds support for the following instructions:
* VEXTRACT[F128|I128|PS]
* VINSERT[F128|I128|PS]
* VPEXTR[B|W|D|Q]
And associated test. For some reason, it seems that the extract
instructions deal with the output register as though it was the first
source register, so they use ModRM.r/m and VEX.B, instead of the usual
ModRM.reg and VEX.R. This meant that the opcode collision with
vbroadcastsd wasn't trivial. It can be easily solved by checking the
VEX.map_select field, so soslving it was very easy.
The VPEXTR instructions had several complicated collisions, and notably,
vpextrw to a register works completely different to any other
instruction in the family, so the code is messy, but it should be
correct.
|
|
This commit adds support for 3 instructions:
* VBROADCASTSS
* VBROADCASTSD
* VBROADCASTF128
and extends the function vpbroadcast_test to include these.
|
|
This commit adds recording support for the following instructions:
* VPERM2[I|F]128
* VPERM[D|Q|PD|PS]
* VPERMILP[S|D]
And associated tests.
|
|
This commit adds support for the following instructions:
* VPSHUF[B|D|HW|LW]
* VSHUFP[S|D]
and the associated test.
|
|
This commit adds record-full support to the following instructions:
* VPSLL[W|D|Q|DQ]
* VPSRL[W|D|Q|DQ]
* VPSRA[W|D]
With both dynamic and constant shifts, and the associated tests.
Notably, vpsraq is not available for AVX or AVX2 instruction sets, only
AVX512. vpsradq does not seem to be available with any instruction set.
|
|
This commit adds support to the following AVX/AVX2 instructions:
* VPADD[B|W|D|Q]
* VPMUL[LW|LD|HW|HUW|UDQ]
* VXORP[S|D]
* VPAND[|N]
This required some reworking on the loop that processes instruction
prefixes, because the opcode for VPMULLD overlapped with a valid
instruction prefix. To fix that, rather than using "goto out_prefixes",
this commit changes the infinite loop to only run while we don't find
another VEX prefix. That should be OK, as the intel manual (page 526 on
the March 2024 edition) says that the VEX prefix is always the last one.
|
|
add support to recording 2 missing AVX instructions: vaddsubps and vaddsubpd, and add associated tests.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
A recent patch of mine modified wchar.exp, but I failed to notice one
part of the review. This patch updates the code to conform to the
review comments.
|
|
Hannes filed a bug that pointed out that:
print L'\\'
... did not work correctly. The bug is in convert_escape, which
simply transcribes the backslash character, rather than convert it
between encodings.
This patch fixes the error. I also turned a macro into a lambda to
clean up this code a little.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33124
Reviewed-By: Tom de Vries <tdevries@suse.de>
Tested-By: Hannes Domani <ssbssa@yahoo.de>
|
|
Use the contrib/dg-extract-results.sh script to create a gdb.sum and
gdb.log summary after running the check-all-boards make target.
Having the results from all the boards merged into a single file
isn't (maybe) the most useful, but it isn't a bad thing. However, the
great thing about merge the results is that the totals are also
merged.
The 'check-all-boards' recipe can then extract these totals, just as
we do for the normal 'check' recipe, this makes is much easier to
spot if there are any unexpected failures when using
'check-all-boards'.
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
Change-Id: I15e307e6910ecbea5a5852e07757f892ea799536
|
|
gdb.arch/amd64-disp-step-avx.exp
In commit 8e73fddeb0d ("[gdb/testsuite] Fix gdb.arch/amd64-disp-step-avx.exp
on x86_64-freebsd") I added a "require {istarget *-*-linux*}", but since then
I found support_displaced_stepping, which seems more appropriate and
descriptive.
Fix this by requiring support_displaced_stepping instead.
Tested on x86_64-freebsd.
|
|
With test-case gdb.arch/amd64-disp-step-avx.exp on x86_64-freebsd I run into:
...
(gdb) continue
Continuing.
Breakpoint 3, test_rip_vex2_end () at amd64-disp-step-avx.S:35
35 nop
(gdb) FAIL: $exp: vex2: continue to test_rip_vex2_end
...
This happens while executing this bit of the test-case:
...
# Turn "debug displaced" on to make sure a displaced step is actually
# executed, not an inline step.
gdb_test_no_output "set debug displaced on"
gdb_test "continue" \
"Continuing.*prepared successfully .*Breakpoint.*, ${test_end_label} ().*" \
"continue to ${test_end_label}"
...
The problem is that on x86_64, displaced stepping is only supported for linux.
Consequently, the "prepared successfully" message is missing.
Fix this by requiring linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Tested on x86_64-freebsd.
|
|
A user noticed that if the remote sends terminal escape sequences from
the "monitor" command, then these will not be correctly displayed when
in TUI mode.
I tracked this down to remote.c emitting one character at a time --
something the TUI output functions did not handle correctly.
I decided in the end to fix in this in the ui-file layer, because the
same bug seems to affect logging and, as is evidenced by the test case
in this patch, Python output in TUI mode.
The idea is simple: buffer escape sequences until they are either
complete or cannot possibly be recognized by gdb.
Regression tested on x86-64 Fedora 40.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14126
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
On MSYS2, say we record a brief gdb session using TERM=dumb script:
...
$ gdb -q
(gdb) print 1
$1 = 1
(gdb) q
...
When looking at the resulting typescript, we notice something odd:
...
$ gdb -q^M
(gdb) print 1^M
$1 = 1^M^M
(gdb) q^M
...
For some reason, we have "$1 = 1\r\r\n(gdb) ".
Looking at the documentation of _setmode [1], it mentions translation mode
_O_TEXT as a mode in which "\n" is translated into "\r\n" on output.
So, it looks like this translation happens twice.
Add a command "maint set console-translation-mode <binary|text>" command that
allows us to set the translation mode of stdout/stderr to binary, such that we
get instead:
...
$ gdb -q -ex "maint set console-translation-mode binary"^M
(gdb) print 1^M
$1 = 1^M
(gdb) q^M
...
Since we run into this in the testsuite, add
"maint set console-translation-mode binary" to INTERNAL_GDBFLAGS.
Based on "maint set testsuite-mode on/off" from these patches [2][3] by Pierre
Muller.
Compared to that proposal, I dropped the name testsuite-mode, because the
behaviour is not specific to the testsuite.
Also I chose values binary/text instead of on/off because eventually there may
be other translation mode values that we need [4].
Co-Authored-By: Pierre Muller <muller@sourceware.org>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
[1] https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setmode
[2] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00939.html
[3] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00940.html
[4] https://learn.microsoft.com/en-us/cpp/c-runtime-library/translation-mode-constants
|
|
The subsequent C++ification patch in this series will allocate one
instance of solib_ops per program space. That instance will be held in
struct program_space. As a small step towards this, add an `solib_ops
*` field to `struct program_space`. This field represents the solib_ops
currently used to manage the solibs in that program space. Initialize
it with the result of `gdbarch_so_ops` in `post_create_inferior`, and
use it whenever we need to do some solib stuff, rather than using
`gdbarch_so_ops` directly.
The difficulty here is knowing when exactly to set and unset the solib
ops. What I have here passes the testsuite on Linux, but with more
testing we will probably discover more spots where it's needed.
The C++ification patch will turn this field into a unique pointer.
With this patch, the message we get when running "info
linker-namespaces" becomes always the same, so update the test in
gdb.base/dlmopen-ns-ids.exp.
Change-Id: Ide8ddc57328895720fcd645d46dc34491f84c656
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
|
|
running don't crash
While writing my solib_ops C++ification series, I broke this, and it
didn't seem to be caught by the testsuite. Add a test for those.
The exact message for "info linker-namespaces" varies depending on the
solib_ops of the target architecture (whether ops->num_active_namespaces
is nullptr or not). For now, just accept any message (a crash will
still be caught). A later patch in this series will make the message
consistent and update this test.
Change-Id: I6bce2ff317447bbf321fc9cbd2d42c3dcea0c683
Approved-By: Pedro Alves <pedro@palves.net>
|
|
Commit:
commit b23903836007d1acaf7f8c059ab000ee83fcebfa
Date: Tue Mar 21 13:01:26 2023 +0100
gdb: linux-namespaces: enter user namespace when appropriate
added a new test gdb.base/user-namespace-attach.exp. It has been
reported that this test will sometimes fail, like this:
(gdb) attach 184732
Attaching to process 184732
warning: process 184732 is a zombie - the process has already terminated
ptrace: Operation not permitted.
(gdb) FAIL: gdb.base/user-namespace-attach.exp: flags=--mount --map-root-user: attach to inferior
the test tries to run the 'unshare' application. Sometimes though,
the application is present, but the set of flags used is not
supported (maybe due to restrictions on the local machine), so we see
behaviour like this:
$ unshare --mount --map-root-user /bin/true; echo $?
unshare: unshare failed: Operation not permitted
1
Handle this case by first running 'unshare' with the same flags, but
using '/bin/true', if this fails then assume the flags are not
supported, and skip the test.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33108
|
|
This commit fixes a couple of issues relating to the pagination
prompt and styling. The pagination prompt is this one:
--Type <RET> for more, q to quit, c to continue without paging--
I did try to split this into multiple patches, based on the three
issues I describe below, but in the end, the fixes were all too
interconnected, so it ended up as one patch that makes two related,
but slightly different changes:
1. Within the pager_file class, relying on the m_applied_style
attribute of the wrapped m_stream, as is done when calling
m_stream->emit_style_escape, is not correct, so stop doing that, and
2. Failing to update m_applied_style within the pager_file class can
leave that attribute out of date, which can then lead to styling
errors later on, so ensure m_applied_style is always updated.
The problems I have seen are:
1. After quitting from a pagination prompt, the next command can
incorrectly style its output. This was reported as bug PR
gdb/31033, and is fixed by this commit.
2. The pagination prompt itself could be styled. The pagination
prompt should always be shown in the default style.
3. After continuing the output at a pagination prompt, GDB can fail
to restore the default style the next time the output (within the
same command) switches back to the default style.
There are tests for all these issues as part of this patch.
The pager_file class is a sub-class of wrapped_file, this means that a
pager_file is itself a ui_file, while it also manages a pointer to a
ui_file object (called m_stream). An instance of pager_file can be
installed as the gdb_stdout ui_file object.
Output sent to a pager_file is stored within an internal
buffer (called m_wrap_buffer) until we have a complete line, when the
content is flushed to the wrapped m_stream. If sufficient lines have
been written out then the pager_file will present the pagination
prompt and allow the user to continue viewing output, or quit the
current command.
As a pager_file is a ui_file, it has an m_applied_style member
variable.
The managed stream (m_stream) is also a ui_file, and so also has an
m_applied_style member variable.
In some places within the pager_file class we attempt to change the
current style of the m_stream using calls like this:
m_stream->emit_style_escape (style);
See pager_file::emit_style_escape, pager_file::prompt_for_continue,
and pager_file::puts. These calls will end up in
ui_file::emit_style_escape, which tries to skip emitting unnecessary
style escapes by checking if the requested style matches the current
m_applied_style value.
The m_applied_style value is updated by calls to the emit_style_escape
function.
The problem here is that most of the time pager_file doesn't change
the style of m_stream by calling m_stream->emit_style_escape. Most of
the time, style changes are performed by pager_file writing the escape
sequence into m_wrap_buffer, and then later flushing this buffer to
m_stream by calling m_stream->puts.
It has to be done this way. Calling m_stream->emit_style_escape
would, if it actually changed the style, immediately change the style
by emitting an escape sequence. But pager_file doesn't want that, it
wants the style change to happen later, when m_wrap_buffer is
flushed.
To avoid excessive style escape sequences being written into
m_wrap_buffer, the pager_file::m_applied_style performs a function
similar to the m_applied_style within m_stream, it tracks the current
style for the end of m_wrap_buffer, and only allows style escape
sequences to be emitted if the style is actually changing.
However, a consequence of this is the m_applied_style within m_stream,
is not updated, which means it will be out of sync with the actual
current style of m_stream. If we then try to make a call to
m_stream->emit_style_escape, if the style we are changing too happens
to match the out of date style in m_stream->m_applied_style, then the
style change will be ignored.
And this is indeed what we see in pager_file::prompt_for_continue with
the call:
m_stream->emit_style_escape (ui_file_style ());
As m_stream->m_applied_style is not being updated, it will always be
the default style, however m_stream itself might not actually be in
the default style. This call then will not emit an escape sequence as
the desired style matches the out of date m_applied_style.
The fix in this case is to call m_stream->puts directly, passing in
the escape sequence for the desired style. This will result in an
immediate change of style for m_stream, which fixes some of the
problems described above.
In fact, given that m_stream's m_applied_style is always going to be
out of sync, I think we should change all of the
m_stream->emit_style_escape calls to instead call m_stream->puts.
However, just changing to use puts doesn't fix all the problems.
I found that, if I run 'apropos time', then quit at the first
pagination prompt. If for the next command I run 'maintenance time' I
see the expected output:
"maintenance time" takes a numeric argument.
However, everything after the first double quote is given the command
name style rather than only styling the text between the double
quotes.
Here is GDB's stack while printing the above output:
#2 0x0000000001050d56 in ui_out::vmessage (this=0x7fff1238a150, in_style=..., format=0x1c05af0 "", args=0x7fff1238a288) at ../../src/gdb/ui-out.c:754
#3 0x000000000104db88 in ui_file::vprintf (this=0x3f9edb0, format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n", args=0x7fff1238a288) at ../../src/gdb/ui-file.c:73
#4 0x00000000010bc754 in gdb_vprintf (stream=0x3f9edb0, format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n", args=0x7fff1238a288) at ../../src/gdb/utils.c:1905
#5 0x00000000010bca20 in gdb_printf (format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n") at ../../src/gdb/utils.c:1945
#6 0x0000000000b6b29e in maintenance_time_display (args=0x0, from_tty=1) at ../../src/gdb/maint.c:128
The interesting frames here are #3, in here `this` is the pager_file
for GDB's stdout, and this passes its m_applied_style to frame #2 as
the `in_style` argument.
If the m_applied_style is wrong, then frame #2 will believe that the
wrong style is currently in use as the default style, and so, after
printing 'maintenance time' GDB will switch back to the wrong style.
So the question is, why is pager_file::m_applied_style wrong?
In pager_file::prompt_for_continue, there is an attempt to switch back
to the default style using:
m_stream->emit_style_escape (ui_file_style ());
If this is changed to a puts call (see above) then this still leaves
pager_file::m_applied_style out of date.
The right fix in this case is, I think, to instead do this:
this->emit_style_escape (ui_file_style ());
this will update pager_file::m_applied_style, and also send the
default style to m_stream using a puts call.
While writing the tests I noticed that I was getting unnecessary style
reset sequences emitted.
The problem is that, around pagination, we don't really know what
style is currently applied to m_stream. The
pager_file::m_applied_style tracks the style at the end of
m_wrap_buffer, but this can run ahead of the current m_stream style.
For example, if the screen is currently full, such that the next
character of output will trigger the pagination prompt, if the next
call is actually to pager_file::emit_style_escape, then
pager_file::m_applied_style will be updated, but the style of m_stream
will remain unchanged. When the next character is written to
pager_file::puts then the pagination prompt will be presented, and GDB
will try to switch m_stream back to the default style. Whether an
escape is emitted or not will depend on the m_applied_style value,
which we know is different than the actual style of m_stream.
It is, after all, only when m_wrap_buffer is flushed to m_stream that
the style of m_stream actually change.
And so, this commit also adds pager_file::m_stream_style. This new
variable tracks the current style of m_stream. This really is a
replacement for m_stream's ui_file::m_applied_style, which is not
accessible from pager_file.
When content is flushed from m_wrap_buffer to m_stream then the
current value of pager_file::m_applied_style becomes the current style
of m_stream. But, when m_wrap_buffer is filling up, but before it is
flushed, then pager_file::m_applied_style can change, but
m_stream_style will remain unchanged.
Now in pager_file::emit_style_escape we are able to skip some of the
direct calls to m_stream->puts() used to emit style escapes.
After all this there are still a few calls to
m_stream->emit_style_escape(). These are all in the wrap_here support
code. I think that these calls are technically broken, but don't
actually cause any issues due to the way styling works in GDB. I
certainly haven't been able to trigger any bugs from these calls yet.
I plan to "fix" these in the next commit just for completeness.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31033
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On openSUSE Tumbleweed (with python 3.13), I get:
...
(gdb) PASS: gdb.python/py-warning.exp: python gdb.warning("")
python gdb.warning()^M
Python Exception <class 'TypeError'>: \
function missing required argument 'text' (pos 1)^M
Error occurred in Python: function missing required argument 'text' (pos 1)^M
(gdb) PASS: gdb.python/py-warning.exp: python gdb.warning()
...
But on openSUSE Leap 15.6 (with python 3.6), I get instead:
...
(gdb) PASS: gdb.python/py-warning.exp: python gdb.warning("")
python gdb.warning()^M
Python Exception <class 'TypeError'>: \
Required argument 'text' (pos 1) not found^M
Error occurred in Python: Required argument 'text' (pos 1) not found^M
(gdb) FAIL: gdb.python/py-warning.exp: python gdb.warning()
...
Fix this by updating the regexp.
Tested on x86_64-linux.
PR testsuite/33104
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33104
|
|
On x86_64-freebsd with test-case gdb.base/infcall-failure.exp I get:
...
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
Address not mapped to object.
0x0000000000400522 in func_segfault () at infcall-failure.c:24
24 return *p; /* Segfault here. */
Error in testing condition for breakpoint 2:
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwind-on-signal on".
Evaluation of the expression containing the function
(func_segfault) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) FAIL: $exp: target_async=on: target_non_stop=on: \
run_cond_hits_segfault_test: continue
...
The problem is that the regexp in the test-case doesn't expect the
"Address not mapped to object." bit.
Fix this by updating the regexp.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Tested on x86_64-freebsd and x86_64-linux.
|
