aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-11-14Remove some redundant "break"sTom Tromey1-4/+0
I found some "break" statements that follow "return" or a call to a noreturn function. These aren't needed, and the compiler would warn if they were. So, this patch removes them. Tested by rebuilding.
2023-11-14Filter invalid encodings from Linux thread namesTom Tromey2-2/+58
On Linux, a thread can only be 16 bytes (including the trailing \0). A user sent in a test case where this causes a truncated UTF-8 sequence, causing gdbserver to create invalid XML. I went back and forth about different ways to solve this, and in the end decided to fix it in gdbserver, with the reason being that it seems important to generate correct XML for the <thread> response. I am not totally sure whether the call to setlocale could have unplanned consequences. This is needed, though, for nl_langinfo to return the correct result. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30618
2023-11-14Update gdb.Symbol.is_variable documentationTom Tromey1-1/+3
Kévin found a bug in an earlier version of this series that was based on a misconception I had about Symbol.is_variable. This patch fixes the documentation to explain the method a bit better. Approved-By: Eli Zaretskii <eliz@gnu.org>
2023-11-14Handle the static link in FrameDecoratorTom Tromey3-13/+174
A co-worker requested that the DAP scope for a nested function's frame also show the variables from outer frames. DAP doesn't directly support this notion, so this patch arranges to put these variables into the inner frames "Locals" scope. I chose to do this only for DAP. For CLI and MI, gdb currently does not do this, so this preserves the behavior. Note that an earlier patch (see commit 4a1311ba) removed some code that seemed to do something similar. However, that code did not actually work.
2023-11-14Fix a bug in DAP scopes codeTom Tromey1-2/+6
While working on static links, I noticed that the DAP scopes code does not handle the scenario where a frame decorator returns None. This situation should be handled identically to a frame decorator returning an empty iterator.
2023-11-14Add gdb.Frame.static_link methodTom Tromey3-0/+39
This adds a new gdb.Frame.static_link method to the gdb Python layer. This can be used to find the static link frame for a given frame. Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2023-11-14Move follow_static_link to frame.cTom Tromey3-53/+53
This moves the follow_static_link function to frame.c and exports it for use elsewhere. The API is changed slightly to make it more generically useful.
2023-11-14Add block::function_blockTom Tromey2-0/+19
This adds the method block::function_block, to easily access a block's enclosing function block.
2023-11-14Add two convenience methods to blockTom Tromey2-3/+17
This adds a couple of convenience methods, block::is_static_block and block::is_global_block.
2023-11-14gdb/MAINTAINERS: add Guinevere Larsen as record-full maintainerSimon Marchi1-0/+1
Change-Id: I67d8361560ce0fa553b2983184c9d18df8dbeb4a
2023-11-14gdb/MAINTAINERS: add Luis Machado as global maintainerSimon Marchi1-1/+1
Change-Id: I211d64393f5c0da3c9ce1fcf5486504d34ed38f4
2023-11-14gdb/MAINTAINERS: add John Baldwin as global maintainerSimon Marchi1-1/+1
Change-Id: Ic9164fd19c3da1381302a17176e8f0f814e9ac6c
2023-11-14gdb: normalize whitespaces in MAINTAINERSSimon Marchi1-13/+13
Replace some spaces with tabs. Change-Id: I89bbabd6610219649e7e99cd0dd7b0ed66d69b09
2023-11-14[gdb/tui] Factor out tui_noscroll_window et alTom de Vries3-66/+93
I noticed that tui_locator_window has an empty do_scroll_vertical and do_scroll_horizontal, like tui_cmd_window, but unlike tui_cmd_window doesn't have: ... bool can_scroll () const override { return false; } ... I suspect that it probably doesn't matter, but regardless it's good to have the same implementations of basic properties in all windows. Ensure this by adding a class tui_noscroll_window, that has: - an empty do_scroll_vertical and do_scroll_horizontal, and - a can_scroll returning false which both tui_locator_window and tui_cmd_window inherit. Make all methods final to ensure no accidental overrides are left in the inheriting classes. Likewise add new classes representing basic window properties: - tui_nofocus_window, - tui_oneline_window, - tui_nobox_window, - tui_norefresh_window, and - tui_always_visible_window. The changes are only a refactoring, apart from adding the "final", which does limit the range of behaviours for subclasses. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2023-11-14gdb: refactor make-target-delegates.py's ARGTYPESTankut Baris Aktemur1-6/+7
Refactor the ARGTYPES regular expression in make-target-delegates.py to eliminate '.*' for better control on what is matched. Also, simplify the "E" match group, for which the optional SYMBOL becomes redundant because that case can be matched by the "T" group. After applying this patch, running './make-target-delegates.py' does not change anything in 'target-delegates.c'. Approved-By: Pedro Alves <pedro@palves.net>
2023-11-14gdb: regenerate target-delegates.cTankut Baris Aktemur1-2/+2
I ran './make-target-delegates.py' and there is one minor difference, where an older style declaration is converted to a newer initialization style. Add this change. Approved-By: Pedro Alves <pedro@palves.net>
2023-11-14[gdb/testsuite] Fix gdb.threads/stepi-over-clone.exp regexpTom de Vries1-5/+9
I ran into the following FAIL: ... (gdb) PASS: gdb.threads/stepi-over-clone.exp: catch process syscalls continue^M Continuing.^M ^M Catchpoint 2 (call to syscall clone), clone () at \ ../sysdeps/unix/sysv/linux/x86_64/clone.S:78^M warning: 78 ../sysdeps/unix/sysv/linux/x86_64/clone.S: \ No such file or directory^M (gdb) FAIL: gdb.threads/stepi-over-clone.exp: continue ... All but one regexps in the .exp file use "clone\[23\]?" with "?" to also accept "clone", except the failing case. This commit fixes that case to also use "?". Furthermore, there are FAILs like this: ... (gdb) PASS: gdb.threads/stepi-over-clone.exp: third_thread=false: \ non-stop=on: displaced=off: i=0: continue stepi^M [New Thread 0x7ffff7ff8700 (LWP 15301)]^M Hello from the first thread.^M 78 in ../sysdeps/unix/sysv/linux/x86_64/clone.S^M (gdb) XXX: Consume the initial command XXX: Consume new thread line XXX: Consume first worker thread message FAIL: gdb.threads/stepi-over-clone.exp: third_thread=false: non-stop=on: \ displaced=off: i=0: stepi ... because this output is expected instead: ... Hello from the first thread.^M 0x00000000004212cd in clone3 ()^M ... The root cause for the difference is the presence of .debug_line info for clone. Fix this by updating the relevant regexps. Tested on x86_64-linux, specifically: - openSUSE Leap 15.4 (where the FAILs where observed), and - openSUSE Tumbleweed (where the FAILs where not observed). Co-Authored-By: Pedro Alves <pedro@palves.net> Approved-By: Pedro Alves <pedro@palves.net> Change-Id: I74ca9e7d4cfe6af294fd50e8c509fcbad289b78c
2023-11-14gdb: implement missing debug handler hook for PythonAndrew Burgess11-1/+1352
This commit builds on the previous commit, and implements the extension_language_ops::handle_missing_debuginfo function for Python. This hook will give user supplied Python code a chance to help find missing debug information. The implementation of the new hook is pretty minimal within GDB's C++ code; most of the work is out-sourced to a Python implementation which is modelled heavily on how GDB's Python frame unwinders are implemented. The following new commands are added as commands implemented in Python, this is similar to how the Python unwinder commands are implemented: info missing-debug-handlers enable missing-debug-handler LOCUS HANDLER disable missing-debug-handler LOCUS HANDLER To make use of this extension hook a user will create missing debug information handler objects, and registers these handlers with GDB. When GDB encounters an objfile that is missing debug information, each handler is called in turn until one is able to help. Here is a minimal handler that does nothing useful: import gdb import gdb.missing_debug class MyFirstHandler(gdb.missing_debug.MissingDebugHandler): def __init__(self): super().__init__("my_first_handler") def __call__(self, objfile): # This handler does nothing useful. return None gdb.missing_debug.register_handler(None, MyFirstHandler()) Returning None from the __call__ method tells GDB that this handler was unable to find the missing debug information, and GDB should ask any other registered handlers. By extending the __call__ method it is possible for the Python extension to locate the debug information for objfile and return a value that tells GDB how to use the information that has been located. Possible return values from a handler: - None: This means the handler couldn't help. GDB will call other registered handlers to see if they can help instead. - False: The handler has done all it can, but the debug information for the objfile still couldn't be found. GDB will not call any other handlers, and will continue without the debug information for objfile. - True: The handler has installed the debug information into a location where GDB would normally expect to find it. GDB should look again for the debug information. - A string: The handler can return a filename, which is the file containing the missing debug information. GDB will load this file. When a handler returns True, GDB will look again for the debug information, but only using the standard built-in build-id and .gnu_debuglink based lookup strategies. It is not possible for an extension to trigger another debuginfod lookup; the assumption is that the debuginfod server is remote, and out of the control of extensions running within GDB. Handlers can be registered globally, or per program space. GDB checks the handlers for the current program space first, and then all of the global handles. The first handler that returns a value that is not None, has "handled" the objfile, at which point GDB continues. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
2023-11-14gdb: add an extension language hook for missing debug infoAndrew Burgess4-28/+166
This commit adds a new extension_language_ops hook which allows an extension to handle the case where GDB can't find a separate debug information file for a particular objfile. This commit doesn't actually implement the hook for any of GDB's extension languages, the next commit will do that. This commit just adds support for the hook to extension-priv.h and extension.[ch], and then reworks symfile-debug.c to call the hook. Right now the hook will always return its default value, which means GDB should do nothing different. As such, there should be no user visible changes after this commit. I'll give a brief description of what the hook does here so that we can understand the changes in symfile-debug.c. The next commit adds a Python implementation for this new hook, and gives a fuller description of the new functionality. Currently, when looking for separate debug information GDB tries three things, in this order: 1. Use the build-id to find the required debug information, 2. Check for .gnu_debuglink section and use that to look up the required debug information, 3. Check with debuginfod to see if it can supply the required information. The new extension_language_ops::handle_missing_debuginfo hook is called if all three steps fail to find any debug information. The hook has three possible return values: a. Nothing, no debug information is found, GDB continues without the debug information for this objfile. This matches the current behaviour of GDB, and is the default if nothing is implementing this new hook, b. Install debug information into a location that step #1 or #2 above would normally check, and then request that GDB repeats steps #1 and #2 in the hope that GDB will now find the debug information. If the debug information is still not found then GDB carries on without the debug information. If the debug information is found the GDB loads it and carries on, c. Return a filename for a file containing the required debug information. GDB loads the contents of this file and carries on. The changes in this commit mostly involve placing the core of objfile::find_and_add_separate_symbol_file into a loop which allows for steps #1 and #2 to be repeated. We take care to ensure that debuginfod is only queried once, the first time through. The assumption is that no extension is going to be able to control the replies from debuginfod, so there's no point making a second request -- and as these requests go over the network, they could potentially be slow. The warnings that find_and_add_separate_symbol_file collects are displayed only once assuming that no debug information is found. If debug information is found, even after the extension has operated, then the warnings are not shown; remember, these are warnings from GDB about failure to find any suitable debug information, so it makes sense to hide these if debug information is found. Approved-By: Tom Tromey <tom@tromey.com>
2023-11-14gdb: refactor objfile::find_and_add_separate_symbol_fileAndrew Burgess1-47/+88
This is purely a refactoring commit. This commit splits objfile::find_and_add_separate_symbol_file into some separate helper functions. My hope is that the steps for looking up separate debug information are now clearer. In a later commit I'm going to extend objfile::find_and_add_separate_symbol_file, with some additional logic, so starting with a simpler function will make the following changes easier. When reading objfile::find_and_add_separate_symbol_file after this commit, you might be tempted to think that removing the `has_dwarf` local variable would be a good additional cleanup. After the next commit though it makes more sense to retain this local, so I've left this in place for now. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2023-11-14gdb: merge debug symbol file lookup code from coffread & elfread pathsAndrew Burgess4-76/+81
This commit merges the code that looks for and loads the separate debug symbol files from coffread.c and elfread.c. The factored out code is moved into a new objfile::find_and_add_separate_symbol_file() method. For the elfread.c path there should be no user visible changes after this commit. For the coffread.c path GDB will now attempt to perform a debuginfod lookup for the missing debug information, assuming that GDB can find a build-id in the COFF file. I don't know if COFF files can include a build-id, but I the existing coffread.c code already includes a call to find_separate_debug_file_by_build-id, so I know that it is at least OK for GDB to ask a COFF file for a build-id. If the COFF file doesn't include a build-id then the debuginfod lookup code will not trigger and the new code is harmless. If the COFF file does include a build-id, then we're going to end up asking debuginfod for the debug file. As build-ids should be unique, this should be harmless, even if debuginfod doesn't contain any suitable debug data, it just costs us one debuginfod lookup, so I'm not too worried about this for now. As with the previous commit, I've done some minimal testing using the mingw toolchain on a Linux machine, GDB seems to still access the split debug information just fine. Approved-By: Tom Tromey <tom@tromey.com>
2023-11-14gdb/coffread: bring separate debug file logic into line with elfread.cAndrew Burgess1-1/+3
In this commit: commit 8a92335bfca80cc9b4cd217505ea0dcbfdefbf07 Date: Fri Feb 1 19:39:04 2013 +0000 the logic for when we try to load a separate debug file in elfread.c was extended. The new code checks that the objfile doesn't already have a separate debug objfile linked to it, and that the objfile isn't itself a separate debug objfile for some other objfile. The coffread code wasn't extended at the same time. I don't know if it's possible for the coffread code to get into the same state where these checks are needed, but I don't see why having these checks would be a problem. In a later commit I plan to merge this part of the elfread and coffread code, so bringing these two pieces of code into line first makes that job easier. I've tested this with a simple test binary compiled with the mingw toolchain on a Linux host. After compiling the binary and splitting out the debug info GDB still finds and loads the separate debug info. Approved-By: Tom Tromey <tom@tromey.com>
2023-11-14Fix another linker command line option that was not being recognised in its ↵Nick Clifton2-1/+7
long form. PR 28910 * lexsup.c (ld_options): Ensure that the --mri-script option is correctly recognised.
2023-11-14Improve objdump's handling of compressed sections.Nick Clifton8-149/+171
PR 31062 * objdump.c (decompressed_dumps): New local variable. (usage): Mention the -z/--decompress option. (long_options): Add --decompress. (dump_section_header): Add "COMPRESSED" to the Flags field of any compressed section. (dump_section): Warn users when dumping a compressed section. (display_any_bfd): Decompress the section if decompressed_dumps is true. (main): Handle the -z/--decompress option. * NEWS: Mention the new feature. * doc/binutils.texi: Document the new feature. * testsuite/binutils-all/objdump.s: Update expected output. * testsuite/binutils-all/objdump.exp: Add test of -Z -s. * testsuite/binutils-all/objdump.Zs: New file. * readelf.c (maybe_expand_or_relocate_section): New function. Contains common code found in dump functions. Adds a note message if a compressed section is not being decompressed. (dump_section_as_strings): Use new function. (dump_section_as_bytes): Likewise.
2023-11-14Automatic date update in version.inGDB Administrator1-1/+1
2023-11-13[gdb/tui] Don't include border_width in left_marginTom de Vries2-3/+3
Currently left_margin does not match its documentation: ... /* Return the size of the left margin space, this is the space used to display things like breakpoint markers. */ int left_margin () const { return box_width () + TUI_EXECINFO_SIZE + extra_margin (); } ... It is stated that the left margin is reserved to display things, but the box_width is not used for that. Fix this by dropping box_width () from the left_margin calculation. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2023-11-13[gdb/tui] Add tui_win_info::{box_width,box_size}Tom de Vries7-19/+35
In tui_source_window::set_contents we have: ... /* Take hilite (window border) into account, when calculating the number of lines. */ int nlines = height - 2; ... The '2' represents the total size of the window border (or box, in can_box terms), in this case one line at the top and one line at the bottom. Likewise, '1' is used to represent the width of the window border. Introduce new functions: - tui_win_info::box_width () and - tui_win_info::box_size () that can be used instead instead of these hardcoded constants. Implement these such that they return 0 when can_box () == false. Tested patch completeness by making all windows unboxed: ... @@ -85,7 +85,7 @@ struct tui_win_info /* Return true if this window can be boxed. */ virtual bool can_box () const { - return true; + return false; } int box_width () const ... and test-driving TUI. This required eliminating an assert in tui_source_window_base::show_source_content, I've included that part as well. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2023-11-13[gdb/tui] Refactor prefresh call in tui_source_window_base::refresh_windowTom de Vries1-2/+5
Currently the call to prefresh in tui_source_window_base::refresh_window looks like: ... prefresh (m_pad.get (), 0, pad_x, y + 1, x + left_margin, y + m_content.size (), x + left_margin + view_width - 1); ... This is hard to parse. It's not obvious what the arguments mean, and there's repetition in the argument calculation. Fix this by rewriting the call as follows: - use sminrow, smincol, smaxrow and smaxcol variables for the last 4 arguments, and - calculate the smaxrow and smaxcol variables based on the sminrow and smincol variables. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2023-11-13Fix the gdb.ada/inline-section-gc.exp testCarl Love2-4/+20
The original intention of the test appears to be checking to make sure setting a breakpoint in an inlined function didn't set multiple breakpoints where one of them was at address 0. The gdb.ada/inline-section-gc.exp test may pass or fail depending on the version of gnat. Per the discussion on IRC, the ada inlining appears to have some target dependencies. In this test there are two functions, callee and caller. Function calee is inlined into caller. The test sets a breakpoint in function callee. The reported location where the breakpoint is set may be at the requested location in callee or the location in caller after callee has been inlined. The test needs to accept either location as correct provided the breakpoint address is not zero. This patch checks to see if the reported breakpoint is in function callee or function caller and fails if the breakpoint address is 0x0. The line number where the breakpoint is set will match the requested line if the breakpoint location is reported is callee.adb. If the breakpoint is reported in caller.adb, the line number in caller is the breakpoint location in callee where it is inlined into caller. This patch fixes the single regression failure for the test on PowerPC. It does not introduce any failures on X86-64.
2023-11-13GNU-ld: ARM: Issues when trying to set target output architectureNick Clifton2-1/+7
PR 28910 * lexsup.c (ld_options): Ensure that the --format option is correctly recognised.
2023-11-13Regenerate gas/config.in and ld/configureMark Wielaard2-5/+9
commit d173146d9 "MIPS: Change all E_MIPS_* to EF_MIPS_*" changed gas/config.in to rename USE_E_MIPS_ABI_O32 to USE_EF_MIPS_ABI_O32 this new name sorts differently when regenerating gas/config.in commit e922d1eaa "Add ability to change linker warning messages into errors when reporting executable stacks and/or executable segments." Introduced two new help strings for --enable-error-execstack and --enable-error-rwx-segments in configure.ac which weren't included in ld/configure when regenerated. * gas/config.in: Regenerate. * ld/configure: Likewise.
2023-11-13Add documentation for the MIPS assembler's -march=from-abi command line optionNick Clifton1-0/+5
2023-11-13MIPS: Fix binutils-all tests for r6 triplesYunQiang Su2-1/+3
2023-11-13Fix redundant space typo in linker documentation.Chung-Ju Wu2-1/+5
2023-11-13Cancel execution command on thread exit, when stepping, nexting, etc.Pedro Alves2-36/+118
If your target has no support for TARGET_WAITKIND_NO_RESUMED events (and no way to support them, such as the yet-unsubmitted AMDGPU target), and you step over thread exit with scheduler-locking on, this is what you get: (gdb) n [Thread ... exited] *hang* Getting back the prompt by typing Ctrl-C may not even work, since no inferior thread is running to receive the SIGINT. Even if it works, it seems unnecessarily harsh. If you started an execution command for which there's a clear thread of interest (step, next, until, etc.), and that thread disappears, then I think it's more user friendly if GDB just detects the situation and aborts the command, giving back the prompt. That is what this commit implements. It does this by explicitly requesting the target to report thread exit events whenever the main resumed thread has a thread_fsm. Note that unlike stepping over a breakpoint, we don't need to enable clone events in this case. With this patch, we get: (gdb) n [Thread 0x7ffff7d89700 (LWP 3961883) exited] Command aborted, thread exited. (gdb) Reviewed-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I901ab64c91d10830590b2dac217b5264635a2b95
2023-11-13Document remote clone events, and QThreadOptions packetPedro Alves2-3/+145
This commit documents in both manual and NEWS: - the new remote clone event stop reply, - the new QThreadOptions packet and its current defined options, - the associated "set/show remote thread-events-packet" command, - and the associated QThreadOptions qSupported feature. Approved-By: Eli Zaretskii <eliz@gnu.org> Change-Id: Ic1c8de1fefba95729bbd242969284265de42427e
2023-11-13Testcases for stepping over thread exit syscall (PR gdb/27338)Simon Marchi6-0/+333
Add new gdb.threads/step-over-thread-exit.exp and gdb.threads/step-over-thread-exit-while-stop-all-threads.exp testcases, exercising stepping over thread exit syscall. These make use of lib/my-syscalls.S to define the exit syscall. Co-authored-by: Pedro Alves <pedro@palves.net> Reviewed-By: Andrew Burgess <aburgess@redhat.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338 Change-Id: Ie8b2c5747db99b7023463a897a8390d9e814a9c9
2023-11-13gdb/testsuite/lib/my-syscalls.S: Refactor new SYSCALL macroPedro Alves1-18/+32
Refactor the syscall assembly code in gdb/testsuite/lib/my-syscalls.S behind a SYSCALL macro so that it's easy to add new syscalls without duplicating code. Note that the way the macro is implemented, it only works correctly for syscalls with up to 3 arguments, and, if the syscall doesn't return (the macro doesn't bother to save/restore callee-saved registers). The following patch will want to use the macro to define a wrapper for the "exit" syscall, so the limitations continue to be sufficient. Change-Id: I8acf1463b11a084d6b4579aaffb49b5d0dea3bba Reviewed-By: Andrew Burgess <aburgess@redhat.com>
2023-11-13Report thread exit event for leader if reporting thread exit eventsPedro Alves2-12/+68
If GDB sets the GDB_THREAD_OPTION_EXIT option on a thread, then if the thread disappears from the thread list, GDB expects to shortly see a thread exit event for it. See e.g., here, in remote_target::update_thread_list(): /* Do not remove the thread if we've requested to be notified of its exit. For example, the thread may be displaced stepping, infrun will need to handle the exit event, and displaced stepping info is recorded in the thread object. If we deleted the thread now, we'd lose that info. */ if ((tp->thread_options () & GDB_THREAD_OPTION_EXIT) != 0) continue; There's one scenario that is deleting a thread from the remote/gdbserver thread list without ever reporting a corresponding thread exit event though -- check_zombie_leaders. This can lead to GDB getting confused. For example, with a following patch that enables GDB_THREAD_OPTION_EXIT whenever schedlock is enabled, we'd see this regression: $ make check RUNTESTFLAGS="--target_board=native-extended-gdbserver" TESTS="gdb.threads/no-unwaited-for-left.exp" ... Running src/gdb/testsuite/gdb.threads/no-unwaited-for-left.exp ... FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits (timeout) ... some more cascading FAILs ... gdb.log shows: (gdb) continue Continuing. FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits (timeout) A passing run would have resulted in: (gdb) continue Continuing. No unwaited-for children left. (gdb) PASS: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits note how the leader thread is not listed in the remote-reported XML thread list below: (gdb) set debug remote 1 (gdb) set debug infrun 1 (gdb) info threads Id Target Id Frame * 1 Thread 1163850.1163850 "no-unwaited-for" main () at /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/no-unwaited-for-left.c:65 3 Thread 1163850.1164130 "no-unwaited-for" [remote] Sending packet: $Hgp11c24a.11c362#39 (gdb) c Continuing. [infrun] clear_proceed_status_thread: 1163850.1163850.0 ... [infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=1, current thread [1163850.1163850.0] at 0x55555555534f [remote] Sending packet: $QPassSignals:#f3 [remote] Packet received: OK [remote] Sending packet: $QThreadOptions;3:p11c24a.11c24a#f3 [remote] Packet received: OK ... [infrun] target_set_thread_options: [options for Thread 1163850.1163850 are now 0x3] ... [infrun] do_target_resume: resume_ptid=1163850.1163850.0, step=0, sig=GDB_SIGNAL_0 [remote] Sending packet: $vCont;c:p11c24a.11c24a#98 [infrun] prepare_to_wait: prepare_to_wait [infrun] reset: reason=handling event [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote [infrun] fetch_inferior_event: exit [infrun] fetch_inferior_event: enter [infrun] scoped_disable_commit_resumed: reason=handling event [infrun] random_pending_event_thread: None found. [remote] wait: enter [remote] Packet received: N [remote] wait: exit [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) = [infrun] print_target_wait_results: -1.0.0 [process -1], [infrun] print_target_wait_results: status->kind = NO_RESUMED [infrun] handle_inferior_event: status->kind = NO_RESUMED [remote] Sending packet: $Hgp0.0#ad [remote] Packet received: OK [remote] Sending packet: $qXfer:threads:read::0,1000#92 [remote] Packet received: l<threads>\n<thread id="p11c24a.11c362" core="0" name="no-unwaited-for" handle="0097d8f7ff7f0000"/>\n</threads>\n [infrun] handle_no_resumed: TARGET_WAITKIND_NO_RESUMED (ignoring: found resumed) ... ... however, infrun decided there was a resumed thread still, so ignored the TARGET_WAITKIND_NO_RESUMED event. Debugging GDB, we see that the "found resumed" thread that GDB finds, is the leader thread. Even though that thread is not on the remote-reported thread list, it is still on the GDB thread list, due to the special case in remote.c mentioned above. This commit addresses the issue by fixing GDBserver to report a thread exit event for the zombie leader too, i.e., making GDBserver respect the "if thread has GDB_THREAD_OPTION_EXIT set, report a thread exit" invariant. To do that, it takes a bit more code than one would imagine off hand, due to the fact that we currently always report LWP exit pending events as TARGET_WAITKIND_EXITED, and then decide whether to convert it to TARGET_WAITKIND_THREAD_EXITED just before reporting the event to GDBserver core. For the zombie leader scenario described, we need to record early on that we want to report a THREAD_EXITED event, and then make sure that decision isn't lost along the way to reporting the event to GDBserver core. Reviewed-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I1e68fccdbc9534434dee07163d3fd19744c8403b
2023-11-13Don't resume new threads if scheduler-locking is in effectPedro Alves5-9/+164
If scheduler-locking is in effect, e.g., with "set scheduler-locking on", and you step over a function that spawns a new thread, the new thread is allowed to run free, at least until some event is hit, at which point, whether the new thread is re-resumed depends on a number of seemingly random factors. E.g., if the target is all-stop, and the parent thread hits a breakpoint, and GDB decides the breakpoint isn't interesting to report to the user, then the parent thread is resumed, but the new thread is left stopped. I think that letting the new threads run with scheduler-locking enabled is a defect. This commit fixes that, making use of the new clone events on Linux, and of target_thread_events() on targets where new threads have no connection to the thread that spawned them. Testcase and documentation changes included. Approved-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: Andrew Burgess <aburgess@redhat.com> Change-Id: Ie12140138b37534b7fc1d904da34f0f174aa11ce
2023-11-13gdbserver: Queue no-resumed event after thread exitPedro Alves5-20/+53
Normally, if the last resumed thread on the target exits, the server sends a no-resumed event to GDB. If however, GDB enables the GDB_THREAD_OPTION_EXIT option on a thread, and, that thread exits, the server sends a thread exit event for that thread instead. In all-stop RSP mode, since events can only be forwarded to GDB one at a time, and the whole target stops whenever an event is reported, GDB resumes the target again after getting a THREAD_EXITED event, and then the server finally reports back a no-resumed event if/when appropriate. For non-stop RSP though, events are asynchronous, and if the server sends a thread-exit event for the last resumed thread, the no-resumed event is never sent. This patch makes sure that in non-stop mode, the server queues a no-resumed event after the thread-exit event if it was the last resumed thread that exited. Without this, we'd see failures in step-over-thread-exit testcases added later in the series, like so: continue Continuing. - No unwaited-for children left. - (gdb) PASS: gdb.threads/step-over-thread-exit.exp: displaced-stepping=off: non-stop=on: target-non-stop=on: schedlock=off: ns_stop_all=1: continue stops when thread exits + FAIL: gdb.threads/step-over-thread-exit.exp: displaced-stepping=off: non-stop=on: target-non-stop=on: schedlock=off: ns_stop_all=1: continue stops when thread exits (timeout) (and other similar ones) Reviewed-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I927d78b30f88236dbd5634b051a716f72420e7c7
2023-11-13stop_all_threads: (re-)enable async before waiting for stopsPedro Alves1-0/+81
Running the gdb.threads/step-over-thread-exit-while-stop-all-threads.exp testcase added later in the series against gdbserver, after the TARGET_WAITKIND_NO_RESUMED fix from the following patch, would run into an infinite loop in stop_all_threads, leading to a timeout: FAIL: gdb.threads/step-over-thread-exit-while-stop-all-threads.exp: displaced-stepping=off: target-non-stop=on: iter 0: continue (timeout) The is really a latent bug, and it is about the fact that stop_all_threads stops listening to events from a target as soon as it sees a TARGET_WAITKIND_NO_RESUMED, ignoring that TARGET_WAITKIND_NO_RESUMED may be delayed. handle_no_resumed knows how to handle delayed no-resumed events, but stop_all_threads was never taught to. In more detail, here's what happens with that testcase: #1 - Multiple threads report breakpoint hits to gdb. #2 - gdb picks one events, and it's for thread 1. All other stops are left pending. thread 1 needs to move past a breakpoint, so gdb stops all threads to start an inline step over for thread 1. While stopping threads, some of the threads that were still running report events that are also left pending. #2 - gdb steps thread 1 #3 - Thread 1 exits while stepping (it steps over an exit syscall), gdbserver reports thread exit for thread 1 #4 - Thread 1 was the last resumed thread, so gdbserver also reports no-resumed: [remote] Notification received: Stop:w0;p3445d0.3445d3 [remote] Sending packet: $vStopped#55 [remote] Packet received: N [remote] Sending packet: $vStopped#55 [remote] Packet received: OK #5 - gdb processes the thread exit for thread 1, finishes the step over and restarts threads. #6 - gdb picks the next event to process out of one of the resumed threads with pending events: [infrun] random_resumed_with_pending_wait_status: Found 32 events, selecting #11 #7 - This is again a breakpoint hit and the breakpoint needs to be stepped over too, so gdb starts a step-over dance again. #8 - We reach stop_all_threads, which finds that some threads need to be stopped. #9 - wait_one finally consumes the no-resumed event queue by #4. Seeing this, wait_one disable target async, to stop listening for events out of the remote target. #10 - We still haven't seen all the stops expected, so stop_all_threads tries another iteration. #11 - Because the remote target is no longer async, and there are no other targets, wait_one return no-resumed immediately without polling the remote target. #12 - We still haven't seen all the stops expected, so stop_all_threads tries another iteration. goto #11, looping forever. Fix this by explicitly enabling/re-enabling target async on targets that can async, before waiting for stops. Reviewed-By: Andrew Burgess <aburgess@redhat.com> Change-Id: Ie3ffb0df89635585a6631aa842689cecc989e33f
2023-11-13gdb: clear step over information on thread exit (PR gdb/27338)Pedro Alves5-17/+174
GDB doesn't handle correctly the case where a thread steps over a breakpoint (using either in-line or displaced stepping), and the executed instruction causes the thread to exit. Using the test program included later in the series, this is what it looks like with displaced-stepping, on x86-64 Linux, where we have two displaced-step buffers: $ ./gdb -q -nx --data-directory=data-directory build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit -ex "b my_exit_syscall" -ex r Reading symbols from build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit... Breakpoint 1 at 0x123c: file src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S, line 68. Starting program: build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1". [New Thread 0x7ffff7c5f640 (LWP 2915510)] [Switching to Thread 0x7ffff7c5f640 (LWP 2915510)] Thread 2 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68 68 syscall (gdb) c Continuing. [New Thread 0x7ffff7c5f640 (LWP 2915524)] [Thread 0x7ffff7c5f640 (LWP 2915510) exited] [Switching to Thread 0x7ffff7c5f640 (LWP 2915524)] Thread 3 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68 68 syscall (gdb) c Continuing. [New Thread 0x7ffff7c5f640 (LWP 2915616)] [Thread 0x7ffff7c5f640 (LWP 2915524) exited] [Switching to Thread 0x7ffff7c5f640 (LWP 2915616)] Thread 4 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68 68 syscall (gdb) c Continuing. ... hangs ... The first two times we do "continue", we displaced-step the syscall instruction that causes the thread to exit. When the thread exits, the main thread, waiting on pthread_join, is unblocked. It spawns a new thread, which hits the breakpoint on the syscall again. However, infrun was never notified that the displaced-stepping threads are done using the displaced-step buffer, so now both buffers are marked as used. So when we do the third continue, there are no buffers available to displaced-step the syscall, so the thread waits forever for its turn. When trying the same but with in-line step over (displaced-stepping disabled): $ ./gdb -q -nx --data-directory=data-directory \ build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit \ -ex "b my_exit_syscall" -ex "set displaced-stepping off" -ex r Reading symbols from build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit... Breakpoint 1 at 0x123c: file src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S, line 68. Starting program: build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-thread-exit/step-over-thread-exit [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1". [New Thread 0x7ffff7c5f640 (LWP 2928290)] [Switching to Thread 0x7ffff7c5f640 (LWP 2928290)] Thread 2 "step-over-threa" hit Breakpoint 1, my_exit_syscall () at src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S:68 68 syscall (gdb) c Continuing. [Thread 0x7ffff7c5f640 (LWP 2928290) exited] No unwaited-for children left. (gdb) i th Id Target Id Frame 1 Thread 0x7ffff7c60740 (LWP 2928285) "step-over-threa" 0x00007ffff7f7c9b7 in __pthread_clockjoin_ex () from /usr/lib/libpthread.so.0 The current thread <Thread ID 2> has terminated. See `help thread'. (gdb) thread 1 [Switching to thread 1 (Thread 0x7ffff7c60740 (LWP 2928285))] #0 0x00007ffff7f7c9b7 in __pthread_clockjoin_ex () from /usr/lib/libpthread.so.0 (gdb) c Continuing. ^C^C ... hangs ... The "continue" causes an in-line step to occur, meaning the main thread is stopped while we step the syscall. The stepped thread exits when executing the syscall, the linux-nat target notices there are no more resumed threads to be waited for, so returns TARGET_WAITKIND_NO_RESUMED, which causes the prompt to return. But infrun never clears the in-line step over info. So if we try continuing the main thread, GDB doesn't resume it, because it thinks there's an in-line step in progress that we need to wait for to finish, and we are stuck there. To fix this, infrun needs to be informed when a thread doing a displaced or in-line step over exits. We can do that with the new target_set_thread_options mechanism which is optimal for only enabling exit events of the thread that needs it; or, if that is not supported, by using target_thread_events, which enables thread exit events for all threads. This is done by this commit. This patch then modifies handle_inferior_event in infrun.c to clean up any step-over the exiting thread might have been doing at the time of the exit. The cases to consider are: - the exiting thread was doing an in-line step-over with an all-stop target - the exiting thread was doing an in-line step-over with a non-stop target - the exiting thread was doing a displaced step-over with a non-stop target The displaced-stepping buffer implementation in displaced-stepping.c is modified to account for the fact that it's possible that we "finish" a displaced step after a thread exit event. The buffer that the exiting thread was using is marked as available again and the original instructions under the scratch pad are restored. However, it skips applying the fixup, which wouldn't make sense since the thread does not exist anymore. Another case that needs handling is if a displaced-stepping thread exits, and the event is reported while we are in stop_all_threads. We should call displaced_step_finish in the handle_one function, in that case. It was already called in other code paths, just not the "thread exited" path. This commit doesn't make infrun ask the target to report the TARGET_WAITKIND_THREAD_EXITED events yet, that'll be done later in the series. Note that "stop_print_frame = false;" line is moved to normal_stop, because TARGET_WAITKIND_THREAD_EXITED can also end up with the event transmorphed into TARGET_WAITKIND_NO_RESUMED. Moving it to normal_stop keeps it centralized. Co-authored-by: Simon Marchi <simon.marchi@efficios.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338 Reviewed-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I745c6955d7ef90beb83bcf0ff1d1ac8b9b6285a5
2023-11-13Implement GDB_THREAD_OPTION_EXIT support for native LinuxPedro Alves1-13/+31
This implements support for the new GDB_THREAD_OPTION_EXIT thread option for native Linux. Reviewed-By: Andrew Burgess <aburgess@redhat.com> Change-Id: Ia69fc0b9b96f9af7de7cefc1ddb1fba9bbb0bb90 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338
2023-11-13Implement GDB_THREAD_OPTION_EXIT support for Linux GDBserverPedro Alves2-17/+30
This implements support for the new GDB_THREAD_OPTION_EXIT thread option for Linux GDBserver. Reviewed-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I96b719fdf7fee94709e98bb3a90751d8134f3a38 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338
2023-11-13Introduce GDB_THREAD_OPTION_EXIT thread option, fix step-over-thread-exitPedro Alves4-5/+24
When stepping over a breakpoint with displaced stepping, GDB needs to be informed if the stepped thread exits, otherwise the displaced stepping buffer that was allocated to that thread leaks, and this can result in deadlock, with other threads waiting for their turn to displaced step, but their turn never comes. Similarly, when stepping over a breakpoint in line, GDB also needs to be informed if the stepped thread exits, so that is can clear the step over state and re-resume threads. This commit makes it possible for GDB to ask the target to report thread exit events for a given thread, using the new "thread options" mechanism introduced by a previous patch. This only adds the core bits. Following patches in the series will teach the Linux backends (native & gdbserver) to handle the GDB_THREAD_OPTION_EXIT option, and then a later patch will make use of these thread exit events to clean up displaced stepping and inline stepping state properly. Reviewed-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I96b719fdf7fee94709e98bb3a90751d8134f3a38 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338
2023-11-13Move deleting thread on TARGET_WAITKIND_THREAD_EXITED to corePedro Alves2-12/+41
Currently, infrun assumes that when TARGET_WAITKIND_THREAD_EXITED is reported, the corresponding GDB thread has already been removed from the GDB thread list. Later in the series, that will no longer work, as infrun will need to refer to the thread's thread_info when it processes TARGET_WAITKIND_THREAD_EXITED. As preparation, this patch makes deleting the GDB thread responsibility of infrun, instead of the target. Reviewed-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I013d87f61ffc9aaca49f0d6ce2a43e3ea69274de
2023-11-13gdbserver/linux-low.cc: Ignore event_ptid if TARGET_WAITKIND_IGNOREPedro Alves1-1/+0
gdbserver's linux_process_target::wait loops if: - called in sync mode, and, - wait_1 returns TARGET_WAITKIND_IGNORE, _and_, - wait_1 also returns null_ptid. The null_ptid check fails however when this path is taken: ptid_t linux_process_target::filter_exit_event (lwp_info *event_child, target_waitstatus *ourstatus) { ... if (!is_leader (thread)) { if (report_exit_events_for (thread)) ourstatus->set_thread_exited (0); else ourstatus->set_ignore (); <<<<<<< delete_lwp (event_child); } return ptid; } This makes linux_process_target::wait return TARGET_WAITKIND_IGNORE in sync mode, which is unexpected by the core and fails an assertion. This commit fixes it by just making linux_process_target::wait loop if it got a TARGET_WAITKIND_IGNORE, irrespective of event_ptid. Change-Id: I39776908a6c75cbd68aa04139ffcf7be334868cf
2023-11-13all-stop/synchronous RSP support thread-exit eventsPedro Alves2-1/+7
Currently, GDB does not understand the THREAD_EXITED stop reply in remote all-stop mode. There's no good reason for this, it just happened that THREAD_EXITED was only ever reported in non-stop mode so far. This patch teaches GDB to parse that event in all-stop RSP too. There is no need to add a qSupported feature for this, because the server won't send a THREAD_EXITED event unless GDB explicitly asks for it, with QThreadEvents, or with the GDB_THREAD_OPTION_EXIT QThreadOptions option added in the next patch. Change-Id: Ide5d12391adf432779fe4c79526801c4a5630966
2023-11-13Remove gdb/19675 kfails (displaced stepping + clone)Pedro Alves1-41/+3
Now that gdb/19675 is fixed for both native and gdbserver GNU/Linux, remove the gdb/19675 kfails. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675 Reviewed-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I95c1c38ca370100675d303cd3c8995860bef465d