aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2023-01-06gdb/mi: add no-history stop reasonBruno Larsen6-2/+14
When executing in reverse and runs out of recorded history, GDB prints a warning to the user, but does not add a reason in the stopped record, for example: *stopped,frame={addr="0x000000000040113e",func="main",args=[],file="/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.reverse/solib-reverse.c",fullname="/home/blarsen/Documents/binutils-gdb/gdb/testsuite/gdb.reverse/solib-reverse.c",line="27",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="1" This problem was reported as record/29260. This commit adds the reason no-history to the record, making it easier for interfaces using the mi interpreter to report the result. It also changes the test gdb.mi/mi-reverse.exp to test that the reason shows up correctly. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29260
2023-01-06gdb/testsuite: Fix FAILs in gdb.linespec/cpcompletion.exp when using clangBruno Larsen1-15/+18
When using clang 16.0.0 to test gdb.linespec/cpcompletion.exp, I get 99 unexpected failures. They all fail to produce a complete list of completion options for a function, either overload2_function, overload3_function or anon_ns_function. This happens because clang is optimizing them away, since they are never used. Fix this by adding __attribute__((used)) to all declarations to the aforementioned functions.
2023-01-05gdbsupport: add gdb::string_view_hashSimon Marchi1-1/+1
Add the string_view_hash type, which will be useful to be able to use gdb::string_view as std::unordered_map keys. Use it in gdb/symtab.c, to exercise it. Change-Id: Id69a466ab19a9f6620b5df8a2dd29b5cddd94c00 Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-01-05gdbsupport: move fast_hash to gdbsupport/common-utils.hSimon Marchi1-19/+0
The following patch adds a hash type for gdb::string_view in gdbsupport, which will use the fast_hash function. Move the latter to gdbsupport. Change-Id: Id74510e17801e775bd5ffa5f443713d79adf14ad Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-01-05gdbsupport: move libxxhash configure check to gdbsupportSimon Marchi2-537/+514
The following patch moves the fast_hash function, which uses libxxhash, to gdbsupport. Move the libxxhash configure check to gdbsupport (and transitively to gdbserver). Change-Id: I242499e50c8cd6fe9f51e6e92dc53a1b3daaa96e Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-01-05gdb: make gdbarch_alloc take ownership of the tdepSimon Marchi46-149/+148
It's currently not clear how the ownership of gdbarch_tdep objects works. In fact, nothing ever takes ownership of it. This is mostly fine because we never free gdbarch objects, and thus we never free gdbarch_tdep objects. There is an exception to that however: when initialization fails, we do free the gdbarch object that is not going to be used, and we free the tdep too. Currently, i386 and s390 do it. To make things clearer, change gdbarch_alloc so that it takes ownership of the tdep. The tdep is thus automatically freed if the gdbarch is freed. Change all gdbarch initialization functions to pass a new gdbarch_tdep object to gdbarch_alloc and then retrieve a non-owning reference from the gdbarch object. Before this patch, the xtensa architecture had a single global instance of xtensa_gdbarch_tdep. Since we need to pass a dynamically allocated gdbarch_tdep_base instance to gdbarch_alloc, remove this global instance, and dynamically allocate one as needed, like we do for all other architectures. Make the `rmap` array externally visible and rename it to the less collision-prone `xtensa_rmap` name. Change-Id: Id3d70493ef80ce4bdff701c57636f4c79ed8aea2 Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-01-05gdb/testsuite: add back needed -re clause in gdb_breakpointSimon Marchi1-0/+6
Commit 4b9728be ("gdb: use gdb_test_multiple in gdb_breakpoint") caused, amongst others: (gdb) break 1^M No line 1 in the current file.^M Make breakpoint pending on future shared library load? (y or [n]) n^M (gdb) FAIL: gdb.dwarf2/dw2-main-no-line-number.exp: gdb_breakpoint: set breakpoint at 1 FAIL: gdb.dwarf2/dw2-main-no-line-number.exp: !$breakpoint_at_missing_lineno_set This is because it removed one empty -re clause (matching just the prompt) that is necessary after replying "n" to the pending breakpoint question. Add this clause back. Change-Id: Ibfaa059d58bbea660bc29f0547e2f75c323fcbc6 Approved-By: Tom de Vries <tdevries@suse.de>
2023-01-05[gdb/python] Avoid queue.SimpleQueue for python 3.6Tom de Vries2-2/+10
On openSUSE Leap 15.4 with python 3.6, the gdb.dap/basic-dap.exp test-case fails as follows: ... ERROR: eof reading json header while executing "error "eof reading json header"" invoked from within "expect { -i exp19 -timeout 10 -re "^Content-Length: (\[0-9\]+)\r\n" { set length $expect_out(1,string) exp_continue } -re "^(\[^\r\n\]+)..." ("uplevel" body line 1) invoked from within "uplevel $body" NONE eof reading json header UNRESOLVED: gdb.dap/basic-dap.exp: startup - initialize ... Investigation using a "catch throw" shows that: ... (gdb) at gdb/python/py-utils.c:396 396 error (_("Error occurred in Python: %s"), msg.get ()); (gdb) p msg.get () $1 = 0x2b91d10 "module 'queue' has no attribute 'SimpleQueue'" ... The python class queue.SimpleQueue was introduced in python 3.7. Fix this by falling back to queue.Queue for python <= 3.6. Tested on x86_64-linux, by successfully running the test-case: ... # of expected passes 47 ...
2023-01-05Add type to expression dump of symbolTom Tromey1-0/+1
I recently had cause to dump some expressions from gdb. I got output like this: Operation: BINOP_GTR Operation: OP_VAR_VALUE Block symbol: Symbol: small_value Block: 0x39b4c20 Operation: OP_LONG Operation: OP_LONG Type: int Constant: 0x0000000000000014 This is ok, but it would have been handy to see the type of the symbol. This patch adds this information. Reviewed-By: Bruno Larsen <blarsen@redhat.com>
2023-01-04gdb: ensure test_name is initialized in gdb_breakpointLancelot SIX1-1/+2
A refactoring in 4b9728bec15 (gdb: use gdb_test_multiple in gdb_breakpoint) left the $test_name variable undefined. This patch fixes this. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-04Use first_opcode in another spotTom Tromey1-1/+1
I found one place that could use expression::first_opcode. Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-01-04Convert exp_uses_objfile to a method of expressionTom Tromey6-17/+16
This changes the exp_uses_objfile function to be a method of 'expression'. Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-01-04gdb: use gdb_test_multiple in gdb_breakpointSimon Marchi1-34/+2
When running the testsuite in a non-optimized build on a slow machine, I sometimes get: UNTESTED: gdb.gdb/selftest.exp: Cannot set breakpoint at captured_main, skipping testcase. do_self_tests, in lib/selftest-support.exp, uses `with_timeout_factor 10`, to account for the fact that reading the debug info of the gdb binary (especially in a non-optimized GDB) can take time. But then it ends up calling gdb_breakpoint, which uses gdb_expect with a hard-coded timeout of 30 seconds. Fix this by making gdb_breakpoint use gdb_test_multiple, which is a desired change anyway for this kind of simple command / expected output case. Change-Id: I9b06ce991cc584810d8cc231b2b4893980b8be75 Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-01-04gdb: fix some #ifdef logic in bt-utils.hAndrew Burgess1-1/+1
In passing I spotted some incorrect #ifdef logic in bt-utils.h. The logic in question has existed since the file was originally added in commit: commit abbbd4a3e0ca51132e7fb31a43f896d29894dae0 Date: Wed Aug 11 13:24:33 2021 +0100 gdb: use libbacktrace to create a better backtrace for fatal signals The code is trying to select between using libbacktrace or using the execinfo supplied backtrace API. First we check to see if we can use libbacktrace. If we can then we include some header files, and then set some defines to indicate that libbacktrace is being used. Then we check if execinfo is available, if it is then we include <execinfo.h> and set some alternative defines. In theory the second block of logic should not trigger if the first block (that uses libbacktrace) has also triggered, but we incorrectly check the define 'PRINT_BACKTRACE_ON_FATAL_SIGNAL' instead of checking for 'GDB_PRINT_INTERNAL_BACKTRACE_USING_LIBBACKTRACE', so the second block triggers more than it should. The 'PRINT_BACKTRACE_ON_FATAL_SIGNAL' define is not defined anywhere, this was a mistake in the original commit. In reality this is harmless, we include <execinfo.h> when we don't need too, but in by-utils.c the libbacktrace define is always checked for before the execinfo define, so we never actually end up using the execinfo path (when libbacktrace is available). But I figure its still worth cleaning this up. I've tested GDB in a "default" build where libbacktrace is used, and when configuring with --disable-libbacktrace which causes the execinfo backtrace API to be used instead, both still appear to work fine. There should be no user visible changes after this commit.
2023-01-04gdb: add 'maintenance print record-instruction' commandBruno Larsen5-0/+211
While chasing some reverse debugging bugs, I found myself wondering what was recorded by GDB to undo and redo a certain instruction. This commit implements a simple way of printing that information. If there isn't enough history to print the desired instruction (such as when the user hasn't started recording yet or when they request 2 instructions back but only 1 was recorded), GDB warns the user like so: (gdb) maint print record-instruction Not enough recorded history If there is enough, GDB prints the instruction like so: (gdb) maint print record-instruction 4 bytes of memory at address 0x00007fffffffd5dc changed from: 01 00 00 00 Register eflags changed: [ IF ] Register rip changed: (void (*)()) 0x401115 <main+15> Approved-by: Eli Zaretskii <eliz@gnu.org> Reviewed-by: Alexandra Hajkova <ahajkova@redhat.com> Reviewed-by: Lancelot Six <lsix@lancelotsix.com> Approved-by: Tom Tromey <tom@tromey.com>
2023-01-03Add test case for "finish" with variably-sized typesTom Tromey5-2/+123
This adds a test case for "finish" with variably-sized types, and for inferior calls as well. This also extends the "runto" proc to handle temporary breakpoints.
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.
generated by cgit v1.1 at 2025-09-20 04:21:40 +0000