This commit is part of a series to share more of the x86 target
description creation code between GDB and gdbserver.
Unlike previous commits which were mostly refactoring, this commit is
the first that makes a real change, though that change should mostly
be for gdbserver; I've largely adopted the "GDB" way of doing things
for gdbserver, and this fixes a real gdbserver bug.
On a x86-64 Linux target, running the test:
gdb.server/connect-with-no-symbol-file.exp
results in two core files being created. Both of these core files are
from the inferior process, created after gdbserver has detached.
In this test a gdbserver process is started and then, after gdbserver
has started, but before GDB attaches, we either delete the inferior
executable, or change its permissions so it can't be read. Only after
doing this do we attempt to connect with GDB.
As GDB connects to gdbserver, gdbserver attempts to figure out the
target description so that it can send the description to GDB, this
involves a call to x86_linux_read_description.
In x86_linux_read_description one of the first things we do is try to
figure out if the process is 32-bit or 64-bit. To do this we look up
the executable via the thread-id, and then attempt to read the
architecture size from the executable. This isn't going to work if
the executable has been deleted, or is no longer readable.
And so, as we can't read the executable, we default to an i386 target
and use an i386 target description.
A consequence of using an i386 target description is that addresses
are assumed to be 32-bits. Here's an example session that shows the
problems this causes. This is run on an x86-64 machine, and the test
binary (xx.x) is a standard 64-bit x86-64 binary:
shell_1$ gdbserver --once localhost :54321 /tmp/xx.x
shell_2$ gdb -q
(gdb) set sysroot
(gdb) shell chmod 000 /tmp/xx.x
(gdb) target remote :54321
Remote debugging using :54321
warning: /tmp/xx.x: Permission denied.
0xf7fd3110 in ?? ()
(gdb) show architecture
The target architecture is set to "auto" (currently "i386").
(gdb) p/x $pc
$1 = 0xf7fd3110
(gdb) info proc mappings
process 2412639
Mapped address spaces:
Start Addr End Addr Size Offset Perms objfile
0x400000 0x401000 0x1000 0x0 r--p /tmp/xx.x
0x401000 0x402000 0x1000 0x1000 r-xp /tmp/xx.x
0x402000 0x403000 0x1000 0x2000 r--p /tmp/xx.x
0x403000 0x405000 0x2000 0x2000 rw-p /tmp/xx.x
0xf7fcb000 0xf7fcf000 0x4000 0x0 r--p [vvar]
0xf7fcf000 0xf7fd1000 0x2000 0x0 r-xp [vdso]
0xf7fd1000 0xf7fd3000 0x2000 0x0 r--p /usr/lib64/ld-2.30.so
0xf7fd3000 0xf7ff3000 0x20000 0x2000 r-xp /usr/lib64/ld-2.30.so
0xf7ff3000 0xf7ffb000 0x8000 0x22000 r--p /usr/lib64/ld-2.30.so
0xf7ffc000 0xf7ffe000 0x2000 0x2a000 rw-p /usr/lib64/ld-2.30.so
0xf7ffe000 0xf7fff000 0x1000 0x0 rw-p
0xfffda000 0xfffff000 0x25000 0x0 rw-p [stack]
0xff600000 0xff601000 0x1000 0x0 r-xp [vsyscall]
(gdb) info inferiors
Num Description Connection Executable
* 1 process 2412639 1 (remote :54321)
(gdb) shell cat /proc/2412639/maps
00400000-00401000 r--p 00000000 fd:03 45907133 /tmp/xx.x
00401000-00402000 r-xp 00001000 fd:03 45907133 /tmp/xx.x
00402000-00403000 r--p 00002000 fd:03 45907133 /tmp/xx.x
00403000-00405000 rw-p 00002000 fd:03 45907133 /tmp/xx.x
7ffff7fcb000-7ffff7fcf000 r--p 00000000 00:00 0 [vvar]
7ffff7fcf000-7ffff7fd1000 r-xp 00000000 00:00 0 [vdso]
7ffff7fd1000-7ffff7fd3000 r--p 00000000 fd:00 143904 /usr/lib64/ld-2.30.so
7ffff7fd3000-7ffff7ff3000 r-xp 00002000 fd:00 143904 /usr/lib64/ld-2.30.so
7ffff7ff3000-7ffff7ffb000 r--p 00022000 fd:00 143904 /usr/lib64/ld-2.30.so
7ffff7ffc000-7ffff7ffe000 rw-p 0002a000 fd:00 143904 /usr/lib64/ld-2.30.so
7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0
7ffffffda000-7ffffffff000 rw-p 00000000 00:00 0 [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
(gdb)
Notice the difference between the mappings reported via GDB and those
reported directly from the kernel via /proc/PID/maps, the addresses of
every mapping is clamped to 32-bits for GDB, while the kernel reports
real 64-bit addresses.
Notice also that the $pc value is a 32-bit value. It appears to be
within one of the mappings reported by GDB, but is outside any of the
mappings reported from the kernel.
And this is where the problem arises. When gdbserver detaches from
the inferior we pass the inferior the address from which it should
resume. Due to the 32/64 bit confusion we tell the inferior to resume
from the 32-bit $pc value, which is not within any valid mapping, and
so, as soon as the inferior resumes, it segfaults.
If we look at how GDB (not gdbserver) figures out its target
description then we see an interesting difference. GDB doesn't try to
read the executable. Instead GDB uses ptrace to query the thread's
state, and uses this to figure out the if the thread is 32 or 64 bit.
If we update gdbserver to do it the "GDB" way then the above problem
is resolved, gdbserver now sees the process as 64-bit, and when we
detach from the inferior we give it the correct 64-bit address, and
the inferior no longer segfaults.
Now, I could just update the gdbserver code, but better, I think, to
share one copy of the code between GDB and gdbserver in gdb/nat/.
That is what this commit does.
The cores of x86_linux_read_description from gdbserver and
x86_linux_nat_target::read_description from GDB are moved into a new
file gdb/nat/x86-linux-tdesc.c and combined into a single function
x86_linux_tdesc_for_tid which is called from each location.
This new function does things the GDB way, the only changes are to
allow for the sharing; we now have a callback function to call the
first time that the xcr0 state is read, this allows for GDB and
gdbserver to perform their own initialisation as needed, and
additionally, the new function takes a pointer for where to cache the
xcr0 value, this isn't needed for this commit, but will be useful in a
later commit where gdbserver will want to read this cached xcr0
value.
Another thing to note about this commit is how the functions
i386_linux_read_description and amd64_linux_read_description are
handled. For now I've left these function as implemented separately
in GDB and gdbserver. I've moved the declarations of these functions
into gdb/nat/x86-linux-tdesc.h, but the implementations are left as
separate.
A later commit in this series will make these functions shared too,
but doing this is not trivial, so I've left that for a separate
commit. Merging the declarations as I've done here ensures that
everyone implements the function to the same API, and once these
functions are shared (in a later commit) we'll want a shared
declaration anyway.
Approved-By: John Baldwin <jhb@FreeBSD.org>
Share the definition of I386_LINUX_XSAVE_XCR0_OFFSET between GDB and
gdbserver.
This commit is part of a series that aims to share more of the x86
target description creation code between GDB and gdbserver. The
I386_LINUX_XSAVE_XCR0_OFFSET #define is used as part of the target
description creation, and I noticed that this constant is defined
separately for GDB and gdbserver.
This commit moves the definition into gdb/nat/x86-linux.h, which
allows the #define to be shared.
There should be no user visible changes after this commit.
Approved-By: John Baldwin <jhb@FreeBSD.org>
This commit is part of a series that aims to share more of the x86
target description reading/generation code between GDB and gdbserver.
There are a huge number of similarities between the code in
gdbserver's x86_linux_read_description function and GDB's
x86_linux_nat_target::read_description function, and it is this
similarity that I plan, in a later commit, to share between GDB and
gdbserver.
However, one thing that is different in x86_linux_read_description is
the code inside the '!use_xml' block. This is the code that handles
the case where gdbserver is not allowed to send an XML target
description back to GDB. In this case gdbserver uses some predefined,
fixed, target descriptions.
First, it's worth noting that I suspect this code is not tested any
more. I couldn't find anything in the testsuite that tries to disable
XML target description support. And the idea of having a single
"fixed" target description really doesn't work well when we think
about all the various x86 extensions that exist. Part of me would
like to rip out the no-xml support in gdbserver (at least for x86),
and if a GDB connects that doesn't support XML target descriptions,
gdbserver can just give an error and drop the connection. GDB has
supported XML target descriptions for 16 years now, I think it would
be reasonable for our shipped gdbserver to drop support for the old
way of doing things.
Anyway.... this commit doesn't do that.
What I did notice was that, over time, the '!use_xml' block appears to
have "drifted" within the x86_linux_read_description function; it's
now not the first check we do. Instead we make some ptrace calls and
return a target description generated based on the result of these
ptrace calls. Surely it only makes sense to generate variable target
descriptions if we can send these back to GDB?
So in this commit I propose to move the '!use_xml' block earlier in
the x86_linux_read_description function.
The benefit of this is that this leaves the later half of
x86_linux_read_description much more similar to the GDB function
x86_linux_nat_target::read_description and sets us up for potentially
sharing code between GDB and gdbserver in a later commit.
Approved-By: John Baldwin <jhb@FreeBSD.org>
This patch is part of a series that has the aim of making the code
that, for x86, reads the target description for a native process
shared between GDB and gdbserver.
Within GDB part of this process involves reading the cs and ds state
from the 'struct user_regs_struct' using a ptrace call.
This isn't done by gdbserver, which is part of the motivation for this
whole series; the approach gdbserver takes is inferior to the approach
GDB takes.
This commit moves the reading of cs and ds, which is used to figure
out if a thread is 32-bit or 64-bit (or in x32 mode), into the gdb/nat
directory so that the code could be shared with gdbserver, but at this
point I'm not actually using the code in gdbserver, that will come
later.
As such there should be no user visible changes after this commit, GDB
continues to do things as it did before (reading cs/ds), while
gdbserver continues to use its own approach (which doesn't require
reading cs/ds).
Approved-By: John Baldwin <jhb@FreeBSD.org>
Convert the have_ptrace_getregset global within gdbserver to a
tribool. This brings the flag into alignment with the corresponding
flag in GDB.
The gdbserver have_ptrace_getregset variable is already used as a
tribool, it just doesn't have the tribool type.
In a future commit I plan to share more code between GDB and
gdbserver, and having this variable be the same type in both code
bases will make the sharing much easier.
There should be no user visible changes after this commit.
Approved-By: John Baldwin <jhb@FreeBSD.org>
With gcc 13, test-case gdb.ada/tagged-lookup.exp passes for me, but with gcc
12, I get:
...
(gdb) set debug symtab-create 1^M
(gdb) print *the_local_var^M
...
$1 = (n => 2)^M
(gdb) FAIL: gdb.ada/tagged-lookup.exp: only one CU expanded
...
The problem is that this fails:
...
-re -wrap ".* = \\\(n => $decimal\\\)" {
if {$found_pck + $found_pck2 == 1} {
pass $gdb_test_name
} else {
fail $gdb_test_name
}
...
because $found_pck == 0 and $found_pck2 == 0.
Indeed, with gcc 13 we have:
...
$ grep "start_subfile: name = .*/tagged-lookup/" gdb.log | sed 's%.*/%%'
b~foo.adb
b~foo.adb
b~foo.adb
b~foo.ads
pck2.adb
pck2.adb
pck2.ads
pck2.adb
pck2.ads
...
and with gcc 12:
...
$ grep "start_subfile: name = .*/tagged-lookup/" gdb.log | sed 's%.*/%%'
b~foo.adb
b~foo.adb
b~foo.adb
b~foo.ads
...
Fix this by checking for "$found_pck + $found_pck2 <= 1" instead.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31514
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31514
Commit 467a34bb9e ("gdb tests: Allow for "LWP" or "process" in thread IDs
from info threads") introduces a new global variable tdlabel_re, but fails to
indicate it's global when used in procs in four test-cases.
Fix this by adding "global tdlabel_re".
Tested on aarch64-linux.
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 98107b0b17 ("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>
This reverts commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f.
This patch caused problems for some users when building gdb, because
it would cause 'guild' to be invoked with the wrong versin of guile.
On the whole it seems simpler to just back this out.
I'm checking this in to the binutils-gdb repository in the interest of
fixing the build for Andrew. No one has responded to the identical
patch sent to gcc-patches, but I will ping it there.
* Makefile.in: Rebuild.
* Makefile.tpl (BASE_EXPORTS): Remove GUILE.
(GUILE): Remove.
* Makefile.def (flags_to_pass): Remove GUILE.
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
For one 0afc614c99 ("x86: Warn .insn instruction with length > 15
bytes") introduced a .insn use involving a slash; such tests need to
have --divide passed to gas.
And then 5bc71c2a6b ("x86-64: Add R_X86_64_CODE_6_GOTTPOFF") broke
BFD_RELOC_X86_64_GOTTPOFF conversion to R_X86_64_CODE_4_GOTTPOFF, by
adding respective code in a section guarded by
generate_relax_relocations (the case of that not being required there
was limited to 32-bit object files). Re-arrange that block of code to
check generate_relax_relocations later.
Since MPX isn't available for x32, we should clear X86_XSTATE_MPX bits
on x32.
PR server/31511
* linux-x86-low.cc (x86_linux_read_description): Clear
X86_XSTATE_MPX bits in xcr0 on x32.
Reviewed-by: Felix Willgerodt <felix.willgerodt@intel.com>
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.
EVENT_MAX is defined as 0x7FFFFFFF (INT_MAX) in winuser.h, so when
building on Windows, the value is overridden and compilation fails
because the array size of evbuf is too large.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28476
Approved-By: Tom Tromey <tom@tromey.com>
In commit a08dc2aa00 (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>
Running `pre-commit autoupdate` showed that there is a new version of
the black hook for v24.3.0. Update it.
ChangeLog:
* .pre-commit-config.yaml: Bump black hook to 24.3.0
Change-Id: I5ec7d2edf99cd15f6525281a43aed9ff481ee9ee
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
b5e7cd5cd3 ("[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>
Add a pre-commit [1] config file, with a single hook to run black on the
gdb directory whenever a Python file is modified. We can always add
more hooks if we find some that are useful.
Using pre-commit to run hooks is opt-in, as in it's not mandatory at all
for development, but it can be useful to run some checks that are easy
to forget (like running black). The hooks run locally on the
developer's machine when doing `git commit` (although they can also be
configured to run at other stages of the git workflow).
Follow these instructions to install the hooks in your local development
git repository:
- Install pre-commit the way you prefer. It can be using your OS
package manager if it has a recent enough version, or using `pip
install pre-commit`.
- Go to the binutils-gdb repository and run `pre-commit install`.
This installs a git hook at `.git/hooks/pre-commit`.
Now, whenever you modify and try to commit a Python file, pre-commit
will run black on it. For instance, if I try to insert something
misformatted, I get this when doing `git commit`:
$ git commit
black....................................................................Failed
- hook id: black
- files were modified by this hook
reformatted gdb/python/lib/gdb/dap/breakpoint.py
All done! ✨🍰✨
1 file reformatted.
At this point, black has already reformatted the files in place, so the
changes that fix the formatting are ready to add and commit. black is
only ran on files modified in the commit.
The hook defines a black version, which is downloaded at `pre-commit
install` time. pre-commit manages its own env at
`$HOME/.cache/pre-commit/<some-hash>`, so it won't use the version of
black you have installed already. This may help ensure that
contributors use the right black version.
The procedure when there is a new version of black (or a new version of
any hook we might be using in the future) is:
- Modify .pre-commit-config.yaml to change the version number, push to
the upstream repo.
- Have contributors run `pre-commit autoupdate` to make their local
pre-commit installation update the hooks.
It is possible to have pre-commit skip some hooks if needed [2].
I will add these instructions to the wiki if this patch gets merged, so
they are easy to find. We could perhaps think of having a
gdb/CONTRIBUTING document of some sort checked in the repo with that
kind of information.
I have not used pre-commit in a real project before, but have heard good
things from it. If we want to give it a try before pushing it to the
repo, some volunteers can copy the .pre-commit-config.yaml file locally
and try it for some time. However, pushing the file upstream is not
going to impact anybody who doesn't care about it, so I'd say it's
relatively low-risk to push it right now.
[1] https://pre-commit.com
[2] https://pre-commit.com/#temporarily-disabling-hooks
Change-Id: Id00cda882f5140914a670c87e574fa7f2f972099
Acked-By: Tom Tromey <tromey@adacore.com>
Acked-By: Guinevere Larsen <blarsen@redhat.com>
Acked-By: Andrew Burgess <aburgess@redhat.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
