| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When running test-case gdb.base/fission-macro.exp on openSUSE Tumbleweed
(using gcc 14) with target board unix/-m32, I get:
...
(gdb) info macro FIRST^M
Defined at /data/vries/gdb/src/gdb/testsuite/gdb.base/fission-macro.c:0^M
-DFIRST=1^M
(gdb) FAIL: $exp: \
dwarf_version=5: dwarf_bits=32: strict_dwarf=0: info macro FIRST
...
instead of the expected:
...
(gdb) info macro FIRST^M
Defined at /data/vries/gdb/src/gdb/testsuite/gdb.base/fission-macro.c:18^M
(gdb) PASS: $exp: \
dwarf_version=5: dwarf_bits=32: strict_dwarf=0: info macro FIRST
...
A dwarf-5 .debug_str_offsets section starts with a header consisting of:
- an initial length (4 bytes for 32-bit and 12 bytes for 64-bit),
- a 2 byte version string, and
- 2 bytes padding
so in total 8 bytes for 32-bit and 16 bytes for 64-bit.
This offset is calculated here in dwarf_decode_macros:
...
str_offsets_base = cu->header.addr_size;
...
which is wrong for both dwarf-5 cases (and also happens to be wrong for
dwarf-4).
Fix this by computing str_offsets_base correctly for dwarf-5, for both the
32-bit and 64-bit case.
Likewise, fix this for dwarf-4, using str_offsets_base 0. We can only test
this with gcc-15, because gcc 14 and earlier don't have the fix for
PR debug/115066.
Tested on x86_64-linux.
Tested test-case using a current gcc trunk build, and gcc 14.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/31897
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31897
|
|
The stated intention of test-case gdb.base/lineinc.exp is:
...
# Test macro handling of #included files.
...
However, the test-case does not produce any macro debug information.
Fix this by adding macros in the compilation flags.
Tested on x86_64-linux.
|
|
The newly added test gdb.base/backtrace-through-cu-nodebug.exp had a
problem in the call to gdb_compile, that caused the .o files to be
outputted in the GDB file tree. This commit fixes the issues in the calls.
Reported-By: Tom de Vries <tdevries@suse.de>
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
On arm-linux, with target board unix/-mthumb, we get:
...
(gdb) PASS: gdb.cp/non-trivial-retval.exp: continue to breakpoint: Break here
p f1 (i1, i2)^M
$1 = {a = -136274256}^M
(gdb) FAIL: gdb.cp/non-trivial-retval.exp: gdb-command<p f1 (i1, i2)>
...
This is not a problem with the inferior call, which works fine:
...
(gdb) p f1 (23, 100)
$3 = {a = 123}
...
but instead it's a problem with the location information:
...
(gdb) p i1
$1 = -136274356
(gdb) p i2
$2 = 100
...
which tells us to find the value of i1 in (DW_OP_fbreg: -12).
The test-case passes if we drop -fvar-tracking, in which case the debug info
tells us to find the value of i1 in (DW_OP_fbreg: -20).
This is with gcc 13.3.0 on Ubuntu 24.04. With gcc 14.2.0 on Debian testing,
the code is the same, but -fvar-tracking does use the correct
'(DW_OP_fbreg: -20)'.
There seems to be some bugfix in -fvar-tracking for gcc 14.
Workaround the bug by using constants 23 and 100 instead of i1 and i2 when
using -fvar-tracking and gcc < 14.
Tested on arm-linux.
PR testsuite/32549
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32549
|
|
This simplifies get_frame_unwind_table, changing it to use the
registry 'emplace' method and to pass the initialization iterators to
the constructor. This fixes a build problem on x86 -- reported by the
auto-builder -- as a side effect.
Tested-By: Guinevere Larsen <guinevere@redhat.com>
|
|
Tom de Vries reported that some of the test for the vmov[u|a]p[s|d] were
failing. In my machine xmm3 was consistently set to 0x54, but apparently
that is different depending on the system. This commit zeroes out xmm3
at the start of the test instead.
While debugging the test failures, I also noticed an issue where the
recording wasn't saving all the required memory. That happened because
vmovs[s|d] shares its opcode with vmovap[s|d], meaning they seem to
share code paths, but the latter encodes memory modification size on
VEX.L whereas the former encodes in VEX.pp. So this commit fixed that,
and made the relevant tests more robust and complete.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32561
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
My earlier changes introduced a self-test crash. This patch fixes the
bug by introducing a new method overload into mock_mapped_index.
|
|
After some recent discussions on the mailing list, I've made some
changes to the README to (I hope) provide more clarity.
The changes I made are:
1. Removed the use of a lone 'HOST' on the configure line. I tried
this and 'configure' gave me a warning:
configure: WARNING: you should use --build, --host, --target
So I don't think this is approved practice any more. We should
encourage users to use `--host` instead.
2. Added and reworded the --host, --target, and --enable-targets
descriptions in the 'configure options' section. My goals here are
to clarify that 'cross-debugging' is really the same as 'remote
debugging', and also to make it clearer what the defaults are.
3. Added some additional text to the 'Remote debugging' section
mentioning that 'remote debugging' is basically the same as 'cross
debugging', given that we use 'cross-debugging' in the text above.
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
This commit fixes an issue with the commit:
commit d3d13bf876aae425ae0eff2ab0f1af9f7da0264a
Date: Thu Apr 25 09:36:43 2024 +0100
gdb: add gdbarch method to get execution context from core file
The above commit improves GDB's ability to display inferior arguments
when opening a core file, however, if an argument includes white
space, then this is not displayed as well as it should be. For
example:
(gdb) core-file /tmp/corefile-exec-context.2.core
[New LWP 4069711]
Reading symbols from /tmp/corefile-exec-context...
Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e e e e e'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 return ret;
(gdb) show args
Argument list to give program being debugged when it is started is "aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e".
(gdb)
Notice the 'Core was generated by ...' line. In this case it is not
clear if the "e e e e e" is a single argument containing white space,
or 5 single arguments.
But when we 'show args' it is immediately clear that this is a single
argument, as the white space is now escaped.
This problem was caused by the above commit building the argument
string itself, and failing to consider white space escaping.
This commit changes things around, first we place the arguments into
the inferior, then, to print the 'Core was generated by ...' line, we
ask the inferior for the argument string. In this way the quoting is
handled just as it is for 'show args'. The initial output is now:
(gdb) core-file /tmp/corefile-exec-context.2.core
[New LWP 4069711]
Reading symbols from /tmp/corefile-exec-context...
Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f4f007af625 in raise () from /lib64/libc.so.6
(gdb)
Much better. The existing test is extended to cover this case.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The base class mapped_index_base is no longer needed. Previously it
was used by both the .gdb_index and .debug_names readers, but the
latter now uses the cooked index instead.
This patch removes mapped_index_base, merging it into
mapped_gdb_index. Supporting code that is specific to .gdb_index is
also moved into read-gdb-index.c. This shrinks dwarf2/read.c a bit,
which is nice.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32504
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
gdb_index_unpack is not used and can be removed. The include of
extract-store-integer.h is also no longer needed by this file.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
I found a number of .c files that need to include
extract-store-integer.h but that were only including it indirectly.
This patch adds the missing includes. This change enables the next
patch.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Fedora has been carrying this test since back in the Project Archer
days. A change back then caused GDB to stop being able to backtrace when
only some of the object files had debug information. Even though the
changed code never seems to have made its way into the main GDB project,
I think it makes sense to bring the test along to ensure something like
this doesn't pass unnoticed.
Co-Authored-By: Jan Kratochvil <jan@jankratochvil.net>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Sometimes, in the GDB testsuite, we want to test the ability of specific
unwinders to handle some piece of code. Usually this is done by trying
to outsmart GDB, or by coercing the compiler to remove information that
GDB would rely on. Both approaches have problems as GDB gets smarter
with time, and that compilers might differ in version and behavior, or
simply introduce new useful information. This was requested back in 2003
in PR backtrace/8434.
To improve our ability to thoroughly test GDB, this patch introduces a
new maintenance command that allows a user to disable some unwinders,
based on either the name of the unwinder or on its class. With this
change, it will now be possible for GDB to not find any frame unwinders
for a given frame, which would previously cause GDB to assert. GDB will
now check if any frame unwinder has been disabled, and if some has, it
will just error out instead of asserting.
Unwinders can be disabled or re-enabled in 3 different ways:
* Disabling/enabling all at once (using '-all').
* By specifying an unwinder class to be disabled (option '-class').
* By specifying the name of an unwinder (option '-name').
If you give no options to the command, GDB assumes the input is an
unwinder class. '-class' would make no difference if used, is just here
for completeness.
This command is meant to be used once the inferior is already at the
desired location for the test. An example session would be:
(gdb) start
Temporary breakpoint 1, main () at omp.c:17
17 func();
(gdb) maint frame-unwinder disable ARCH
(gdb) bt
\#0 main () at omp.c:17
(gdb) maint frame-unwinder enable ARCH
(gdb) cont
Continuing.
This commit is a more generic version of commit 3c3bb0580be0,
and so, based on the final paragraph of the commit message:
gdb: Add switch to disable DWARF stack unwinders
<...>
If in the future we find ourselves adding more switches to disable
different unwinders, then we should probably move to a more generic
solution, and remove this patch.
this patch also reverts 3c3bb0580be0
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8434
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
temp adding completion
|
|
Frame unwinders have historically been a structure populated with
callback pointers, so that architectures (or other specific unwinders)
could install their own way to handle the inferior. However, since
moving to C++, we could use polymorphism to get the same functionality
in a more readable way. Polymorphism also makes it simpler to add new
functionality to all frame unwinders, since all that's required is
adding it to the base class.
As part of the changes to add support to disabling frame unwinders,
this commit makes the first baby step in using polymorphism for the
frame unwinders, by making frame_unwind a virtual class, and adds a
couple of new classes. The main class added is frame_unwind_legacy,
which works the same as the previous structs, using function pointers
as callbacks. This class was added to allow the transition to happen
piecemeal. New unwinders should instead follow the lead of the other
classes implemented.
2 of the others, frame_unwind_python and frame_unwind_trampoline, were added
because it seemed simpler at the moment to do that instead of reworking
the dynamic allocation to work with the legacy class, and can be used as
an example to future implementations.
Finally, the cygwin unwinder was converted to a class since it was most
of the way there already.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
A future patch will add a way to disable certain unwinders based on
different characteristics. This patch aims to make it more convenient
to disable related unwinders in bulk, such as architecture specific
ones, by identifying all unwinders by which part of the code adds it.
The classes, and explanations, are as follows:
* GDB: An internal unwinder, added by GDB core, such as the unwinder
for dummy frames;
* EXTENSION: Unwinders added by extension languages;
* DEBUGINFO: Unwinders installed by the debug info reader;
* ARCH: Unwinders installed by the architecture specific code.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Before this commit, all frame unwinders would be stored in the obstack
of a gdbarch and accessed by using the registry system. This made for
unwieldy code, and unnecessarily complex logic in the frame_unwinder
implementation, along with making frame_unwind structs be unable to have
non-trivial destructors.
Seeing as a future patch of this series wants to refactor the
frame_unwind struct to use inheritance, and we'd like to not restrict
the future derived classes on what destructors are allowed. In
preparation for that change, this commit changes the registry in gdbarch
to instead store an std::vector, which doesn't require using an obstack
and doesn't rely on a linked list.
There should be no user-visible changes.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
When running test-case gdb.dwarf2/implptr.exp on target board unix/-m32, we
get:
...
(gdb) PASS: gdb.dwarf2/implptr.exp: print ***l in implptr:bar
break implptr.c:34^M
No compiled code for line 34 in file "implptr.c".^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: $exp: set baz breakpoint for implptr (got interactive prompt)
...
This is a regression since commit dcaa85e58c4 ("gdb: reject inserting
breakpoints between functions").
The .debug_line info does not contain an entry with a line number lower than
36, so gdb cannot map it to an address.
Fix this by setting a breakpoint at the function containing line 34 instead.
Tested on x86_64-linux.
PR testsuite/32477
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32477
|
|
Once in a while, I run into a timeout in test-case
gdb.threads/step-over-thread-exit.exp:
...
(gdb) continue^M
Continuing.^M
[New Thread 0xfffff7cff1a0 (LWP 2874854)]^M
^M
Thread 97 "step-over-threa" hit Breakpoint 2, 0x0000000000410314 in \
my_exit_syscall () at gdb/testsuite/lib/my-syscalls.S:74^M
74 SYSCALL (my_exit, __NR_exit)^M
(gdb) [Thread 0xfffff7cff1a0 (LWP 2874853) exited]^M
FAIL: $exp: step_over_mode=displaced: non-stop=on: target-non-stop=on: \
schedlock=off: cmd=continue: ns_stop_all=0: iter 95: continue (timeout)
...
I can reproduce it more frequently by running with taskset -c <slow core id>.
Fix this by using -no-prompt-anchor.
This requires us to add -no-prompt-anchor to proc gdb_test_multiple.
Tested on aarch64-linux.
PR testsuite/32489
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32489
|
|
The sourceware buildbot reported "python black formatter ( failure )" at
commit b034bb38772 ("[gdb] Add gdbarch_dwarf2_reg_piece_offset hook").
Fix this by running the precommit hooks in a container with Python 3.11 using:
...
$ pre-commit run --files gdb*/*
...
|
|
Boolify the 'in_g_packet' of the 'packet_reg' struct that is used in
remote.c.
|
|
On s390x-linux, I get:
...
(gdb) print l^M
$29 = 0^M
(gdb) FAIL: gdb.base/store.exp: var doublest l; print old l, expecting -1
...
So, we're in wack_doublest trying to print l, which is a copy of parameter u:
...
register doublest l = u, r = v;
...
which does have the expected value:
...
(gdb) p u
$1 = -1
...
which is a long double, 16 bytes and looks like this:
...
(gdb) p /x u
$3 = 0xbfff0000000000000000000000000000
...
Parameter u is passed in two registers:
...
<2><6a5>: Abbrev Number: 15 (DW_TAG_formal_parameter)
<6a6> DW_AT_name : v
<69e> DW_AT_location : 6 byte block: 50 93 8 51 93 8 \
(DW_OP_reg0 (r0); DW_OP_piece: 8; DW_OP_reg1 (r1); DW_OP_piece: 8)
...
and indeed we find the msw in r0 and the lsw in r1:
...
(gdb) p /x $r0
$4 = 0xbfff000000000000
(gdb) p /x $r1
$5 = 0x0
(gdb)
...
Likewise, variable l consists of two registers:
...
<2><6b5>: Abbrev Number: 13 (DW_TAG_variable)
<6b6> DW_AT_name : l
<6be> DW_AT_location : 6 byte block: 68 93 8 69 93 8 \
(DW_OP_reg24 (f8); DW_OP_piece: 8; DW_OP_reg25 (f10); DW_OP_piece: 8)
...
and we find the same values there:
...
(gdb) p /x $f8
$6 = 0xbfff000000000000
(gdb) p /x $f10
$7 = 0x0
...
So, we get the expected results when fetching the value from two gprs, but not
when fetching the value from two fprs.
When fetching the values from the two fprs, we stumble upon a particularity of
the DWARF register numbers as defined by the s390x ABI [1]: dwarf register 24
maps to both floating-point register f8 (8 bytes), and vector register v8
(16 bytes).
In s390_dwarf_reg_to_regnum, it's determined which of the two is chosen, and
if available vector registers are preferred over floating-point registers, so
v8 is chosen, and used to fetch the value.
Since the size of the DW_OP_piece is 8 bytes, and the register size is 16
bytes, this bit in rw_pieced_value is activated:
...
/* If the piece is located in a register, but does not
occupy the entire register, the placement of the piece
within that register is defined by the ABI. */
bits_to_skip
+= 8 * gdbarch_dwarf2_reg_piece_offset (arch, gdb_regnum,
p->size / 8);
...
but since the default implemention default_dwarf2_reg_piece_offset does not
match the s390x ABI, we get the wrong answer.
This is a known problem, see FOSDEM 2018 presentation "DWARF Pieces And Other
DWARF Location Woes" [2].
Fix this by adding s390_dwarf2_reg_piece_offset, roughly implementing the same
logic as in s390_value_from_register.
Tested on s390x-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://github.com/IBM/s390x-abi
[2] https://archive.fosdem.org/2018/schedule/event/dwarfpieces
|
|
In rw_pieced_value, when reading/writing part of a register, DW_OP_piece and
DW_OP_bit_piece are handled the same, but the standard tells us:
- DW_OP_piece: if the piece is located in a register, but does not occupy the
entire register, the placement of the piece within that register is defined
by the ABI.
- DW_OP_bit_piece: if the location is a register, the offset is from the least
significant bit end of the register.
Add a new hook gdbarch_dwarf2_reg_piece_offset that allows us to define the
ABI-specific behaviour for DW_OP_piece.
The default implementation of the hook is the behaviour of DW_OP_bit_piece, so
there should not be any functional changes.
Tested on s390x-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Add a new field "dwarf_location_atom op" to dwarf_expr_piece to keep track of
which dwarf_location_atom caused a dwarf_expr_piece to be added.
This is used in the following patch.
Tested on s390x-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I happened to notice that "help add-inferior" said:
-execFILENAME
FILENAME is the file name of the executable to use as the
main program.
This is missing a space after "-exec". This patch fixes the bug.
If ok'd on time I plan to check this in to the gdb-16 branch as well.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
loongarch_stopped_data_address() is a common function and will be used by
gdb and gdbserver, so move its definition from gdb/loongarch-linux-nat.c
to gdb/nat/loongarch-hw-point.c. This is preparation for later gdbserver
patch on LoongArch and is no effect for the current code.
Signed-off-by: Hui Li <lihui@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
loongarch_{get,remove}_debug_reg_state() are used as helper functions
by loongarch_linux_nat_target. We should move their definitions from
gdb/nat/loongarch-linux-hw-point.c to gdb/loongarch-linux-nat.c.
Signed-off-by: Hui Li <lihui@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
loongarch_lookup_debug_reg_state() is a unused function, so we
can remove it.
Signed-off-by: Hui Li <lihui@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
The test gdb.reverse/i386-avx-reverse.exp requires CPU to have AVX
instructions but it actually also uses AVX2 instructions (like
vpcmpeqd). This caused the test to fail on CPUs that have AVX but not
AVX2.
This commit adds check for AVX2.
Tested on Intel Xeon CPU E3-1265L (no AVX2) and Intel Core i7-1355U
(has AVX2).
|
|
Test-case gdb.python/py-symbol.exp fails with various target boards, including
fission and gold-gdb-index.
The problem here is that, in this test, the current language is still
unset (i.e., lazy) when the symbol lookup is done. It is eventually
set deep in the lookup -- but this then requires a reentrant symbol
lookup, which fails. (DWARF symbol lookup is not reentrant.)
Fix this by:
- detecting symbol lookup reentrance using an assert, and
- requiring the current language to be set when entering symbol lookup.
Tested on x86_64-linux.
Co-Authored-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/32490
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32490
|
|
This changes decode_line_2_item::selected to bool. There was no
benefit to keeping this as a bitfield, so I removed that. Note that
the constructor already uses bool here.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes add_sal_to_sals to use 'bool' rather than 'int'.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I found a few filename-related "show" commands that do not use the
filename style when displaying the file. This patch fixes the
oversight.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
The custom linetable functionality in GDB's JIT Interface has been broken
since commit 1acc9dca423f78e44553928f0de839b618c13766.
In that commit, linetables were made independent from the objfile, which
requires objfile->section_offsets to be initialized. However, section_offsets
were never initialized in objfiles generated by GDB's JIT Interface
with custom jit-readers, leading to GDB crashes when stepping into JITed code
blocks with the following command already executed:
jit-reader-load libmygdbjitreader.so
This patch fixes the issue by initializing the minimum section_offsets required
for linetable parsing procedures.
A minimal test is included. The test sets up some very simple line
table information, which is enough to trigger the bug. However, the
line table information is crafted such that none of the line table
entries will end up being displayed in GDB's output when the test is
run, as such, none of the expected output actually changes.
It might be nice in the future to extend some of the jit tests to
actually test hitting line table entries added via the jit reader.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit adds support for the following types of instructions
relating to floating poitn values: add, mul, sub, min, div, max.
These are supported with packed or single values, and single or double
precision.
Some of the instructions had opcode clashes, however, considering the
mechanics of recording the registers is the same on both instructions,
this is just marked with a comment.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
This commit adds support for the AVX instructions vunpck[l|h][ps|pd]
instructions, which was pretty straightforward.
This commit also fixes a mistake in the test, where "record stop" was
used after the recording was already stopped, if it failed during
vpunpck_test recording. It also improved the documentation at the start
of the relevant .c function.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
This commit updates GDB's record-full to be able to record vmov[ss|sd]
and vmov [u|a] [ps|pd] AVX instructions, and tests for them.
Unlike the vmovdq[u|a] instructions, the aligned and unalgined versions
of vmov?[ps|pd] have different opcodes. The mechanics of recording them
is the same, but the aligned version has opcodes 0x28 and 0x29, while
the unaligned has the same opcode as vmov[ss|sd] instruction, 0x10 and
0x11.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
UST support in gdbserver is substantially outdated. Simon says:
...[having HAVE_UST defined] never happens nowadays because it used
a version of lttng-ust that has been deprecated for a loooong time
(the 0.x series). So everything in HAVE_UST just bitrots. It might
be possible to update all this code to use lttng-ust 2.x (1.x never
existed), but I don't think it's going to happen unless somebody
specifically asks for it. I would suggest removing support for UST
from gdbserver. ...If we ever want to resurrect the support for UST
and port to 2.x, we can get the code from the git history.
This patch removes the support, mostly mechanically by deleting code
guarded by `#ifdef HAVE_UST`. After these removals, `struct
static_tracepoint_ctx` becomes unused. So, remove it, too.
The following patches remove more code.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I noticed that 'L' is a tracepoint action but it is not defined in the
document. Add the description.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
I noticed that gdbserver accepts an 'S' option for the QTDP packet to
create a static tracepoint, but this is not mentioned in the document.
Update the document.
I first thought about updating the argument as `[:Flen|:S]`, but then
opted for `[:Flen][:S]`. Although it is odd that ':F' and ':S' are
allowed to co-exist, the implementation at the gdbserver side allows
this and handles the packet arguments so that the right-most
positioned ':F' or ':S' overwrites the final tracepoint type. When
the documentation is missing, the implementation usually determines
the behavior.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
In AIX a recent commit caused a build break with the error as shown below.
In file included from python/py-color.h:23,
from python/python.c:39:
python/python-internal.h:86:10: fatal error: Python.h: No such file or directory
86 | #include <Python.h>
In AIX, we run builds with and without python for our internal CI's.
A feature development made by the recent commit https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=6447969d0ac774b6dec0f95a0d3d27c27d158690
missed to guard Python.h in HAVE_PYTHON macro.
This commit is a fix for the same.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
A comment in bugzilla pointed out a bug in my earlier patch to handle
the DAP "linesStartAt1" setting. In particular, in the backtrace
code, "line" can be None, which would lead to an exception from
export_line.
This patch fixes the problem.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32468
|
|
Fix a typo and do a format change.
|
|
Commit 7fcdec025c05 ("GDB: Use gdb::array_view for buffers used in
register reading and unwinding") introduces a regression in
gdb.base/jit-reader.exp:
$ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.base/jit-reader/jit-reader -ex 'jit-reader-load /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/jit-reader/jit-reader.so' -ex r -batch
This GDB supports auto-downloading debuginfo from the following URLs:
<https://debuginfod.archlinux.org>
Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal]
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
Program received signal SIGTRAP, Trace/breakpoint trap.
Recursive internal problem.
The "Recusive internal problem" part is not good, but it's not the point
of this patch. It still means we hit an internal error.
The stack trace is:
#0 internal_error_loc (file=0x55555ebefb20 "/home/simark/src/binutils-gdb/gdb/frame.c", line=1207, fmt=0x55555ebef500 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:53
#1 0x0000555561604d83 in frame_register_unwind (next_frame=..., regnum=16, optimizedp=0x7ffff12e5a20, unavailablep=0x7ffff12e5a30, lvalp=0x7ffff12e5a40, addrp=0x7ffff12e5a60, realnump=0x7ffff12e5a50, buffer=...)
at /home/simark/src/binutils-gdb/gdb/frame.c:1207
#2 0x0000555561608334 in deprecated_frame_register_read (frame=..., regnum=16, myaddr=...) at /home/simark/src/binutils-gdb/gdb/frame.c:1496
#3 0x0000555561a74259 in jit_unwind_reg_get_impl (cb=0x7ffff1049ca0, regnum=16) at /home/simark/src/binutils-gdb/gdb/jit.c:988
#4 0x00007fffd26e634e in read_register (callbacks=0x7ffff1049ca0, dw_reg=16, value=0x7fffffffb4c8) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-reader.c:100
#5 0x00007fffd26e645f in unwind_frame (self=0x50400000ac10, cbs=0x7ffff1049ca0) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-reader.c:143
#6 0x0000555561a74a12 in jit_frame_sniffer (self=0x55556374d040 <jit_frame_unwind>, this_frame=..., cache=0x5210002905f8) at /home/simark/src/binutils-gdb/gdb/jit.c:1042
#7 0x00005555615f499e in frame_unwind_try_unwinder (this_frame=..., this_cache=0x5210002905f8, unwinder=0x55556374d040 <jit_frame_unwind>) at /home/simark/src/binutils-gdb/gdb/frame-unwind.c:138
#8 0x00005555615f512c in frame_unwind_find_by_frame (this_frame=..., this_cache=0x5210002905f8) at /home/simark/src/binutils-gdb/gdb/frame-unwind.c:209
#9 0x00005555616178d0 in get_frame_type (frame=...) at /home/simark/src/binutils-gdb/gdb/frame.c:2996
#10 0x000055556282db03 in do_print_frame_info (uiout=0x511000027500, fp_opts=..., frame=..., print_level=0, print_what=SRC_AND_LOC, print_args=1, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:1033
The problem is that function `jit_unwind_reg_get_impl` passes field
`gdb_reg_value::value`, a gdb_byte array of 1 element (used as a
flexible array member), as the array view parameter of
`deprecated_frame_register_read`. This results in an array view of size
1. The assertion in `frame_register_unwind` that verifies the passed in
buffer is larger enough to hold the unwound register value then fails.
Fix this by explicitly creating an array view of the right size.
Change-Id: Ie170da438ec9085863e7be8b455a067b531635dc
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
|
|
Colors can be specified as "none" for terminal's default color, as a name of
one of the eight standard colors of ISO/IEC 6429 "black", "red", "green", etc.,
as an RGB hexadecimal tripplet #RRGGBB for 24-bit TrueColor, or as an
integer from 0 to 255. Integers 0 to 7 are the synonyms for the standard
colors. Integers 8-15 are used for the so-called bright colors from the
aixterm extended 16-color palette. Integers 16-255 are the indexes into xterm
extended 256-color palette (usually 6x6x6 cube plus gray ramp). In
general, 256-color palette is terminal dependent and sometimes can be
changed with OSC 4 sequences, e.g. "\033]4;1;rgb:00/FF/00\033\\".
It is the responsibility of the user to verify that the terminal supports
the specified colors.
PATCH v5 changes: documentation fixed.
PATCH v6 changes: documentation fixed.
PATCH v7 changes: rebase onto master and fixes after review.
PATCH v8 changes: fixes after review.
|
|
I noticed that an article was missing in the "Debug Names" node. I'm
checking this in to correct the error.
|
|
event-top.h declares the_prompts, but it is never defined. It's a
leftover from some ancient refactoring.
Similarly, top.c defines a few prompt-related macros, but these are
unused.
This patch removes these.
|
|
This was flagged by Debian's lintian.
Signed-off-by: Sergio Durigan Junior <sergiodj@sergiodj.net>
|
|
I belatedly realized I had forgotten to update a bool-related comment
in linespec.c. This patch fixes the oversight.
|
|
This changes various spots in linespec to use a bool rather than an
int.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
