The rules seem to generate the same output as existing subdir cgen
rules with cgen ports, so hopefully this should be correct. These
are the last set of codegen rules that we run in subdirs, so this
will help unblock killing off subdir builds entirely.
Rather than define our own hack for emitting an include statement,
use the existing Automake include variables. These have the nice
side-effect of being more portable.
The Debugger Adapter Protocol is a JSON-RPC protocol that IDEs can use
to communicate with debuggers. You can find more information here:
https://microsoft.github.io/debug-adapter-protocol/
Frequently this is implemented as a shim, but it seemed to me that GDB
could implement it directly, via the Python API. This patch is the
initial implementation.
DAP is implemented as a new "interp". This is slightly weird, because
it doesn't act like an ordinary interpreter -- for example it doesn't
implement a command syntax, and doesn't use GDB's ordinary event loop.
However, this seemed like the best approach overall.
To run GDB in this mode, use:
gdb -i=dap
The DAP code will accept JSON-RPC messages on stdin and print
responses to stdout. GDB redirects the inferior's stdout to a new
pipe so that output can be encapsulated by the protocol.
The Python code uses multiple threads to do its work. Separate
threads are used for reading JSON from the client and for writing JSON
to the client. All GDB work is done in the main thread. (The first
implementation used asyncio, but this had some limitations, and so I
rewrote it to use threads instead.)
This is not a complete implementation of the protocol, but it does
implement enough to demonstrate that the overall approach works.
There is a rudimentary test suite. It uses a JSON parser written in
pure Tcl. This parser is under the same license as Tcl itself, so I
felt it was acceptable to simply import it into the tree.
There is also a bit of documentation -- just documenting the new
interpreter name.
The cced7cacec ("gdb: preserve `|` in connection details string")
commit added '|' detection and removal to ser-pipe.c, but missed to add it
to ser-mingw.c.
This results in the error message below for MinGW hosts:
error starting child process '| <executable> <args>': CreateProcess: No such file or directory
This commit add the missing '|' detection and removal to ser-mingw.c.
I noticed that, when using gdbserver, gdb might print:
Reading /usr/lib/debug/lib64//libcap.so.2.48-2.48-4.fc36.x86_64.debug from remote target...
Reading target:/usr/lib/debug/lib64//libcap.so.2.48-2.48-4.fc36.x86_64.debug from remote target...
The second line has the "target:" prefix, but from the code it's clear
that this string is being passed verbatim to gdbserver -- which seems
wrong.
I filed PR remote/29929 for this.
The problem here is that find_separate_debug_file uses gdb_sysroot
without checking to see if it starts with the "target:" prefix. This
patch changes this code to be a little more careful.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29929
On x86_64-linux, I run into:
...
(gdb) python hbp1 = gdb.Breakpoint("add", type=gdb.BP_HARDWARE_BREAKPOINT)^M
Hardware assisted breakpoint 2 at 0x40072e: add. (7 locations)^M
(gdb) FAIL: gdb.python/py-breakpoint.exp: test_hardware_breakpoints: \
Set hardware breakpoint
...
due to libstdc++ debug info:
...
$ gdb -q -batch outputs/gdb.python/py-breakpoint/py-breakpoint \
-ex start \
-ex "b add" \
-ex "info break"
Temporary breakpoint 1 at 0x40076a: file py-breakpoint.c, line 50.
Temporary breakpoint 1, main (argc=1, argv=$hex) at py-breakpoint.c:50
50 int foo = 5;
Breakpoint 2 at 0x40072e: add. (7 locations)
Num Type Disp Enb Address What
2 breakpoint keep y <MULTIPLE>
2.1 y 0x000000000040072e in add(int) at \
py-breakpoint.c:39
2.2 y 0x00007ffff7b131de in \
(anonymous namespace)::fast_float::bigint::add at \
../../../../../libstdc++-v3/src/c++17/fast_float/fast_float.h:1815
...
2.7 y 0x00007ffff7b137e4 in \
(anonymous namespace)::fast_float::bigint::add at \
../../../../../libstdc++-v3/src/c++17/fast_float/fast_float.h:1815
...
Fix this by using qualified=True.
Tested on x86_64-linux.
PR testsuite/29910
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29910
Clean up includes a bit by making ports include bfd/ headers
explicitly. This matches other projects, and makes it more clear
where these headers are coming from.
Clean up includes a bit by making ports include opcodes/ headers
explicitly. This matches other projects, and makes it more clear
where these headers are coming from.
Delete a few files only used for obsolete targets, and tidy config,
xfails and other pieces of support specific to those targets. And
since I was editing target triplets in test files, fix the nm
alpha-linuxecoff fails.
These defines seem to have been added in anticipation of adding another
cpu port (IQ10BF?), but that was over 20 years ago, and that port has
yet to materialize. So drop these compile flags since they don't do
anything to the generated code. If another port ever shows up, it's
easy enough to readd things as needed.
This commit updates the following file...
gdb/doc/gdb.texinfo
gdb/doc/refcard.tex
gdb/syscalls/update-netbsd.sh
... by hand as instructed by the gdb/copyright.py script.
The update by hand is needed because the copyright headers
to update are actually nested inside those files, rather
than located at the start of the file.
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
... to sim/ppc/powerpc.igen
This file is in the NOT_FSF_LIST because this file has a copyright
which is not assigned to the FSF. Since the file got renamed,
the corresponding entry in NOT_FSF_LIST needs to be renamed as well.
This commit updates the copyright year displayed by gdb, gdbserver
and gdbreplay's help message from 2022 to 2023, as per our Start
of New Year procedure. The corresponding source files' copyright
header are also updated accordingly.
This adds 'Innovative Computing Labs' as an external author to
update-copyright.py, to cover the copyright notice in
gprofng/common/opteron_pcbe.c, and uses that plus another external
author 'Oracle and' to update gprofng copyright dates. I'm not going
to commit 'Oracle and' as an accepted author, but that covers the
string "Copyright (c) 2006, 2012, Oracle and/or its affiliates. All
rights reserved." found in gprofng/testsuite/gprofng.display/jsynprog
files.
The newer update-copyright.py fixes file encoding too, removing cr/lf
on binutils/bfdtest2.c and ld/testsuite/ld-cygwin/exe-export.exp, and
embedded cr in binutils/testsuite/binutils-all/ar.exp string match.
This picks up some improvements from gcc/contrib. exceptions must
derive from BaseException, port to python3, retain original file mode,
fix name of script in examples.
Adds libsframe to list of default dirs. I would have added gprofng
too but there are some files claiming copyright by authors other than
the Free Software Foundation.
There's a command "disable probes", but SystemTap probes, for instance
libc:longjmp cannot be disabled:
...
$ gdb -q -batch a.out -ex start -ex "disable probes libc ^longjmp$"
...
Probe libc:longjmp cannot be disabled.
Probe libc:longjmp cannot be disabled.
Probe libc:longjmp cannot be disabled.
...
Add a command "maintenance ignore-probes" that ignores probes during
get_probes, such that we can easily pretend to use a libc without the
libc:longjmp probe:
...
(gdb) maint ignore-probes -verbose libc ^longjmp$
ignore-probes filter has been set to:
PROVIDER: 'libc'
PROBE_NAME: '^longjmp$'
OBJNAME: ''
(gdb) start ^M
...
Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
...
The "Ignoring ..." messages can be suppressed by not using -verbose.
Note that as with "disable probes", running simply "maint ignore-probes"
ignores all probes.
The ignore-probes filter can be reset by using:
...
(gdb) maint ignore-probes -reset
ignore-probes filter has been reset
...
For now, the command is only supported for SystemTap probes.
PR cli/27159
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27159
A few fixes to minor issues I've discovered in my PDB patches.
* If sizes or offsets are greater than 0x8000, they get encoded as
extended values in the same way as for enum values - e.g. a LF_ULONG
.short followed by a .long.
* I've managed to coax MSVC to produce another type, LF_VFTABLE, which
is seen when dealing with COM. I don't think LLVM emits this. Note that
we can't just implement everything in Microsoft's header files, as most
of it is obsolete.
* Fixes a stupid bug in the test program, where I was adding an index to
a size. The index was hard-coded to 0, so this didn't cause any actual
issues.
[ Partial resubmission of an earlier submission by Andrew (
https://sourceware.org/pipermail/gdb-patches/2012-September/096347.html ), so
listing him as co-author. ]
With x86_64-linux and target board unix/-m32, we have:
...
(gdb) continue^M
Continuing.^M
Exception #10^M
^M
Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M
23 throw new int (e);^M
(gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \
check FinishBreakpoint in catch()
...
The following scenario happens:
- set breakpoint in throw_exception_1, a function that throws an exception
- continue
- hit breakpoint, with call stack main.c:38 -> throw_exception_1
- set a finish breakpoint
- continue
- hit the breakpoint again, with call stack main.c:48 -> throw_exception
-> throw_exception_1
Due to the exception, the function call did not properly terminate, and the
finish breakpoint didn't trigger. This is expected behaviour.
However, the intention is that gdb detects this situation at the next stop
and calls the out_of_scope callback, which would result here in this test-case
in a rather confusing "exception did not finish" message. So the problem is
that this message doesn't show up, in other words, the out_of_scope callback
is not called.
[ Note that the fact that the situation is detected only at the next stop
(wherever that happens to be) could be improved upon, and the earlier
submission did that by setting a longjmp breakpoint. But I'm considering this
problem out-of-scope for this patch. ]
Note that the message does show up later, at thread exit:
...
[Inferior 1 (process 20046) exited with code 0236]^M
exception did not finish ...^M
...
The decision on whether to call the out_of_scope call back is taken in
bpfinishpy_detect_out_scope_cb, and the interesting bit is here:
...
if (b->pspace == current_inferior ()->pspace
&& (!target_has_registers ()
|| frame_find_by_id (b->frame_id) == NULL))
bpfinishpy_out_of_scope (finish_bp);
...
In the case of the thread exit, the callback triggers because
target_has_registers () == 0.
So why doesn't the callback trigger in the case of the breakpoint?
Well, the b->frame_id is the frame_id of the frame of main (the frame
in which the finish breakpoint is supposed to trigger), so AFAIU
frame_find_by_id (b->frame_id) == NULL will only be true once we've
left main, at which point I guess we don't stop till thread exit.
Fix this by saving the frame in which the finish breakpoint was created, and
using frame_find_by_id () == NULL on that frame instead, such that we have:
...
(gdb) continue^M
Continuing.^M
Exception #10^M
^M
Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M
23 throw new int (e);^M
exception did not finish ...^M
(gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \
check FinishBreakpoint in catch()
...
Still, the test-case is failing because it's setup to match the behaviour that
we get on x86_64-linux with target board unix/-m64:
...
(gdb) continue^M
Continuing.^M
Exception #10^M
stopped at ExceptionFinishBreakpoint^M
(gdb) PASS: gdb.python/py-finish-breakpoint2.exp: \
check FinishBreakpoint in catch()
...
So what happens here? Again, due to the exception, the function call did not
properly terminate, but the finish breakpoint still triggers. This is somewhat
unexpected. This happens because it just so happens to be that the frame
return address at which the breakpoint is set, is also the first instruction
after the exception has been handled. This is a know problem, filed as
PR29909, so KFAIL it, and modify the test-case to expect the out_of_scope
callback.
Also add a breakpoint after setting the finish breakpoint but before throwing
the exception, to check that we don't call the out_of_scope callback too early.
Tested on x86_64-linux, with target boards unix/-m32.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
PR python/27247
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27247
On ubuntu 22.04.1 x86_64, I run into:
...
(gdb) PASS: gdb.base/print-symbol-loading.exp: shlib off: \
set print symbol-loading off
sharedlibrary .*^M
Symbols already loaded for /lib/x86_64-linux-gnu/libc.so.6^M
Symbols already loaded for /lib/x86_64-linux-gnu/libpthread.so.0^M
(gdb) FAIL: gdb.base/print-symbol-loading.exp: shlib off: load shared-lib
...
The test-case expects the libc.so line, but not the libpthread.so line.
However, we have:
...
$ ldd /lib/x86_64-linux-gnu/libc.so.6
linux-vdso.so.1 (0x00007ffd7f7e7000)
libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (0x00007f4468c00000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4469193000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4468f3e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4468f39000)
...
so it's not unexpected that libpthread.so is loaded if libc.so is loaded.
Fix this by accepting the libpthread.so line.
Tested on x86_64-linux.
PR testsuite/29919
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29919
On Ubuntu 22.04.1 x86_64, with glibc 2.35 I run into:
...
watchpoint-fork-mt.c: In function 'start':^M
watchpoint-fork-mt.c:67:7: warning: 'pthread_yield' is deprecated: \
pthread_yield is deprecated, use sched_yield instead \
[-Wdeprecated-declarations]^M
67 | i = pthread_yield ();^M
| ^^M
...
Fix this as suggested, by using sched_yield instead.
Tested on x86_64-linux.
On Ubuntu 22.04.1 x86_64 (with glibc 2.35), I run into:
...
(gdb) PASS: gdb.base/corefile.exp: $_exitcode is void
bt^M
#0 __pthread_kill_implementation (...) at ./nptl/pthread_kill.c:44^M
#1 __pthread_kill_internal (...) at ./nptl/pthread_kill.c:78^M
#2 __GI___pthread_kill (...) at ./nptl/pthread_kill.c:89^M
#3 0x00007f4985e1a476 in __GI_raise (...) at ../sysdeps/posix/raise.c:26^M
#4 0x00007f4985e007f3 in __GI_abort () at ./stdlib/abort.c:79^M
#5 0x0000556b4ea4b504 in func2 () at gdb.base/coremaker.c:153^M
#6 0x0000556b4ea4b516 in func1 () at gdb.base/coremaker.c:159^M
#7 0x0000556b4ea4b578 in main (...) at gdb.base/coremaker.c:171^M
(gdb) PASS: gdb.base/corefile.exp: backtrace
up^M
#1 __pthread_kill_internal (...) at ./nptl/pthread_kill.c:78^M
78 in ./nptl/pthread_kill.c^M
(gdb) FAIL: gdb.base/corefile.exp: up
...
The problem is that the regexp used here:
...
gdb_test "up" "#\[0-9\]* *\[0-9xa-fH'\]* in .* \\(.*\\).*" "up"
...
does not fit the __pthread_kill_internal line which lacks the instruction
address due to inlining.
Fix this by making the regexp less strict.
Tested on x86_64-linux.
On ubuntu 22.04.1 x86_64, I run into:
...
(gdb) info probes all rtld rtld_map_complete^M
No probes matched.^M
(gdb) XFAIL: gdb.threads/dlopen-libpthread.exp: info probes all rtld rtld_map_complete
UNTESTED: gdb.threads/dlopen-libpthread.exp: no matching probes
...
This has been filed as PR testsuite/17016.
The problem is that the name rtld_map_complete is used, which was only
available in Fedora 17, and upstream the name map_complete was used.
In the email thread discussing a proposed patch (
https://sourceware.org/legacy-ml/gdb-patches/2014-09/msg00712.html ) it was
suggested to make the test-case handle both names.
So, handle both names: map_complete and rtld_map_complete.
This exposes the following FAIL:
...
(gdb) info sharedlibrary^M
From To Syms Read Shared Object Library^M
$hex $hex Yes /lib64/ld-linux-x86-64.so.2^M
$hex $hex Yes (*) /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0^M
$hex $hex Yes /lib/x86_64-linux-gnu/libc.so.6^M
$hex $hex Yes /lib/x86_64-linux-gnu/libdl.so.2^M
$hex $hex Yes /lib/x86_64-linux-gnu/libpthread.so.0^M
(*): Shared library is missing debugging information.^M
(gdb) FAIL: gdb.threads/dlopen-libpthread.exp: libpthread.so not found
...
due to using a glibc (v2.35) that has libpthread integrated into libc.
Fix this by changing the FAIL into UNSUPPORTED.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17016
On Ubuntu 22.04.1 x86_64, I run into:
...
gdb.reverse/step-indirect-call-thunk.c: In function 'inc':^M
gdb.reverse/step-indirect-call-thunk.c:22:1: error: '-mindirect-branch' and \
'-fcf-protection' are not compatible^M
22 | { /* inc.1 */^M
| ^^M
...
Fix this by forcing -fcf-protection=none, if supported.
Tested on x86_64-linux.
On Ubuntu 22.04.1 x86_64, I run into:
...
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: not in inline 1
next^M
51 if (t != NULL^M
(gdb) FAIL: gdb.cp/step-and-next-inline.exp: no_header: next step 1
...
This is due to -fcf-protection, which adds the endbr64 at the start of get_alias_set:
...
0000000000001180 <_Z13get_alias_setP4tree>:
1180: f3 0f 1e fa endbr64
1184: 48 85 ff test %rdi,%rdi
...
so the extra insn gets an is-stmt line number entry:
...
INDEX LINE ADDRESS IS-STMT PROLOGUE-END
...
11 50 0x0000000000001180 Y
12 50 0x0000000000001180
13 51 0x0000000000001184 Y
14 54 0x0000000000001184
...
and when stepping into get_alias_set we step to line 50:
...
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: in main
step^M
get_alias_set (t=t@entry=0x555555558018 <xx>) at step-and-next-inline.cc:50^M
50 {^M
...
In contrast, with -fcf-protection=none, we get:
...
0000000000001170 <_Z13get_alias_setP4tree>:
1170: 48 85 ff test %rdi,%rdi
...
and:
...
INDEX LINE ADDRESS IS-STMT PROLOGUE-END
...
11 50 0x0000000000001170 Y
12 51 0x0000000000001170 Y
13 54 0x0000000000001170
...
so when stepping into get_alias_set we step to line 51:
...
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: in main
step^M
get_alias_set (t=t@entry=0x555555558018 <xx>) at step-and-next-inline.cc:51^M
51 if (t != NULL^M
...
Fix this by rewriting the gdb_test issuing the step command to check which
line the step lands on, and issuing an extra next if needed.
Tested on x86_64-linux, both with and without -fcf-protection=none.
PR testsuite/29920
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29920
Make comp_unit_head.length private, to enforce using accessor functions.
Replace accessor function get_length with get_length_with_initial and
get_length_without_initial, to make it explicit which variant we're using.
Tested on x86_64-linux.
PR symtab/29343
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29343
This fixes a couple of places in display_debug_lines_decoded that were
off by one in checking DWARF5 .debug_line directory indices. It also
displays the DWARF5 entry 0 for the program current directory rather
than "." as is done for pre-DWARF5. I decided against displaying
DW_AT_comp_dir for pre-DWARF5 since I figure it is better for readelf
to minimally interpret debug info.
binutils/
PR 29948
* dwarf.c (display_debug_lines_decoded): Display the given
directory entry 0 for DWARF5. Properly check directory index
against number of entries in the table. Revert to using
unsigned int for n_directories and associated variables.
Correct warning messages.
gas/
* testsuite/gas/elf/dwarf-5-loc0.d: Update.
