aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2023-01-03Use value_at_non_lval in get_call_return_valueTom Tromey1-6/+1
get_call_return_value can handle RETURN_VALUE_STRUCT_CONVENTION, because the call is completely managed by gdb. However, it does not handle variably-sized types correctly. The simplest way to fix this is to use value_at_non_lval, which does type resolution.
2023-01-03Fix inferior calls with variably-sized return typeTom Tromey7-89/+91
This patch updates the gdbarch_return_value_as_value implementations to work correctly with variably-sized return types.
2023-01-03Convert selected architectures to gdbarch_return_value_as_valueTom Tromey9-20/+81
This converts a few selected architectures to use gdbarch_return_value_as_value rather than gdbarch_return_value. The architectures are just the ones that I am able to test. This patch should not introduce any behavior changes.
2023-01-03Don't let property evaluation affect the current languageTom Tromey1-0/+5
On PPC, we saw that calling an inferior function could sometimes change the current language, because gdb would select the call dummy frame -- associated with _start. This patch changes gdb so that the current language is never affected by DWARF property evaluation.
2023-01-03Introduce value_at_non_lvalTom Tromey2-0/+14
In some cases, while a value might be read from memory, gdb should not record the value as being equivalent to that memory. In Ada, the inferior call code will call ada_convert_actual -- and here, if the argument is already in memory, that address will simply be reused. However, for a call like "f(g())", the result of "g" might be on the stack and thus overwritten by the call to "f". This patch introduces a new function that is like value_at but that ensures that the result is non-lvalue.
2023-01-03Don't emit gdbarch_return_valueTom Tromey5-62/+61
The previous patch introduced a new overload of gdbarch_return_value. The intent here is that this new overload always be called by the core of gdb -- the previous implementation is effectively deprecated, because a call to the old-style method will not work with any converted architectures (whereas calling the new-style method is will delegate when needed). This patch changes gdbarch.py so that the old gdbarch_return_value wrapper function can be omitted. This will prevent any errors from creeping in.
2023-01-03Add new overload of gdbarch_return_valueTom Tromey10-35/+121
The gdbarch "return_value" can't correctly handle variably-sized types. The problem here is that the TYPE_LENGTH of such a type is 0, until the type is resolved, which requires reading memory. However, gdbarch_return_value only accepts a buffer as an out parameter. Fixing this requires letting the implementation of the gdbarch method resolve the type and return a value -- that is, both the contents and the new type. After an attempt at this, I realized I wouldn't be able to correctly update all implementations (there are ~80) of this method. So, instead, this patch adds a new method that falls back to the current method, and it updates gdb to only call the new method. This way it's possible to incrementally convert the architectures that I am able to test.
2023-01-03Fix crash in amd64-tdep.cTom Tromey1-1/+2
amd64-tdep.c could crash when 'finish'ing from a function whose return type had variable length. In this situation, the value will be passed by reference, and this patch avoids the crash. (Note that this does not fully fix the bug reported, but it does fix the crash, so it seems worthwhile to land independently.)
2023-01-03[gdb/testsuite] Add xfail in gdb.arch/i386-pkru.expTom de Vries2-4/+88
On a x86_64-linux machine with pkru register, I run into: ... (gdb) PASS: gdb.arch/i386-pkru.exp: set pkru value info register pkru^M pkru 0x12345678 305419896^M (gdb) FAIL: gdb.arch/i386-pkru.exp: read value after setting value ... This is a regression due to kernel commit e84ba47e313d ("x86/fpu: Hook up PKRU onto ptrace()"). This is fixed by recent kernel commit 4a804c4f8356 ("x86/fpu: Allow PKRU to be (once again) written by ptrace."). The regression occurs for kernel versions v5.14-rc1 (the first tag containing the regression) up to but excluding v6.2-rc1 (the first tag containing the fix). Fix this by adding an xfail for the appropriate kernel versions. Tested on x86_64-linux. PR testsuite/29790 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29790
2023-01-03Do not use PyObject_CallNoArgsTom Tromey1-2/+2
PyObject_CallNoArgs was introduced in Python 3.9, so avoid it in favor of PyObject_CallObject.
2023-01-03[gdb] Fix segfault during inferior call to ifuncAndrew Burgess2-2/+10
With a simple test-case: ... $ cat test.c char *p = "a"; int main (void) { return strlen (p); } $ gcc -g test.c ... we run into this segfault: ... $ gdb -q -batch a.out -ex start -ex "p strlen (p)" Temporary breakpoint 1 at 0x1151: file test.c, line 4. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Temporary breakpoint 1, main () at test.c:4 4 return strlen (p); Fatal signal: Segmentation fault ... The strlen is an ifunc, and consequently during the call to call_function_by_hand_dummy for "p strlen (p)" another call to call_function_by_hand_dummy is used to resolve the ifunc. This invalidates the get_current_frame () result in the outer call. Fix this by using prepare_reinflate and reinflate. Note that this series ( https://inbox.sourceware.org/gdb-patches/20221214033441.499512-1-simon.marchi@polymtl.ca/ ) should address this problem, but this patch is a simpler fix which is easy to backport. Tested on x86_64-linux. Co-Authored-By: Tom de Vries <tdevries@suse.de> PR gdb/29941 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29941
2023-01-02Simplify debug_expTom Tromey1-1/+1
debug_exp should call expression::dump rather than using the 'op' member.
2023-01-02Initial implementation of Debugger Adapter ProtocolTom Tromey26-2/+2297
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.
2023-01-02Fix target remote pipe command for MinGWJonas Hoerberg1-0/+6
The cced7cacecad104fff0 ("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.
2023-01-02Remove target: prefix from gdb_sysroot in find_separate_debug_fileTom Tromey1-12/+25
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
2023-01-02[gdb/testsuite] Fix gdb.python/py-breakpoint.exp with libstdc++ debug infoTom de Vries1-1/+2
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
2023-01-01manual copyright year range of various GDB files to add 2023Joel Brobecker3-5/+5
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.
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker6079-6079/+6079
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.
2023-01-01gdb/copyright.py: Adjust following rename of sim/ppc/ppc-instructions...Joel Brobecker1-1/+1
... 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.
2023-01-01Update copyright year in help message of gdb, gdbserver, gdbreplayJoel Brobecker1-2/+2
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.
2022-12-31[gdb/cli] Add maintenance ignore-probesTom de Vries4-0/+145
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
2022-12-31[gdb/python] Fix gdb.python/py-finish-breakpoint2.exp for -m32Tom de Vries3-6/+55
[ 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
2022-12-31[gdb/testsuite] Fix gdb.base/print-symbol-loading.exp on ubuntu 22.04.1Tom de Vries1-1/+5
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
2022-12-31[gdb/testsuite] Replace deprecated pthread_yield in ↵Tom de Vries1-5/+5
gdb.threads/watchpoint-fork.exp 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.
2022-12-31[gdb/testsuite] Fix gdb.base/corefile.exp with glibc 2.35Tom de Vries1-2/+2
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.
2022-12-30[gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibcTom de Vries1-10/+25
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
2022-12-30[gdb/testsuite] Fix gdb.reverse/step-indirect-call-thunk.exp with ↵Tom de Vries1-3/+12
-fcf-protection 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.
2022-12-30[gdb/testsuite] Fix gdb.cp/step-and-next-inline.exp with -fcf-protectionTom de Vries1-1/+10
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
2022-12-30[gdb/symtab] Make comp_unit_head.length privateTom de Vries3-18/+33
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
2022-12-28Use $decimal in timestamp.expTom Tromey1-1/+1
This patch fixes a review comment by Tom de Vries. He pointed out that the new timestamp.exp should use the $decimal convenience regexp.
2022-12-28Fix "set debug timestamp"Tom Tromey2-1/+25
PR cli/29945 points out that "set debug timestamp 1" stopped working -- this is a regression due to commit b8043d27 ("Remove a ui-related memory leak"). This patch fixes the bug and adds a regression test. I think this should probably be backported to the gdb 13 branch. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29945
2022-12-27Handle SIGSEGV in gdb selftestsTom Tromey2-0/+12
The gdb.gdb self-tests were timing out for me, which turned out to be PR testsuite/29325. Looking into it, the problem is that the version of the Boehm GC that is used by Guile on my machine causes a SEGV during stack probing. This unexpected stop confuses the tests and causes repeated timeouts. This patch adapts the two failing tests. This makes them work for me, and reduces the running time of gdb.gdb from 20 minutes to about 11 seconds. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29325
2022-12-26Add initializers to comp_unit_headTom Tromey4-16/+14
PR symtab/29343 points out that it would be beneficial if comp_unit_head had a constructor and used initializers. This patch implements this. I'm unsure if this is sufficient to close the bug, but at least it's a step. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29343
2022-12-24gdb/testsuite: fix buffer overflow in gdb.base/signed-builtin-types.expAndrew Burgess1-43/+8
In commit: commit 9f50fe0835850645bd8ea9bb1efe1fe6c48dfb12 Date: Wed Dec 7 15:55:25 2022 +0000 gdb/testsuite: new test for recent dwarf reader issue A new test (gdb.base/signed-builtin-types.exp) was added that made use of 'info sources' to figure out if the debug information for a particular object file had been fully expanded or not. Unfortunately some lines of the 'info sources' output can be very long, this was observed on some systems where the debug information for the dynamic-linker was installed, in this case, the list of source files associated with the dynamic linker was so long it would cause expect's internal buffer to overflow. This commit switches from using 'info sources' to 'maint print objfile', the output from the latter command is more compact, but also, can be restricted to a single named object file. With this change in place I am no longer seeing buffer overflow errors from expect when running gdb.base/signed-builtin-types.exp.
2022-12-23Use bool for dwarf2_has_infoTom Tromey2-5/+5
This changes dwarf2_has_info to return bool.
2022-12-23gdb/testsuite: remove MPFR detection in gdb.base/float128.expSimon Marchi1-36/+1
I see this fail since commit 991180627851 ("Use toplevel configure for GMP and MPFR for gdb"): FAIL: gdb.base/float128.exp: show configuration The test fails to find --with-mpfr or --without-mpfr in the "show configuration" output. Since MPFR has become mandatory, we can just remove that check and simplify the test to assume MPFR support is there. Change-Id: I4f3458470db0029705b390dfefed3a66dfc0633a Approved-By: Tom de Vries <tdevries@suse.de>
2022-12-23Fix MinGW build using mingw.org's MinGWEli Zaretskii1-1/+5
This allows to build GDB even though the default value of _WIN32_WINNT is lower than the one needed to expose some new APIs used here, and leave the test for their actual support to run time. * gdb/nat/windows-nat.c (EXTENDED_STARTUPINFO_PRESENT): Define if not defined. (create_process_wrapper): Use 'gdb_lpproc_thread_attribute_list' instead of 'PPROC_THREAD_ATTRIBUTE_LIST' (which might not be defined at compile time). This fixes compilation error using mingw.org's MinGW.
2022-12-21Fix compiling of top.cAndrew Pinski1-1/+0
When I moved my last patch forward, somehow I missed removing the #endif for the HAVE_LIBMPFR case. Committed as obvious after a quick build. gdb/ChangeLog: * top.c: Remove the extra #endif which was missed.
2022-12-21Use toplevel configure for GMP and MPFR for gdbAndrew Pinski8-1079/+41
This patch uses the toplevel configure parts for GMP/MPFR for gdb. The only thing is that gdb now requires MPFR for building. Before it was a recommended but not required library. Also this allows building of GMP and MPFR with the toplevel directory just like how it is done for GCC. We now error out in the toplevel configure of the version of GMP and MPFR that is wrong. OK after GDB 13 branches? Build gdb 3 ways: with GMP and MPFR in the toplevel (static library used at that point for both) With only MPFR in the toplevel (GMP distro library used and MPFR built from source) With neither GMP and MPFR in the toplevel (distro libraries used) Changes from v1: * Updated gdb/README and gdb/doc/gdb.texinfo. * Regenerated using unmodified autoconf-2.69 Thanks, Andrew Pinski ChangeLog: * Makefile.def: Add configure-gdb dependencies on all-gmp and all-mpfr. * configure.ac: Split out MPC checking from MPFR. Require GMP and MPFR if the gdb directory exist. * Makefile.in: Regenerate. * configure: Regenerate. gdb/ChangeLog: PR bug/28500 * configure.ac: Remove AC_LIB_HAVE_LINKFLAGS for gmp and mpfr. Use GMPLIBS and GMPINC which is provided by the toplevel configure. * Makefile.in (LIBGMP, LIBMPFR): Remove. (GMPLIBS, GMPINC): Add definition. (INTERNAL_CFLAGS_BASE): Add GMPINC. (CLIBS): Exchange LIBMPFR and LIBGMP for GMPLIBS. * target-float.c: Make the code conditional on HAVE_LIBMPFR unconditional. * top.c: Remove code checking HAVE_LIBMPFR. * configure: Regenerate. * config.in: Regenerate. * README: Update GMP/MPFR section of the config options. * doc/gdb.texinfo: Likewise. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28500
2022-12-21gdb/c++: validate 'using' directives based on the current lineBruno Larsen6-9/+95
When asking GDB to print a variable from an imported namespace, we only want to see variables imported in lines that the inferior has already gone through, as is being tested last in gdb.cp/nsusing.exp. However with the proposed change to gdb.cp/nsusing.exp, we get the following failures: (gdb) PASS: gdb.cp/nsusing.exp: continue to breakpoint: marker10 stop print x $9 = 911 (gdb) FAIL: gdb.cp/nsusing.exp: print x, before using statement next 15 y += x; (gdb) PASS: gdb.cp/nsusing.exp: using namespace M print x $10 = 911 (gdb) PASS: gdb.cp/nsusing.exp: print x, only using M Showing that the feature wasn't functioning properly, it just so happened that gcc ordered the namespaces in a convenient way. This happens because GDB doesn't take into account the line where the "using namespace" directive is written. So long as it shows up in the current scope, we assume it is valid. To fix this, add a new member to struct using_direct, that stores the line where the directive was written, and a new function that informs if the using directive is valid already. Unfortunately, due to a GCC bug, the failure still shows up. Compilers that set the declaration line of the using directive correctly (such as Clang) do not show such a bug, so the test includes an XFAIL for gcc code. Finally, because the final test of gdb.cp/nsusing.exp has turned into multiple that all would need XFAILs for older GCCs (<= 4.3), and that GCC is very old, if it is detected, the test just exits early. Approved-by: Tom Tromey <tom@tromey.com>
2022-12-20sim: move register headers into sim/ namespace [PR sim/29869]Mike Frysinger8-8/+8
These headers define the register numbers for each port to implement the sim_fetch_register & sim_store_register interfaces. While gdb uses these, the APIs are part of the sim, not gdb. Move the headers out of the gdb/ include namespace and into sim/ instead.
2022-12-20Fix install-strip targetHannes Domani1-2/+2
The libtool patch broke install-strip of gdb: /bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/share/gdb/python/gdb transformed_name=`t='s,y,y,'; \ echo gdb | sed -e "$t"` ; \ if test "x$transformed_name" = x; then \ transformed_name=gdb ; \ else \ true ; \ fi ; \ /bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/bin ; \ /bin/sh ./libtool --mode=install STRIPPROG='strip' /bin/sh /src/gdb/gdb.git/install-sh -c -s \ gdb \ /src/gdb/inst/bin/$transformed_name ; \ /bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/include/gdb ; \ /usr/bin/install -c -m 644 jit-reader.h /src/gdb/inst/include/gdb/jit-reader.h libtool: install: `/src/gdb/inst/bin/gdb' is not a directory libtool: install: Try `libtool --help --mode=install' for more information. Since INSTALL_PROGRAM_ENV is no longer at the beginning of the command, the gdb executable is not installed with install-strip.
2022-12-19Use bool in bpstatTom Tromey6-30/+31
This changes bpstat to use 'bool' rather than 'char', and updates the uses.
2022-12-19Use bool constants for value_print_optionsTom Tromey19-60/+60
This changes the uses of value_print_options to use 'true' and 'false' rather than integers.
2022-12-19Remove quick_symbol_functions::relocatedTom Tromey4-91/+4
quick_symbol_functions::relocated is only needed for psymtabs, and there it is only needed for Rust. However, because we've switched the DWARF reader away from psymtabs, this means there's no longer a need for this method at all.
2022-12-19Remove MI version 1Tom Tromey11-126/+11
MI version 1 is long since obsolete. Several years ago, I filed PR mi/23170 for this. I think it's finally time to remove this. Any users of MI 1 can and should upgrade to a newer version. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23170
2022-12-19Remove vestiges of MI version 0Tom Tromey1-27/+0
I found a few vestiges of MI version 0 in the test suite. This patch removes them.
2022-12-19gdb: fix command lookup in execute_command ()Jan Vrany1-6/+2
Commit b5661ff2 ("gdb: fix possible use-after-free when executing commands") used lookup_cmd_exact () to lookup command again after its execution to avoid possible use-after-free error. However this change broke test gdb.base/define.exp which defines a post-hook for subcommand ("target testsuite"). In this case, lookup_cmd_exact () returned NULL because there's no command 'testsuite' in top-level commands. This commit fixes this case by looking up the command again using the original command line via lookup_cmd (). Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-12-18Update gdb/NEWS after GDB 13 branch creation.Joel Brobecker1-1/+3
This commit a new section for the next release branch, and renames the section of the current branch, now that it has been cut.
2022-12-18Bump version to 14.0.50.DATE-git.Joel Brobecker2-2/+2
Now that the GDB 13 branch has been created, this commit bumps the version number in gdb/version.in to 14.0.50.DATE-git For the record, the GDB 13 branch was created from commit 71c90666e601c511a5f495827ca9ba545e4cb463. Also, as a result of the version bump, the following changes have been made in gdb/testsuite: * gdb.base/default.exp: Change $_gdb_major to 14.
generated by cgit v1.1 at 2025-09-20 13:09:39 +0000