| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Several tests assume that the first word after a thread ID in 'info
threads' output is "Thread". However, several targets use "LWP"
instead such as the FreeBSD and NetBSD native targets. The Linux
native target also uses "LWP" if libthread_db is not being used.
Targets that do not support threads use "process" as the first word
via normal_pid_to_str.
Add a tdlabel_re global variable as a regular-expression for a thread
label in `info threads' that matches either "process", "Thread", or
"LWP".
Some other tests in the tree don't require a specific word, and
some targets may use other first words (e.g. OpenBSD uses "thread"
and Ravenscar threads use "Ravenscar Thread").
|
|
Use gdb_realpath instead of realpath in windows-nat.c:windows_make_so,
so that we don't have to manually call free.
Approved-By: John Baldwin <jhb@FreeBSD.org>
Change-Id: Id3cda7e177ac984c9a5f7c23f354e72bd561edff
|
|
There is no need to limit shared library path sizes to
SO_NAME_MAX_PATH_SIZE nowadays. windows_solib::name and
windows_solib::original_name are std::strings nowadays, and so are
solib::so_name and solib::so_original_name in the core solib code.
This commit reworks the code to remove that limit. This also fixes a
leak where we were not releasing 'rname' in the realpath branch if the
'rname' string was larger than SO_NAME_MAX_PATH_SIZE.
Note: I tested the cygwin_conv_path with a manual hack to force that
path, and then stepping through the code. You only get to that path
if Windows doesn't report an absolute path for ntdll.dll, and on my
machine (running Windows 10), it always does.
Approved-By: John Baldwin <jhb@FreeBSD.org>
Change-Id: I79e9862d5a7646eebfef7ab5b05b96318a7ca0c5
|
|
There are two separate #ifndef __CYGWIN__/#else/#endif sections in the
windows_make_so function with 3 lines of shared code separating them.
I find this makes the code harder to understand than necessary.
AFAICS, there is no reason those three shared lines need to be after
the first #ifdef block. There is no early return, nor are 'load_addr'
nor 'name' modified.
This commit moves that shared code to the top of the function, and
then combines the two #ifndef sections.
Approved-By: John Baldwin <jhb@FreeBSD.org>
Change-Id: If2678b52836b1c3134a5e9f9fdaee74448d8b7bc
|
|
solib_map_sections errors out if the library file name is longer than
SO_NAME_MAX_PATH_SIZE.
solib::so_name and solib::so_original_name used to be arrays of
SO_NAME_MAX_PATH_SIZE size, so that check made sense then.
However, since commit 98107b0b17ac ("gdb: make
so_list::{so_original_name,so_name} std::strings") those fields are of
std::string type, so there's really no need for the limit.
This commit simply removes the length limit check.
Approved-By: John Baldwin <jhb@FreeBSD.org>
Change-Id: I2ec676b231cd18ae900c61c5caea461f47e989e6
|
|
I noticed that the disassembler_options code uses manual memory
management. It seemed simpler to replace this with std::string.
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
I found a few unnecessary casts when calling
set_gdbarch_disassembler_options_implicit.
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
This changes get_disassembler_options to return a const char *.
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
Define a new variable gpsize as gprsize * LOONGARCH_LINUX_NUM_GREGSET
to replace the related code in the first cb(), and also make use of
tabs and spaces in indentation to force the proper alignment of code,
then remove the empty line at the end of the function.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
This commit teaches GDB's gcore command to generate sparse core files
(if supported by the filesystem).
To create a sparse file, all you have to do is skip writing zeros to
the file, instead lseek'ing-ahead over them.
The sparse logic is applied when writing the memory sections, as
that's where the bulk of the data and the zeros are.
The commit also tweaks gdb.base/bigcore.exp to make it exercise
gdb-generated cores in addition to kernel-generated cores. We
couldn't do that before, because GDB's gcore on that test's program
would generate a multi-GB non-sparse core (16GB on my system).
After this commit, gdb.base/bigcore.exp generates, when testing with
GDB's gcore, a much smaller core file, roughly in line with what the
kernel produces:
real sizes:
$ du --hu testsuite/outputs/gdb.base/bigcore/bigcore.corefile.*
2.2M testsuite/outputs/gdb.base/bigcore/bigcore.corefile.gdb
2.0M testsuite/outputs/gdb.base/bigcore/bigcore.corefile.kernel
apparent sizes:
$ du --hu --apparent-size testsuite/outputs/gdb.base/bigcore/bigcore.corefile.*
16G testsuite/outputs/gdb.base/bigcore/bigcore.corefile.gdb
16G testsuite/outputs/gdb.base/bigcore/bigcore.corefile.kernel
Time to generate the core also goes down significantly. On my machine, I get:
when writing to an SSD, from 21.0s, down to 8.0s
when writing to an HDD, from 31.0s, down to 8.5s
The changes to gdb.base/bigcore.exp are smaller than they look at
first sight. It's basically mostly refactoring -- moving most of the
code to a new procedure which takes as argument who should dump the
core, and then calling the procedure twice. I purposely did not
modernize any of the refactored code in this patch.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31494
Reviewed-By: Lancelot Six <lancelot.six@amd.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Change-Id: I2554a6a4a72d8c199ce31f176e0ead0c0c76cff1
|
|
Ada 2022 includes a "delta aggregates" feature that can sometimes
simplify aggregate creation. This patch implements this feature for
GDB.
|
|
This patch makes allocate_on_obstack a little bit safer, by enforcing
the rule that objects allocated on an obstack must have a trivial
destructor.
The static assert is done in a method -- doing it inside the class
itself won't work because the class is incomplete at that point.
|
|
The addrmap polymorphism is sort of "phony" in that there isn't really
code in the tree that can be presented with either type. I haven't
tried to fix this (though perhaps I may); but meanwhile it's handy for
the next patch if addrmap_fixed has a trivial destructor. This patch
achieves this by making the addrmap destructor non-virtual, and also
making it protected so that objects of any of these types cannot be
destroyed when only the base class is known.
|
|
There are a few spots in the tree that use 'addrmap' where only an
addrmap_fixed will ever really be seen. This patch changes this code
to use the more specific type.
|
|
In commit a08dc2aa004b (gdb: syscalls: Add loongarch-linux.xml.in),
it needs special handling when generating xml file. This should at
least be mentioned in the file comment rather than git log to help
the next person who regenerates this file understand what needs to
be done, suggested by Pedro Alves, thank you.
At the beginning, I only added the tips in loongarch-linux.xml.in,
after executing the command "make" to generate loongarch-linux.xml
from loongarch-linux.xml.in, it generates the same tips in the file
loongarch-linux.xml automatically, so update loongarch-linux.xml.in
and loongarch-linux.xml together.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Approved-by: Pedro Alves <pedro@palves.net>
|
|
In loongarch_iterate_over_regset_sections(), the second and third arguments
of the iterate_over_regset_sections_cb callback function should be the regset
size which is regsize * regnum. Otherwise when execute:
make check-gdb TESTS="gdb.base/corefile.exp"
there exists the following failed log:
(gdb) core-file /home/fedora/community/gdb/build/gdb/testsuite/outputs/gdb.base/corefile/corefile.core
[New LWP 531099]
warning: Unexpected size of section `.reg-loongarch-lsx/531099' in core file.
warning: Unexpected size of section `.reg-loongarch-lasx/531099' in core file.
Core was generated by `/home/fedora/community/gdb/build/gdb/testsuite/outputs/gdb.base/corefile/corefile'.
Program terminated with signal SIGABRT, Aborted.
warning: Unexpected size of section `.reg-loongarch-lsx/531099' in core file.
warning: Unexpected size of section `.reg-loongarch-lasx/531099' in core file.
#0 0x00007ffff3081600 in __pthread_kill_implementation.constprop.0 () from /lib64/libc.so.6
(gdb) FAIL: gdb.base/corefile.exp: core-file warning-free
Signed-off-by: Hui Li <lihui@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
On a system without ipv6 support enabled, when running test-case
gdb.server/server-connect.exp, it takes about 4 minutes, and I get:
...
builtin_spawn gdbserver --once ::1:2347 server-connect^M
Can't open socket: Address family not supported by protocol.^M
Exiting^M
PASS: gdb.server/server-connect.exp: tcp6: start gdbserver
target remote tcp6:::1:2347^M
A program is being debugged already. Kill it? (y or n) y^M
could not connect: Address family not supported by protocol.^M
(gdb) FAIL: gdb.server/server-connect.exp: tcp6: connect to gdbserver using tcp6:::1
...
Fix this by:
- recognizing the error message in gdbserver_start, and returning an empty list
to signal unsupported, and
- handling the unsupported response in the test-case.
This brings testing time down to 2 seconds, and gets me:
...
UNSUPPORTED: gdb.server/server-connect.exp: tcp6: start gdbserver
UNSUPPORTED: gdb.server/server-connect.exp: tcp6-with-brackets: start gdbserver
UNSUPPORTED: gdb.server/server-connect.exp: udp6: start gdbserver
UNSUPPORTED: gdb.server/server-connect.exp: udp6-with-brackets: start gdbserver
...
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31502
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31502
|
|
On aarch64-linux (debian 12), when running test-case gdb.base/corefile-buildid.exp, I get:
...
expecting exec file "debugdir-exec/.build-id/ec/f10ec5d39648774f8c35d3cf757c8db52f5163"
info files^M
Local core dump file:^M
`build-exec/corefile-buildid.core', file type elf64-littleaarch64.^M
0x0000aaaac1d70000 - 0x0000aaaac1d71000 is load1^M
...
0x0000ffffffa8b000 - 0x0000ffffffaac000 is load16^M
(gdb) FAIL: gdb.base/corefile-buildid.exp: exec: info files
...
The problem is that the test-case expect the build-id to be available in the
core file, while it isn't.
Fix this by detecting that the build-id isn't available in the core file using eu-readelf, as in
gdb.base/coredump-filter-build-id.exp.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On aarch64-linux (debian 12), when running test-case
gdb.base/longjmp-until-in-main.exp, I run into:
...
(gdb) until 33^M
warning: Breakpoint address adjusted from 0x70f727c678928489 to 0xfff727c678928489.^M
Warning:^M
Cannot insert breakpoint 0.^M
Cannot access memory at address 0xfff727c678928489^M
^M
0x0000fffff7e3a580 in siglongjmp () from /lib/aarch64-linux-gnu/libc.so.6^M
(gdb) FAIL: gdb.base/longjmp-until-in-main.exp: until $line, in main
...
This is PR gdb/26967: no longjmp probe is available:
...
(gdb) info probes stap libc ^longjmp$^M
No probes matched.^M
...
and glibc applies pointer mangling which makes it fairly difficult for gdb to
get the longjmp target.
There's a KFAIL for this in test-case gdb.base/longjmp.exp, added in commit
b5e7cd5cd3d ("[gdb/testsuite] Add KFAILs in gdb.base/longjmp.exp").
Factor out new proc have_longjmp_probe, and use it to add similar KFAIL in
this and one more test-case.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
It's currently not possible to cast an in-memory value of a primitive
type to const reference:
```
(gdb) p Q.id
$1 = 42
(gdb) p (int&)Q.id
$2 = (int &) @0x22fd0c: 42
(gdb) p (const int&)Q.id
Attempt to take address of value not located in memory.
```
And if in a function call an argument needs the same kind of casting,
it also doesn't work:
```
(gdb) l f3
39 int f3(const int &i)
40 {
41 return i;
42 }
(gdb) p f3(Q.id)
Attempt to take address of value not located in memory.
```
It's because when the constness of the type changes in a call to
value_cast, a new not_lval value is allocated, which doesn't exist
in the target memory.
Fixed by ignoring const/volatile/restrict qualifications in
value_cast when comparing cast type to original type, so the new
value will point to the same location as the original value:
```
(gdb) p (int&)i
$2 = (int &) @0x39f72c: 1
(gdb) p (const int&)i
$3 = (const int &) @0x39f72c: 1
(gdb) p f3(Q.id)
$4 = 42
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19423
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Currently a reinterpret_cast may change the pointer value if
multiple inheritance is involved:
```
(gdb) p r
$1 = (Right *) 0x22f75c
(gdb) p reinterpret_cast<LeftRight*>(r)
$2 = (LeftRight *) 0x22f758
```
It's because value_cast is called in this case, which automatically
does up- and downcasting.
Fixed by simply using the target pointer type in a copy of the
original value:
```
(gdb) p r
$1 = (Right *) 0x3bf87c
(gdb) p reinterpret_cast<LeftRight*>(r)
$2 = (LeftRight *) 0x3bf87c
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18861
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Currently it's not possible to call functions if an argument is a
pointer to an array:
```
(gdb) l f
1 int f (int (*x)[2])
2 {
3 return x[0][1];
4 }
5
6 int main()
7 {
8 int a[2][2] = {{0, 1}, {2, 3}};
9 return f (a);
10 }
(gdb) p f(a)
Cannot resolve function f to any overloaded instance
```
This happens because types_equal doesn't handle array types, so the
function is never even considered as a possibility.
With array type handling added, by comparing element types and array
bounds, the same works:
```
(gdb) p f(a)
$1 = 1
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15398
Co-Authored-By: Keith Seitz <keiths@redhat.com>
Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Now, there exists syscalls/loongarch-linux.xml, let us set the correct
XML syscall filename for LoongArch, otherwise GDB won't be able to find
the correct XML file to open and get the syscalls definitions.
It should install the package expat-devel (a library for XML parsing)
and configure --with-expat (done by default if libexpat is installed
and found at configure time) for compiling gdb in this case.
Without this patch:
(gdb) catch syscall
warning: There is no XML file to open.
warning: GDB will not be able to display syscall names nor to verify if
any provided syscall numbers are valid.
Catchpoint 1 (any syscall)
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
It shows that "Don't know how to generate loongarch-linux.xml.in"
when using the script update-linux-from-src.sh to regenerate the
syscall group info against Linux kernel, just add loongarch case.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
Make use of the command "make" to generate loongarch-linux.xml
from loongarch-linux.xml.in.
Like this:
$ git clone https://sourceware.org/git/binutils-gdb.git gdb.git
$ cd gdb.git/gdb/syscalls/
$ make
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
There is no syscall.tbl for LoongArch because it uses generic syscalls,
so it can not generate loongarch-linux.xml.in automatically through the
script update-linux-from-src.sh, make use of the script update-linux.sh
to generate loongarch-linux.xml.in.
Like this:
$ git clone https://sourceware.org/git/binutils-gdb.git gdb.git
$ cd gdb.git/gdb/syscalls/
$ touch loongarch-linux.xml.in
$ ./update-linux.sh loongarch-linux.xml.in
Note that the system header file /usr/include/asm-generic/unistd.h
may be different with the latest upstream Linux kernel uapi header
file include/uapi/asm-generic/unistd.h, it is better to copy the
upstream header file into the system header file when generating
loongarch-linux.xml.in.
There exist some __NR3264_ prefixed syscall numbers, replace them
with digital numbers according to /usr/include/asm-generic/unistd.h
and sort them by syscall number manually, maybe we can modify the
script to do it automatically in the future.
<syscall name="fcntl" number="__NR3264_fcntl"/>
<syscall name="statfs" number="__NR3264_statfs"/>
<syscall name="fstatfs" number="__NR3264_fstatfs"/>
<syscall name="truncate" number="__NR3264_truncate"/>
<syscall name="ftruncate" number="__NR3264_ftruncate"/>
<syscall name="lseek" number="__NR3264_lseek"/>
<syscall name="sendfile" number="__NR3264_sendfile"/>
<syscall name="mmap" number="__NR3264_mmap"/>
<syscall name="fadvise64" number="__NR3264_fadvise64"/>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
Make use of the command "make" to regenerate .xml files from .xml.in files.
Like this:
$ git clone https://sourceware.org/git/binutils-gdb.git gdb.git
$ cd gdb.git/gdb/syscalls/
$ make
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
Make use of the script update-linux-from-src.sh to regenerate the Linux
syscall group info against Linux git commit d206a76d7d27 which will be
released in v6.8.
Like this:
$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux.git
$ git clone https://sourceware.org/git/binutils-gdb.git gdb.git
$ cd gdb.git/gdb/syscalls/
$ ./update-linux-from-src.sh ~/linux.git/
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
Make use of the script update-linux-defaults.sh to regenerate the Linux
syscall group info against strace git commit 8c480270653d which will be
released in v6.8.
Like this:
$ git clone https://github.com/strace/strace.git strace.git
$ git clone https://sourceware.org/git/binutils-gdb.git gdb.git
$ cd gdb.git/gdb/syscalls/
$ ./update-linux-defaults.sh ~/strace.git/
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
On arm-linux, with gas 2.40, I run into:
...
(gdb) x /i main+8^M
0x4e1 <main+7>: vrhadd.u16 d14, d14, d31^M
(gdb) FAIL: gdb.arch/pr25124.exp: disassemble thumb instruction (1st try)
...
This is a regression due to PR gas/31115, which makes gas produce a low_pc
with the thumb bit set (0x4d8 & 0x1):
...
<1><24>: Abbrev Number: 2 (DW_TAG_subprogram)
<25> DW_AT_name : main
<29> DW_AT_external : 1
<29> DW_AT_type : <0x2f>
<2a> DW_AT_low_pc : 0x4d9
<2e> DW_AT_high_pc : 12
...
The regression was introduced in 2.39, and is also present in 2.40 and 2.41,
and hasn't been fixed yet.
Work around this in read_func_scope, by using gdbarch_addr_bits_remove on
low_pc and high_pc.
Tested on arm-linux and x86_64-linux.
PR tdep/31453
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31453
|
|
I noticed that "info locals" on a certain large Ada program was very
slow. I tracked this down to ada_get_tsd_type expanding nearly every
CU in the program.
This patch fixes the problem by changing this code to use the more
efficient lookup_transparent_type which, unlike the Ada-specific
lookup functions, does not try to find all matching instances.
Note that I first tried fixing this by changing ada_find_any_type, but
this did not work -- I may revisit this approach at some later date.
Also note that the copyright dates on the test files are set that way
because I copied them from another test.
New in v2: the new test failed on the Linaro regression tester.
Looking at the logs, it seems that gdb was picking up a 'value' from
libgnat:
$1 = {<text variable, no debug info>} 0xf7e227a4 <ada.calendar.formatting.value>
This version renames the local variable in an attempt to work around
this.
v3: In v2, while trying to reproduce the problem locally, I
accidentally forgot to commit one of the changes.
|
|
flake8 points out that some code in frame_filters.py is referring to
undefined variables.
In the first hunk, I've changed the code to match what other
'complete' methods do in this file.
In the second hunk, I've simply removed the try/except -- if
get_filter_priority fails, it will raise GdbError, which is already
handled properly by gdb.
|
|
The gdb.solib_name() and Progspace.solib_name() functions can throw an
exception if the address argument is not a valid address, but this is
not currently tested.
This commit adds a couple of tests to check that exceptions are thrown
correctly.
An early version of this commit updated the documentation, but it was
pointed out that lots of functions throw an exception if passed an
argument of the wrong type, and we don't document all of these, it's
kind-of assumed that passing an object of the incorrect type might
result in an exception, so this updated version leaves the docs alone,
but I do think adding the extra tests has value.
There's no changes to GDB itself in this commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
symtab-> linetable () is set to null in
buildsym_compunit::end_compunit_symtab_with_blockvector () if the symtab
has no linetable. Attempting to iterate over this linetable using the
Python API caused GDB to segfault.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
In commit 2aaba744467 ("[gdb] Fix "value is not available" with debug frame")
I fixed a case in frame_unwind_register_value where using "set debug frame on"
caused an "info frame" command to abort, reporting a "value is not available"
error, due to the tpidruro register being unavailable.
Subsequently, commit bbb12eb9c84 ("gdb/arm: Remove tpidruro register from
non-FreeBSD target descriptions") removed the unavailable register, which
caused a progression on test-case gdb.base/inline-frame-cycle-unwind.exp.
While investigating the progression (see PR python/31437), I found that the
"debug frame" output of the test-case (when reverting commit bbb12eb9c84)
showed a smilar problem:
...
Python Exception <class 'gdb.error'>: value is not available^M
...
that was absent without "debug frame".
Fix this likewise in fetch_lazy_register, and update the test-case to check
for the exception.
Furthermore, I realized that there's both value::entirely_available and
value::entirely_unavailable, and that commit 2aaba744467 handled the case
of !entirely_available by printing unavailable.
Instead, print:
- "unavailable" for entirely_unavailable, and
- "partly unavailable" for !entirely_unavailable && !entirely_available.
Tested on x86_64-linux and arm-linux.
|
|
ada_bitwise_operation differs from the "usual" bitwise operations only
in that it calls value_cast at the end. However, because gdb is
generally fairly lax about integer types, and because (perhaps oddly)
C-style binary promotion is done here anyway, it seems to me that this
code isn't needed.
|
|
ptype is a bit funny, in that it accepts both expressions and type
names. It also evaluates the resulting expression using
EVAL_AVOID_SIDE_EFFECTS -- which both seems sensible (as a user would
you expect ptype to possibly cause inferior execution?), but is also a
historical artifact of how expressions are implemented (there's no
EVAL_FOR_TYPE).
In Ada, calling a function with an array will sometimes result in a
"thick pointer" array descriptor being made. This is essentially a
structure holding a pointer and bounds information.
Currently, in such a callee, printing the type of the array will yield
funny results:
(gdb) print str.all
$1 = "Hello World"
(gdb) ptype str
type = array (<>) of character
(gdb) ptype str.all
type = array (1 .. 0) of character
That "1 .. 0" is the result of an EVAL_AVOID_SIDE_EFFECTS branch
trying to do "something" with an array descriptor, without doing too
much.
I tried briefly to make this code really dereference the array
descriptor and get the correct runtime type. However, that proved to
be tricky; it certainly can't be done for all access types, because
that will cause dynamic type resolution and end up printing just the
runtime type -- which with variants may be pretty far from what the
user may expect.
Instead, this patch arranges to just leave such types alone in this
situation. I don't think this should have an extra effects, because
things like array subscripting still work on thick pointers.
This patch also touches arrayptr.exp, because in that case the access
type is a "thin pointer", and this ensures that the output does not
change in that scenario.
|
|
quirk_rust_enum makes string copies to store in an unordered_map.
However, the original strings have an appropriate lifetime, and so no
copying is needed. With C++17, we can rely on string_view having a
std::hash specialization, so this patch changes this code to use
string_view rather than string.
|
|
This patch arranges to set __file__ when source'ing a Python script.
This fixes a problem that was introduced by the "source" rewrite, and
then pointed out by Lancelot Six.
Reviewed-by: Lancelot Six <lancelot.six@amd.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
When certain DAP tests are run in a certain order, dejagnu will throw
an exception during shutdown. After adding many logging statements, I
tracked this down to kill_wait_spawned_process not clearing the
'fileid' board_info entry, causing dejagnu to try to wait for the
process a second time -- and fail.
Tom de Vries then pointed out a second instance of this, which I
tracked down to the same problem occurring when spawning gdbserver.
This version of the patch fixes this by adding a new proc that can be
used to clean up board_info after waiting for a process to exit. I'm
not sure why this problem hasn't affected the test suite in the past.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31435
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Fedora GDB has carried around a patch for a while which tested
attaching to an i386 process which is stopped within the vDSO library
region. Apparently, at some point in the distant past there was an
issue finding symbol information for this region in this situation.
I'm struggling to track down the precise details of what the original
bug was, however, acquiring symbol information for the vDSO region is
different than for "normal" shared libraries -- the vDSO information
is synthesised within GDB during the attach / inferior creation
process -- so it's not unreasonable to imagine that there could be a
bug specifically in this area of GDB which wouldn't impact "normal"
shared libraries.
I looked for references to vDSO in our testsuite and couldn't find
any tests that looked like they did the same sort of thing, so I'd
like to propose adding this test to our testsuite.
It's a pretty simple test, and doesn't take long to run, so the cost
of adding this is not huge.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On debian 12, aarch64-linux I run into:
...
(gdb) list .^M
No symbol table is loaded. Use the "file" command.^M
(gdb) FAIL: gdb.base/list-nodebug.exp: first 'list .'
...
The test-case expects some debug info, but none for main. Instead, there's no
debug info at all.
Fix this by adding another source file to the test-case, and compiling it with
debug info.
Tested on aarch64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR testsuite/31290
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31290
|
|
BFD recently changed bfd_mmap to use size_t, not bfd_size_type. This
patch updates gdb_bfd_section_data to follow. Without this patch, if
the two types ever differ, gdb would fail to build.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
When the GCC compiler plugin responds with GCC_C_FE_VERSION_2, gdb can
use the new 'finish_record_with_alignment' method. This lets gdb pass
alignment information to the compiler, which in turn fixes the test
case included in this patch.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31397
|
|
This removes the embedded 'if' from GDB_PY_HANDLE_EXCEPTION and
GDB_PY_SET_HANDLE_EXCEPTION. I believe this 'if' was necessary with
the old gdb try/catch macros, but it no longer is: these should only
ever be called from a 'catch' block, where it's already known that an
exception was thrown.
Simon pointed out, though, that in a few spots, these were in facts
called outside of 'catch' blocks. This patch cleans up these spots.
I also found one spot where a redundant 'return nullptr' could be
removed.
|
|
On aarch64-linux, with test-case gdb.base/watchpoint-unaligned.exp I run into:
...
(gdb) watch data.u.size8twice[1]^M
Hardware watchpoint 241: data.u.size8twice[1]^M
(gdb) PASS: gdb.base/watchpoint-unaligned.exp: watch data.u.size8twice[1]
continue^M
Continuing.^M
FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)
FAIL: gdb.base/watchpoint-unaligned.exp: size8twice write
...
This happens as follows.
We start the exec and set an 8-byte hardware watchpoint on
data.u.size8twice[1] at address 0x440048:
...
(gdb) p sizeof (data.u.size8twice[1])
$1 = 8
(gdb) p &data.u.size8twice[1]
$2 = (uint64_t *) 0x440048 <data+16>
...
We continue execution, and a 16-byte write at address 0x440040 triggers the
hardware watchpoint:
...
4101c8: a9000801 stp x1, x2, [x0]
...
When checking whether a watchpoint has triggered in
aarch64_stopped_data_address, we check against address 0x440040 (passed in
parameter addr_trap). This behaviour is documented:
...
/* ADDR_TRAP reports the first address of the memory range
accessed by the CPU, regardless of what was the memory
range watched. ... */
...
and consequently the matching logic compares against an addr_watch_aligned:
...
&& addr_trap >= addr_watch_aligned
&& addr_trap < addr_watch + len)
...
However, the comparison fails:
...
(gdb) p /x addr_watch_aligned
$3 = 0x440048
(gdb) p addr_trap >= addr_watch_aligned
$4 = false
...
Consequently, aarch64_stopped_data_address returns false, and
stopped_by_watchpoint returns false, and watchpoints_triggered returns 0,
which make infrun think it's looking at a delayed hardware
breakpoint/watchpoint trap:
...
[infrun] handle_signal_stop: stop_pc=0x4101c8
[infrun] handle_signal_stop: delayed hardware breakpoint/watchpoint trap, ignoring
...
Infrun then ignores the trap and continues, but runs into the same situation
again and again, causing a hang which then causes the test timeout.
Fix this by allowing a match 8 bytes below addr_watch_aligned. This
introduces the possibility for false positives, so we only do this for regular
"value changed" watchpoints.
An earlier version of this patch worked by aligning addr_watch_aligned to 16
instead of 8:
...
- const CORE_ADDR addr_watch_aligned = align_down (state->dr_addr_wp[i], 8);
+ const CORE_ADDR addr_watch_aligned = align_down (state->dr_addr_wp[i], 16);
...
but while that fixed the test-case, it didn't fix the problem completely, so
extend the test-case to check more scenarios.
Tested on aarch64-linux.
Tested-By: Luis Machado <luis.machado@arm.com>
Approved-By: Luis Machado <luis.machado@arm.com>
PR tdep/29423
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29423
|
|
I noticed that the manual has an extra "either", which makes a
sentence ungrammatical. This patch removes it.
|
|
On aarch64-linux, with test-case gdb.base/watch-bitfields.exp I run into:
...
(gdb) continue^M
Continuing.^M
^M
Hardware watchpoint 2: -location q.a^M
^M
Old value = 1^M
New value = 0^M
main () at watch-bitfields.c:42^M
42 q.h--;^M
(gdb) FAIL: $exp: -location watch against bitfields: q.e: 0->5: continue
...
In a minimal form, if we step past line 37 which sets q.e, and we have a
watchpoint set on q.e, it triggers:
...
$ gdb -q -batch watch-bitfields -ex "b 37" -ex run -ex "watch q.e" -ex step
Breakpoint 1 at 0x410204: file watch-bitfields.c, line 37.
Breakpoint 1, main () at watch-bitfields.c:37
37 q.e = 5;
Hardware watchpoint 2: q.e
Hardware watchpoint 2: q.e
Old value = 0
New value = 5
main () at /home/vries/gdb/src/gdb/testsuite/gdb.base/watch-bitfields.c:38
38 q.f = 6;
...
However, if we set in addition a watchpoint on q.a, the watchpoint on q.e
doesn't trigger.
How does this happen?
Bitfield q.a is just bit 0 of byte 0, and bitfield q.e is bit 4..7 of byte 1
and bit 1 of byte 2. So, watch q.a should watch byte 0, and watch q.e should
watch bytes 1 and 2.
Using "maint set show-debug-regs on" (and some more detailed debug prints) we
get:
...
WP2: addr=0x440028 (orig=0x440029), ctrl=0x000000d5, ref.count=1
ctrl: enabled=1, offset=1, len=2
WP3: addr=0x440028 (orig=0x440028), ctrl=0x00000035, ref.count=1
ctrl: enabled=1, offset=0, len=1
...
which matches that.
When executing line 37, a hardware watchpoint trap triggers and we hit
aarch64_stopped_data_address with addr_trap == 0x440028:
...
(gdb) p /x addr_trap
$1 = 0x440028
....
and since the loop in aarch64_stopped_data_address walks backward, we check
WP3 first, which matches, and consequently target_stopped_by_watchpoint
returns true in watchpoints_triggered.
Likewise for target_stopped_data_address, which also returns addr == 0x440028.
Watchpoints_triggered matches watchpoint q.a to that address, and sets
watch_triggered_yes.
However, subsequently the value of q.a is checked, and it's the same value as
before (becase the insn in line 37 didn't change q.a), so the watchpoint
hardware trap is not reported to the user.
The problem originates from that fact that aarch64_stopped_data_address picked
WP3 instead of WP2.
There's something we can do about this. In the example above, both
target_stopped_by_watchpoint and target_stopped_data_address returned true.
Instead we can return true in target_stopped_by_watchpoint but false in
target_stopped_data_address. This lets watchpoints_triggered known that a
watchpoint was triggered, but we don't know where, and both watchpoints
get set to watch_triggered_unknown.
Subsequently, the values of both q.a and q.e are checked, and since q.e is not
the same value as before, the watchpoint hardware trap is reported to the user.
Note that this works well for regular (write) watchpoints (watch command), but
not for read watchpoints (rwatch command), because for those no value is
checked. Likewise for access watchpoints (awatch command).
So, fix this by:
- passing a nullptr in aarch64_fbsd_nat_target::stopped_by_watchpoint and
aarch64_linux_nat_target::stopped_by_watchpoint to make clear we're not
interested in the stop address,
- introducing a two-phase approach in aarch64_stopped_data_address, where:
- phase one handles access and read watchpoints, as before, and
- phase two handles write watchpoints, where multiple matches cause:
- return true if addr_p == null, and
- return false if addr_p != null.
Tested on aarch64-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
PR tdep/31214
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31214
|
|
This patch deprecates the MPX commands "show/set mpx bound".
Intel listed Intel(R) Memory Protection Extensions (MPX) as removed
in 2019. Following gcc v9.1, the linux kernel v5.6 and glibc v2.35,
deprecate MPX in GDB.
|
