aboutsummaryrefslogtreecommitdiff
path: root/gdb/breakpoint.c
AgeCommit message (Collapse)AuthorFilesLines
2024-04-12Fix setting watchpoints when current thread is runningPedro Alves1-4/+7
Currently, when the current thread is running, you can print global variables. However, if you try to set a watchpoint on the same globals, GDB errors out, complaining that the selected thread is running. Like so: (gdb) c& Continuing. (gdb) p global $1 = 1098377287 (gdb) watch global Selected thread is running. This patch makes setting the watchpoint work. You'll now get: (gdb) c& Continuing. (gdb) [New Thread 0x7ffff7d6e640 (LWP 434993)] [New Thread 0x7ffff756d640 (LWP 434994)] p global $1 = 88168 (gdb) watch global Hardware watchpoint 2: global (gdb) [Switching to Thread 0x7ffff7d6e640 (LWP 434993)] Thread 2 "function0" hit Hardware watchpoint 2: global Old value = 185420 New value = 185423 int_return () at threads.c:39 39 } The problem is that update_watchpoint calls get_selected_frame unconditionally. We can skip it if the watchpoint expression is only watching globals. This adds a testcase that exercises both all-stop and non-stop, and also software and hardware watchpoints. It is kfailed for software watchpoints, as those require another fix not handled by this patch (the sw watchpoint doesn't fire because GDB doesn't force the running-free thread to switch to single-stepping). Change-Id: I68ca948541aea3edd4f70741f272f543187abe40
2024-03-31gdb: build dprintf commands just once in code_breakpoint constructorAndrew Burgess1-7/+7
I noticed in code_breakpoint::code_breakpoint that we are calling update_dprintf_command_list once for each breakpoint location, when we really only need to call this once per breakpoint -- the data updated by this function, the breakpoint command list -- is per breakpoint, not per breakpoint location. Calling update_dprintf_command_list multiple times is just wasted effort, there's no per location error checking, we don't even pass the current location to the function. This commit moves the update_dprintf_command_list call outside of the per-location loop. There should be no user visible changes after this commit.
2024-03-31gdb: the extra_string in a dprintf breakpoint is never nullptrAndrew Burgess1-11/+5
Given the changes in the previous couple of commits, this commit cleans up some of the asserts and 'if' checks related to the extra_string within a dprintf breakpoint. This commit: 1. Adds some asserts to update_dprintf_command_list about the breakpoint type, and that the extra_string is not nullptr, 2. Given that we know extra_string is not nullptr (this is enforced when the breakpoint is created), we can simplify code_breakpoint::code_breakpoint -- it no longer needs to check for the extra_string is nullptr case, 3. In dprintf_breakpoint::re_set we can remove the assert (this will be checked within update_dprintf_command_list, we can also remove the redundant 'if' check. There should be no user visible changes after this commit.
2024-03-31gdb: change 'if' to gdb_assert in update_dprintf_command_listAndrew Burgess1-2/+3
I noticed in update_dprintf_command_list that we handle the case where the bp_dprintf style breakpoint doesn't have a format and args string. However, I don't believe such a situation is possible. The obvious approach certainly already catches this case: (gdb) dprintf main Format string required If it is possible to create a dprintf breakpoint without a format and args string then I think we should be catching this case and handling it at creation time, rather than having GDB just ignore the situation later on. And so, I propose that we change the 'if' that ignores the case where the format/args string is empty, and instead assert that we do always have a format/args string. The original code, that handled an empty format/args string has existed since commit e7e0cddfb0d4, which is when dprintf support was added to GDB. If I'm correct and this situation can't ever happen then there should be no user visible changes after this commit.
2024-03-31gdb: create_breakpoint: asserts relating to extra_string/parse_extraAndrew Burgess1-13/+28
The goal of this commit is to better define the API for create_breakpoint especially around the use of extra_string and parse_extra. This will be useful in the next commit when I plan to make some changes to create_breakpoint. This commit makes one possibly breaking change: until this commit it was possible to create thread-specific dprintf breakpoint like this: (gdb) dprintf call_me, thread 1 "%s", "hello" Dprintf 2 at 0x401152: file /tmp/hello.c, line 8. (gdb) info breakpoints Num Type Disp Enb Address What 2 dprintf keep y 0x0000000000401152 in call_me at /tmp/hello.c:8 thread 1 stop only in thread 1 printf "%s", "hello" (gdb) This feature of dprintf was not documented, was not tested, and is slightly different in syntax to how we create thread specific breakpoints and/or watchpoints -- the thread condition appears after the first ','. I believe that this worked at all was simply by luck. We happen to pass the parse_extra flag as true from dprintf_command to create_breakpoint. So in this commit I made the choice to change this. We now pass parse_extra as false from dprintf_command to create_breakpoint. With this done it is assumed that the only thing in the extra_string is the dprintf format and arguments. Beyond this change I've updated the comment on create_breakpoint in breakpoint.h, and I've then added some asserts into create_breakpoint as well as moving around some of the error handling. - We now assert on the incoming argument values, - I've moved an error check to sit after the call to find_condition_and_thread_for_sals, this ensures the extra_string was parsed correctly, In dprintf_command: - We now throw an error if there is no format string after the dprintf location. This error was already being thrown, but was being caught later in the process. With this change we catch the missing string earlier, - And, as mentioned earlier, we pass parse_extra as false when calling create_breakpoint, In create_tracepoint_from_upload: - We now throw an error if the parsed location doesn't completely consume the addr_str variable. This error has now effectively moved out of create_breakpoint.
2024-03-31gdb: create_breakpoint: add asserts and additional commentsAndrew Burgess1-0/+6
This commit extends the asserts on create_breakpoint (in the header file), and adds some additional assertions into the definition. The new assert confirms that when the thread and inferior information is going to be parsed from the extra_string, then the thread and inferior arguments should be -1. That is, the caller of create_breakpoint should not try to create a thread/inferior specific breakpoint by *both* specifying thread/inferior *and* asking to parse the extra_string, it's one or the other. There should be no user visible changes after this commit.
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi1-1/+0
Now that defs.h, server.h and common-defs.h are included via the `-include` option, it is no longer necessary for source files to include them. Remove all the inclusions of these files I could find. Update the generation scripts where relevant. Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 Approved-By: Pedro Alves <pedro@palves.net>
2024-03-25gdb: fix b/p conditions with infcalls in multi-threaded inferiorsAndrew Burgess1-0/+2
This commit fixes bug PR 28942, that is, creating a conditional breakpoint in a multi-threaded inferior, where the breakpoint condition includes an inferior function call. Currently, when a user tries to create such a breakpoint, then GDB will fail with: (gdb) break infcall-from-bp-cond-single.c:61 if (return_true ()) Breakpoint 2 at 0x4011fa: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/infcall-from-bp-cond-single.c, line 61. (gdb) continue Continuing. [New Thread 0x7ffff7c5d700 (LWP 2460150)] [New Thread 0x7ffff745c700 (LWP 2460151)] [New Thread 0x7ffff6c5b700 (LWP 2460152)] [New Thread 0x7ffff645a700 (LWP 2460153)] [New Thread 0x7ffff5c59700 (LWP 2460154)] Error in testing breakpoint condition: Couldn't get registers: No such process. An error occurred while in a function called from GDB. Evaluation of the expression containing the function (return_true) will be abandoned. When the function is done executing, GDB will silently stop. Selected thread is running. (gdb) Or, in some cases, like this: (gdb) break infcall-from-bp-cond-simple.c:56 if (is_matching_tid (arg, 1)) Breakpoint 2 at 0x401194: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/infcall-from-bp-cond-simple.c, line 56. (gdb) continue Continuing. [New Thread 0x7ffff7c5d700 (LWP 2461106)] [New Thread 0x7ffff745c700 (LWP 2461107)] ../../src.release/gdb/nat/x86-linux-dregs.c:146: internal-error: x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. The precise error depends on the exact thread state; so there's race conditions depending on which threads have fully started, and which have not. But the underlying problem is always the same; when GDB tries to execute the inferior function call from within the breakpoint condition, GDB will, incorrectly, try to resume threads that are already running - GDB doesn't realise that some threads might already be running. The solution proposed in this patch requires an additional member variable thread_info::in_cond_eval. This flag is set to true (in breakpoint.c) when GDB is evaluating a breakpoint condition. In user_visible_resume_ptid (infrun.c), when the in_cond_eval flag is true, then GDB will only try to resume the current thread, that is, the thread for which the breakpoint condition is being evaluated. This solves the problem of GDB trying to resume threads that are already running. The next problem is that inferior function calls are assumed to be synchronous, that is, GDB doesn't expect to start an inferior function call in thread #1, then receive a stop from thread #2 for some other, unrelated reason. To prevent GDB responding to an event from another thread, we update fetch_inferior_event and do_target_wait in infrun.c, so that, when an inferior function call (on behalf of a breakpoint condition) is in progress, we only wait for events from the current thread (the one evaluating the condition). In do_target_wait I had to change the inferior_matches lambda function, which is used to select which inferior to wait on. Previously the logic was this: auto inferior_matches = [&wait_ptid] (inferior *inf) { return (inf->process_target () != nullptr && ptid_t (inf->pid).matches (wait_ptid)); }; This compares the pid of the inferior against the complete ptid we want to wait on. Before this commit wait_ptid was only ever minus_one_ptid (which is special, and means any process), and so every inferior would match. After this commit though wait_ptid might represent a specific thread in a specific inferior. If we compare the pid of the inferior to a specific ptid then these will not match. The fix is to compare against the pid extracted from the wait_ptid, not against the complete wait_ptid itself. In fetch_inferior_event, after receiving the event, we only want to stop all the other threads, and call inferior_event_handler with INF_EXEC_COMPLETE, if we are not evaluating a conditional breakpoint. If we are, then all the other threads should be left doing whatever they were before. The inferior_event_handler call will be performed once the breakpoint condition has finished being evaluated, and GDB decides to stop or not. The final problem that needs solving relates to GDB's commit-resume mechanism, which allows GDB to collect resume requests into a single packet in order to reduce traffic to a remote target. The problem is that the commit-resume mechanism will not send any resume requests for an inferior if there are already events pending on the GDB side. Imagine an inferior with two threads. Both threads hit a breakpoint, maybe the same conditional breakpoint. At this point there are two pending events, one for each thread. GDB selects one of the events and spots that this is a conditional breakpoint, GDB evaluates the condition. The condition includes an inferior function call, so GDB sets up for the call and resumes the one thread, the resume request is added to the commit-resume queue. When the commit-resume queue is committed GDB sees that there is a pending event from another thread, and so doesn't send any resume requests to the actual target, GDB is assuming that when we wait we will select the event from the other thread. However, as this is an inferior function call for a condition evaluation, we will not select the event from the other thread, we only care about events from the thread that is evaluating the condition - and the resume for this thread was never sent to the target. And so, GDB hangs, waiting for an event from a thread that was never fully resumed. To fix this issue I have added the concept of "forcing" the commit-resume queue. When enabling commit resume, if the force flag is true, then any resumes will be committed to the target, even if there are other threads with pending events. A note on authorship: this patch was based on some work done by Natalia Saiapova and Tankut Baris Aktemur from Intel[1]. I have made some changes to their work in this version. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28942 [1] https://sourceware.org/pipermail/gdb-patches/2020-October/172454.html Co-authored-by: Natalia Saiapova <natalia.saiapova@intel.com> Co-authored-by: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Tested-By: Luis Machado <luis.machado@arm.com> Tested-By: Keith Seitz <keiths@redhat.com>
2024-02-26gdb: Modify the output of "info breakpoints" and "delete breakpoints"Tiezhu Yang1-10/+15
The output of "info breakpoints" includes breakpoint, watchpoint, tracepoint, and catchpoint if they are created, so it should show all the four types are deleted in the output of "info breakpoints" to report empty list after "delete breakpoints". It should also change the output of "delete breakpoints" to make it clear that watchpoints, tracepoints, and catchpoints are also being deleted. This is suggested by Guinevere Larsen, thank you. $ make check-gdb TESTS="gdb.base/access-mem-running.exp" $ gdb/gdb gdb/testsuite/outputs/gdb.base/access-mem-running/access-mem-running [...] (gdb) break main Breakpoint 1 at 0x12000073c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 32. (gdb) watch global_counter Hardware watchpoint 2: global_counter (gdb) trace maybe_stop_here Tracepoint 3 at 0x12000071c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 27. (gdb) catch fork Catchpoint 4 (fork) (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x000000012000073c in main at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:32 2 hw watchpoint keep y global_counter 3 tracepoint keep y 0x000000012000071c in maybe_stop_here at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:27 not installed on target 4 catchpoint keep y fork Without this patch: (gdb) delete breakpoints Delete all breakpoints? (y or n) y (gdb) info breakpoints No breakpoints or watchpoints. (gdb) info breakpoints 3 No breakpoint or watchpoint matching '3'. With this patch: (gdb) delete breakpoints Delete all breakpoints, watchpoints, tracepoints, and catchpoints? (y or n) y (gdb) info breakpoints No breakpoints, watchpoints, tracepoints, or catchpoints. (gdb) info breakpoints 3 No breakpoint, watchpoint, tracepoint, or catchpoint matching '3'. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Approved-by: Kevin Buettner <kevinb@redhat.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2024-02-09gdb: add program_space parameter to disable_breakpoints_in_shlibsSimon Marchi1-4/+3
Make the current_program_space reference bubble up one level. Change-Id: Ide917aa306bff1872d961244901d79f65d2da62e Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-02-09gdb: add inferior parameter to breakpoint_init_inferiorSimon Marchi1-17/+5
By inspection, I believe that breakpoint_init_inferior doesn't call anything that relies on the current program space or inferior. So, add an inferior parameter, to make the current inferior / program space references bubble up one level. Change-Id: Ib07b7a6d360e324f6ae1aa502dd314b8cce421b7 Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-02-09gdb: add program_space parameter to mark_breakpoints_outSimon Marchi1-4/+4
Make the current_program_space reference bubble up one level. Change-Id: Idc8ed78d23bf3bb2969f6963d8cc049f26901c29 Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-02-05gdb: rename struct shobj -> struct solibSimon Marchi1-2/+2
`struct so_list` was recently renamed to `struct shobj` (in 3fe0dfd1604f ("gdb: rename struct so_list to shobj")). In hindsight, `solib` would have been a better name. We have solib.c, the implementations in solib-*.c, many functions with solib in their name, the solib_loaded / solib_unloaded observables, etc. Rename shobj to solib. Change-Id: I0af1c7a9b29bdda027e9af633f6d37e1cfcacd5d Approved-By: Tom Tromey <tom@tromey.com>
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2024-01-08Avoid language-based lookups in startup pathTom Tromey1-1/+3
The previous patches are nearly enough to enable background DWARF reading. However, this hack in language_defn::get_symbol_name_matcher causes an early computation of current_language: /* If currently in Ada mode, and the lookup name is wrapped in '<...>', hijack all symbol name comparisons using the Ada matcher, which handles the verbatim matching. */ if (current_language->la_language == language_ada && lookup_name.ada ().verbatim_p ()) return current_language->get_symbol_name_matcher_inner (lookup_name); I considered various options here -- reversing the order of the checks, or promoting the verbatim mode to not be a purely Ada feature -- but in the end found that the few calls to this during startup could be handled more directly. In the JIT code, and in create_exception_master_breakpoint_hook, gdb is really looking for a certain kind of symbol (text or data) using a linkage name. Changing the lookup here is clearer and probably more efficient as well. In create_std_terminate_master_breakpoint, the lookup can't really be done by linkage name (it would require relying on a certain mangling scheme, and also may trip over versioned symbols) -- but we know that this spot is C++-specific, and so the language ought to be temporarily set to C++ here. After this patch, the "file" case is much faster: (gdb) file /tmp/gdb 2023-10-23 13:16:54.456 - command started Reading symbols from /tmp/gdb... 2023-10-23 13:16:54.520 - command finished Command execution time: 0.225906 (cpu), 0.064313 (wall)
2023-12-13Use unique_xmalloc_ptr in explicit_location_specTom Tromey1-3/+2
This changes explicit_location_spec to use unique_xmalloc_ptr, removing some manual memory management. Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-13Use unique_xmalloc_ptr in linespec_location_specTom Tromey1-4/+5
This changes linespec_location_spec to use unique_xmalloc_ptr, removing some manual memory management. Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-11-28[gdb] Fix segfault in for_each_block, part 1Tom de Vries1-13/+16
When running test-case gdb.base/vfork-follow-parent.exp on powerpc64 (likewise on s390x), I run into: ... (gdb) PASS: gdb.base/vfork-follow-parent.exp: \ exec_file=vfork-follow-parent-exit: target-non-stop=on: non-stop=off: \ resolution_method=schedule-multiple: print unblock_parent = 1 continue^M Continuing.^M Reading symbols from vfork-follow-parent-exit...^M ^M ^M Fatal signal: Segmentation fault^M ----- Backtrace -----^M 0x1027d3e7 gdb_internal_backtrace_1^M src/gdb/bt-utils.c:122^M 0x1027d54f _Z22gdb_internal_backtracev^M src/gdb/bt-utils.c:168^M 0x1057643f handle_fatal_signal^M src/gdb/event-top.c:889^M 0x10576677 handle_sigsegv^M src/gdb/event-top.c:962^M 0x3fffa7610477 ???^M 0x103f2144 for_each_block^M src/gdb/dcache.c:199^M 0x103f235b _Z17dcache_invalidateP13dcache_struct^M src/gdb/dcache.c:251^M 0x10bde8c7 _Z24target_dcache_invalidatev^M src/gdb/target-dcache.c:50^M ... or similar. The root cause for the segmentation fault is that linux_is_uclinux gives an incorrect result: it should always return false, given that we're running on a regular linux system, but instead it returns first true, then false. In more detail, the segmentation fault happens as follows: - a program space with an address space is created - a second program space is about to be created. maybe_new_address_space is called, and because linux_is_uclinux returns true, maybe_new_address_space returns false, and no new address space is created - a second program space with the same address space is created - a program space is deleted. Because linux_is_uclinux now returns false, gdbarch_has_shared_address_space (current_inferior ()->arch ()) returns false, and the address space is deleted - when gdb uses the address space of the remaining program space, we run into the segfault, because the address space is deleted. Hardcoding linux_is_uclinux to false makes the test-case pass. We leave addressing the root cause for the following commit in this series. For now, prevent the segmentation fault by making the address space a refcounted object. This was already suggested here [1]: ... A better solution might be to have the address spaces be reference counted ... Tested on top of trunk on x86_64-linux and ppc64le-linux. Tested on top of gdb-14-branch on ppc64-linux. Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca> PR gdb/30547 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30547 [1] https://sourceware.org/pipermail/gdb-patches/2023-October/202928.html
2023-11-21gdb: Replace gdb::optional with std::optionalLancelot Six1-9/+10
Since GDB now requires C++17, we don't need the internally maintained gdb::optional implementation. This patch does the following replacing: - gdb::optional -> std::optional - gdb::in_place -> std::in_place - #include "gdbsupport/gdb_optional.h" -> #include <optional> This change has mostly been done automatically. One exception is gdbsupport/thread-pool.* which did not use the gdb:: prefix as it already lives in the gdb namespace. Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-11-17gdb: remove get_current_regcacheSimon Marchi1-1/+1
Remove get_current_regcache, inlining the call to get_thread_regcache in callers. When possible, pass the right thread_info object known from the local context. Otherwise, fall back to passing `inferior_thread ()`. This makes the reference to global context bubble up one level, a small step towards the long term goal of reducing the number of references to global context (or rather, moving those references as close as possible to the top of the call tree). No behavior change expected. Change-Id: Ifa6980c88825d803ea586546b6b4c633c33be8d6
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-10-30Remove some frame invalidation codeTom Tromey1-3/+0
I stumbled across a few spots that mention that a function "invalidates frame" and also assignments of NULL to a frame_info_ptr. This code isn't harmful, but is also unnecessary since the introduction of frame_info_ptr -- nowadays frame invalidations are handled automatically. Regression tested on x86-64 Fedora 38. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-10-19gdb: rename struct so_list to shobjSimon Marchi1-3/+2
Now that so_list lists are implemented using intrusive_list, it doesn't really make sense for the element type to be named "_list". Rename to just `struct shobj` (`struct so` was deemed to be not greppable enough). Change-Id: I1063061901298bb40fee73bf0cce44cd12154c0e Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: make so_list::{so_original_name,so_name} std::stringsSimon Marchi1-1/+1
Change these two fields, simplifying memory management and copying. Change-Id: If2559284c515721e71e1ef56ada8b64667eebe55 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: replace some so_list parameters to use referencesSimon Marchi1-2/+3
A subsequent patch changes so_list to be linked using intrusive_list. Iterating an intrusive_list yields some references to the list elements. Convert some functions accepting so_list objects to take references, to make things easier and more natural. Add const where possible and convenient. Change-Id: Id5ab5339c3eb6432e809ad14782952d6a45806f3 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-10gdb: remove target_gdbarchSimon Marchi1-8/+8
This function is just a wrapper around the current inferior's gdbarch. I find that having that wrapper just obscures where the arch is coming from, and that it's often used as "I don't know which arch to use so I'll use this magical target_gdbarch function that gets me an arch" when the arch should in fact come from something in the context (a thread, objfile, symbol, etc). I think that removing it and inlining `current_inferior ()->arch ()` everywhere will make it a bit clearer where that arch comes from and will trigger people into reflecting whether this is the right place to get the arch or not. Change-Id: I79f14b4e4934c88f91ca3a3155f5fc3ea2fadf6b Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-05gdb: remove unnecessary nullptr check in free_objfile observersSimon Marchi1-3/+0
The free_objfile observable is never called with a nullptr objfile. Change-Id: I1e990edeb45bc38009ccb129c623911097ab65fe Approved-By: Tom Tromey <tom@tromey.com>
2023-10-02gdb: remove solib::pspace fieldSimon Marchi1-2/+2
This backlink is not necessary, we always know the program space from the context. Pass it down the solib_unloaded observer. Change-Id: I45a503472dc791f517558b8141901472634e0556 Approved-By: Tom Tromey <tom@tromey.com>
2023-09-26Use string_file::release in some placesTom Tromey1-1/+1
I found a few spots like: string_file f; std::string x = f.string (); However, string_file::string returns a 'const std::string &'... so it seems to me that this must be copying the string (? I find it hard to reason about this in C++). This patch changes these spots to use release() instead, which moves the string. Reviewed-by: Keith Seitz <keiths@redhat.com> Reviewed-by: Lancelot Six <lancelot.six@amd.com>
2023-09-19Use gdb::checked_static_cast for code_breakpointTom Tromey1-2/+4
This replaces some casts to 'code_breakpoint *' with checked_static_cast. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-09-19Use gdb::checked_static_cast for tracepointsTom Tromey1-15/+19
This replaces some casts to 'tracepoint *' with checked_static_cast. Some functions are changed to accept a 'tracepoint *' now, for better type safety. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-09-19Use gdb::checked_static_cast for watchpointsTom Tromey1-152/+147
This replaces some casts to 'watchpoint *' with checked_static_cast. In one spot, an unnecessary block is also removed. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-09-19gdb, breakpoint: add a destructor to the watchpoint structMohamed Bouhaouel1-0/+14
Make sure to unlink the related breakpoint when the watchpoint instance is deleted. This prevents having a wp-related breakpoint that is linked to a NULL watchpoint (e.g. the watchpoint instance is being deleted when the 'watch' command fails). With the below scenario, having such a left out breakpoint will lead to a GDB hang, and this is due to an infinite loop when deleting all inferior breakpoints. Scenario: (gdb) set can-use-hw-watchpoints 0 (gdb) awatch <SCOPE VAR> Can't set read/access watchpoint when hardware watchpoints are disabled. (gdb) rwatch <SCOPE VAR> Can't set read/access watchpoint when hardware watchpoints are disabled. (gdb) <continue the program until the end> >> HANG << Signed-off-by: Mohamed Bouhaouel <mohamed.bouhaouel@intel.com> Reviewed-by: Bruno Larsen <blarsen@redhat.com>
2023-08-23gdb: centralize "[Thread ...exited]" notificationsPedro Alves1-1/+3
Currently, each target backend is responsible for printing "[Thread ...exited]" before deleting a thread. This leads to unnecessary differences between targets, like e.g. with the remote target, we never print such messages, even though we do print "[New Thread ...]". E.g., debugging the gdb.threads/attach-many-short-lived-threads.exp with gdbserver, letting it run for a bit, and then pressing Ctrl-C, we currently see: (gdb) c Continuing. ^C[New Thread 3850398.3887449] [New Thread 3850398.3887500] [New Thread 3850398.3887551] [New Thread 3850398.3887602] [New Thread 3850398.3887653] ... Thread 1 "attach-many-sho" received signal SIGINT, Interrupt. 0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78 78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c (gdb) Above, we only see "New Thread" notifications, even though threads were deleted. After this patch, we'll see: (gdb) c Continuing. ^C[Thread 3558643.3577053 exited] [Thread 3558643.3577104 exited] [Thread 3558643.3577155 exited] [Thread 3558643.3579603 exited] ... [New Thread 3558643.3597415] [New Thread 3558643.3600015] [New Thread 3558643.3599965] ... Thread 1 "attach-many-sho" received signal SIGINT, Interrupt. 0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78 78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c (gdb) q This commit fixes this by moving the thread exit printing to common code instead, triggered from within delete_thread (or rather, set_thread_exited). There's one wrinkle, though. While most targest want to print: [Thread ... exited] the Windows target wants to print: [Thread ... exited with code <exit_code>] ... and sometimes wants to suppress the notification for the main thread. To address that, this commits adds a delete_thread_with_code function, only used by that target (so far). This fix was originally posted as part of a larger series: https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-1-pedro@palves.net/ But didn't really need to be part of that series. In order to get this fix merged sooner, I (Andrew Burgess) have rebased this commit outside of the original series. Any bugs introduced while splitting this patch out and rebasing, are entirely my own. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30129 Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
2023-08-23gdb: add missing notify_breakpoint_modified callAndrew Burgess1-1/+1
The commit: commit b080fe54fb3414b488b8ef323c6c50def061f918 Date: Tue Nov 8 12:32:51 2022 +0000 gdb: add inferior-specific breakpoints introduced a bug in the function breakpoint_set_inferior. The above commit includes this line: gdb::observers::breakpoint_modified.notify (b); when it should have instead used this line: notify_breakpoint_modified (b); The change to use notify_breakpoint_modified was introduced to GDB after commit b080fe54fb34 was written, but before it was merged, and I failed to update this part of the code during the rebase. The consequence of this error is that the MI interpreter will not emit breakpoint-modified notifications when breakpoint_set_inferior is called. In this commit I update the code to call notify_breakpoint_modified, and add a test that checks the MI events are being emitted correctly in this case.
2023-08-17gdb: add inferior-specific breakpointsAndrew Burgess1-49/+188
This commit extends the breakpoint mechanism to allow for inferior specific breakpoints (but not watchpoints in this commit). As GDB gains better support for multiple connections, and so for running multiple (possibly unrelated) inferiors, then it is not hard to imagine that a user might wish to create breakpoints that apply to any thread in a single inferior. To achieve this currently, the user would need to create a condition possibly making use of the $_inferior convenience variable, which, though functional, isn't the most user friendly. This commit adds a new 'inferior' keyword that allows for the creation of inferior specific breakpoints. Inferior specific breakpoints are automatically deleted when the associated inferior is removed from GDB, this is similar to how thread-specific breakpoints are deleted when the associated thread is deleted. Watchpoints are already per-program-space, which in most cases mean watchpoints are already inferior specific. There is a small window where inferior-specific watchpoints might make sense, which is after a vfork, when two processes are sharing the same address space. However, I'm leaving that as an exercise for another day. For now, attempting to use the inferior keyword with a watchpoint will give an error, like this: (gdb) watch a8 inferior 1 Cannot use 'inferior' keyword with watchpoints A final note on the implementation: currently, inferior specific breakpoints, like thread-specific breakpoints, are inserted into every inferior, GDB then checks once the inferior stops if we are in the correct thread or inferior, and resumes automatically if we stopped in the wrong thread/inferior. An obvious optimisation here is to only insert breakpoint locations into the specific program space (which mostly means inferior) that contains either the inferior or thread we are interested in. This would reduce the number times GDB has to stop and then resume again in a multi-inferior setup. I have a series on the mailing list[1] that implements this optimisation for thread-specific breakpoints. Once this series has landed I'll update that series to also handle inferior specific breakpoints in the same way. For now, inferior specific breakpoints are just slightly less optimal, but this is no different to thread-specific breakpoints in a multi-inferior debug session, so I don't see this as a huge problem. [1] https://inbox.sourceware.org/gdb-patches/cover.1685479504.git.aburgess@redhat.com/
2023-08-09gdb, breakpoint: add breakpoint location debugging logsMihails Strasuns1-0/+110
Add new commands: set debug breakpoint on|off show debug breakpoint This patch introduces new debugging information that prints breakpoint location insertion and removal flow. The debug output looks like: ~~~ (gdb) set debug breakpoint on (gdb) disassemble main Dump of assembler code for function main: 0x0000555555555129 <+0>: endbr64 0x000055555555512d <+4>: push %rbp 0x000055555555512e <+5>: mov %rsp,%rbp => 0x0000555555555131 <+8>: mov $0x0,%eax 0x0000555555555136 <+13>: pop %rbp 0x0000555555555137 <+14>: ret End of assembler dump. (gdb) break *0x0000555555555137 Breakpoint 2 at 0x555555555137: file main.c, line 4. [breakpoint] update_global_location_list: insert_mode = UGLL_MAY_INSERT (gdb) c Continuing. [breakpoint] update_global_location_list: insert_mode = UGLL_INSERT [breakpoint] insert_bp_location: Breakpoint 2 (0x5565daddb1e0) at address 0x555555555137 in main at main.c:4 [breakpoint] insert_bp_location: Breakpoint -2 (0x5565dab51c10) at address 0x7ffff7fd37b5 [breakpoint] insert_bp_location: Breakpoint -5 (0x5565dab68f30) at address 0x7ffff7fe509e [breakpoint] insert_bp_location: Breakpoint -7 (0x5565dab694f0) at address 0x7ffff7fe63f4 [breakpoint] remove_breakpoint_1: Breakpoint 2 (0x5565daddb1e0) at address 0x555555555137 in main at main.c:4 due to regular remove [breakpoint] remove_breakpoint_1: Breakpoint -2 (0x5565dab51c10) at address 0x7ffff7fd37b5 due to regular remove [breakpoint] remove_breakpoint_1: Breakpoint -5 (0x5565dab68f30) at address 0x7ffff7fe509e due to regular remove [breakpoint] remove_breakpoint_1: Breakpoint -7 (0x5565dab694f0) at address 0x7ffff7fe63f4 due to regular remove Breakpoint 2, 0x0000555555555137 in main () at main.c:4 4 } ~~~ Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
2023-08-03gdb: avoid double stop after failed breakpoint condition checkAndrew Burgess1-12/+0
This commit replaces this earlier commit: commit 2e411b8c68eb2b035b31d5b00d940d4be1a0928b Date: Fri Oct 14 14:53:15 2022 +0100 gdb: don't always print breakpoint location after failed condition check and is a result of feedback received here[1]. The original commit addressed a problem where, if a breakpoint condition included an inferior function call, and if the inferior function call failed, then GDB would announce the stop twice. Here's an example of GDB's output before the above commit that shows the problem being addressed: (gdb) break foo if (some_func ()) Breakpoint 1 at 0x40111e: file bpcond.c, line 11. (gdb) r Starting program: /tmp/bpcond Program received signal SIGSEGV, Segmentation fault. 0x0000000000401116 in some_func () at bpcond.c:5 5 return *p; Error in testing condition for breakpoint 1: The program being debugged stopped while in a function called from GDB. Evaluation of the expression containing the function (some_func) will be abandoned. When the function is done executing, GDB will silently stop. Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5 5 return *p; (gdb) The original commit addressed this issue in breakpoint.c, by spotting that the $pc had changed while evaluating the breakpoint condition, and inferring from this that GDB must have stopped elsewhere. However, the way in which the original commit suppressed the second stop announcement was to set bpstat::print to true -- this tells GDB not to print the frame during the stop announcement, and for the CLI this is fine, however, it was pointed out that for the MI this still isn't really enough. Below is an example from an MI session after the above commit was applied, this shows the problem with the above commit: -break-insert -c "cond_fail()" foo ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000040111e",func="foo",file="/tmp/mi-condbreak-fail.c",line="30",thread-groups=["i1"],cond="cond_fail()",times="0",original-location="foo"} (gdb) -exec-run =thread-group-started,id="i1",pid="2636270" =thread-created,id="1",group-id="i1" =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7fd3110",to="0x00007ffff7ff2bb4"}] ^running *running,thread-id="all" (gdb) =library-loaded,id="/lib64/libm.so.6",target-name="/lib64/libm.so.6",host-name="/lib64/libm.so.6",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7e59390",to="0x00007ffff7ef4f98"}] =library-loaded,id="/lib64/libc.so.6",target-name="/lib64/libc.so.6",host-name="/lib64/libc.so.6",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7ca66b0",to="0x00007ffff7df3c5f"}] ~"\nProgram" ~" received signal SIGSEGV, Segmentation fault.\n" ~"0x0000000000401116 in cond_fail () at /tmp/mi-condbreak-fail.c:24\n" ~"24\t return *p;\t\t\t/* Crash here. */\n" *stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0x0000000000401116",func="cond_fail",args=[],file="/tmp/mi-condbreak-fail.c",fullname="/tmp/mi-condbreak-fail.c",line="24",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="9" &"Error in testing condition for breakpoint 1:\n" &"The program being debugged was signaled while in a function called from GDB.\n" &"GDB remains in the frame where the signal was received.\n" &"To change this behavior use \"set unwindonsignal on\".\n" &"Evaluation of the expression containing the function\n" &"(cond_fail) will be abandoned.\n" &"When the function is done executing, GDB will silently stop.\n" =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000040111e",func="foo",file="/tmp/mi-condbreak-fail.c",fullname="/tmp/mi-condbreak-fail.c",line="30",thread-groups=["i1"],cond="cond_fail()",times="1",original-location="foo"} *stopped (gdb) Notice that we still see two '*stopped' lines, the first includes the full frame information, while the second has no frame information, this is a result of bpstat::print having been set. Ideally, the second '*stopped' line should not be present. By setting bpstat::print I was addressing the problem too late, this flag really only changes how interp::on_normal_stop prints the stop event, and interp::on_normal_stop is called (indirectly) from the normal_stop function in infrun.c. A better solution is to avoid calling normal_stop at all for the stops which should not be reported to the user, and this is what I do in this commit. This commit has 3 parts: 1. In breakpoint.c, revert the above commit, 2. In fetch_inferior_event (infrun.c), capture the stop-id before calling handle_inferior_event. If, after calling handle_inferior_event, the stop-id has changed, then this indicates that somewhere within handle_inferior_event, a stop was announced to the user. If this is the case then GDB should not call normal_stop, and we should rely on whoever announced the stop to ensure that we are in a PROMPT_NEEDED state, which means the prompt will be displayed once fetch_inferior_event returns. And, 3. In infcall.c, do two things: (a) In run_inferior_call, after making the inferior call, ensure that either async_disable_stdin or async_enable_stdin is called to put the prompt state, and stdin handling into the correct state based on whether the inferior call completed successfully or not, and (b) In call_thread_fsm::should_stop, call async_enable_stdin rather than changing the prompt state directly. This isn't strictly necessary, but helped me understand this code more. This async_enable_stdin call is only reached if normal_stop is not going to be called, and replaces the async_enable_stdin call that exists in normal_stop. Though we could just adjust the prompt state if felt (to me) much easier to understand when I could see this call and the corresponding call in normal_stop. With these changes in place now, when the inferior call (from the breakpoint condition) fails, infcall.c leaves the prompt state as PROMPT_NEEDED, and leaves stdin registered with the event loop. Back in fetch_inferior_event GDB notices that the stop-id has changed and so avoids calling normal_stop. And on return from fetch_inferior_event GDB will display the prompt and handle input from stdin. As normal_stop is not called the MI problem is solved, and the test added in the earlier mentioned commit still passes just fine, so the CLI has not regressed. [1] https://inbox.sourceware.org/gdb-patches/6fd4aa13-6003-2563-5841-e80d5a55d59e@palves.net/
2023-07-10gdb: include location number in breakpoint error messageAndrew Burgess1-3/+11
This commit improves the output of this previous commit: commit 2dc3457a454a35d0617dc1f9cc1db77468471f95 Date: Fri Oct 14 13:22:55 2022 +0100 gdb: include breakpoint number in testing condition error message The earlier commit extended the error message: Error in testing breakpoint condition: to include the breakpoint number, e.g.: Error in testing breakpoint condition 3: This commit extends takes this further, and includes the location number if the breakpoint has multiple locations, so we might now see: Error in testing breakpoint condition 3.2: Just as with how GDB reports a normal breakpoint stop, if a breakpoint only has a single location then the location number is not included, this keeps things nice and consistent. I've extended one of the tests to cover the new functionality. Approved-By: Pedro Alves <pedro@palves.net>
2023-06-05[gdb] Fix more typosTom de Vries1-1/+1
Fix some more typos: - distinquish -> distinguish - actualy -> actually - singe -> single - frash -> frame - chid -> child - dissassembler -> disassembler - uninitalized -> uninitialized - precontidion -> precondition - regsiters -> registers - marge -> merge - sate -> state - garanteed -> guaranteed - explictly -> explicitly - prefices (nonstandard plural) -> prefixes - bondary -> boundary - formated -> formatted - ithe -> the - arrav -> array - coresponding -> corresponding - owend -> owned - fials -> fails - diasm -> disasm - ture -> true - tpye -> type There's one code change, the name of macro SIG_CODE_BONDARY_FAULT changed to SIG_CODE_BOUNDARY_FAULT. Tested on x86_64-linux.
2023-06-03[gdb] Fix typosTom de Vries1-1/+1
Fix a few typos: - implemention -> implementation - convertion(s) -> conversion(s) - backlashes -> backslashes - signoring -> ignoring - (un)ambigious -> (un)ambiguous - occured -> occurred - hidding -> hiding - temporarilly -> temporarily - immediatelly -> immediately - sillyness -> silliness - similiar -> similar - porkuser -> pokeuser - thats -> that - alway -> always - supercede -> supersede - accomodate -> accommodate - aquire -> acquire - priveleged -> privileged - priviliged -> privileged - priviledges -> privileges - privilige -> privilege - recieve -> receive - (p)refered -> (p)referred - succesfully -> successfully - successfuly -> successfully - responsability -> responsibility - wether -> whether - wich -> which - disasbleable -> disableable - descriminant -> discriminant - construcstor -> constructor - underlaying -> underlying - underyling -> underlying - structureal -> structural - appearences -> appearances - terciarily -> tertiarily - resgisters -> registers - reacheable -> reachable - likelyhood -> likelihood - intepreter -> interpreter - disassemly -> disassembly - covnersion -> conversion - conviently -> conveniently - atttribute -> attribute - struction -> struct - resonable -> reasonable - popupated -> populated - namespaxe -> namespace - intialize -> initialize - identifer(s) -> identifier(s) - expection -> exception - exectuted -> executed - dungerous -> dangerous - dissapear -> disappear - completly -> completely - (inter)changable -> (inter)changeable - beakpoint -> breakpoint - automativ -> automatic - alocating -> allocating - agressive -> aggressive - writting -> writing - reguires -> requires - registed -> registered - recuding -> reducing - opeartor -> operator - ommitted -> omitted - modifing -> modifying - intances -> instances - imbedded -> embedded - gdbaarch -> gdbarch - exection -> execution - direcive -> directive - demanged -> demangled - decidely -> decidedly - argments -> arguments - agrument -> argument - amespace -> namespace - targtet -> target - supress(ed) -> suppress(ed) - startum -> stratum - squence -> sequence - prompty -> prompt - overlow -> overflow - memember -> member - languge -> language - geneate -> generate - funcion -> function - exising -> existing - dinking -> syncing - destroh -> destroy - clenaed -> cleaned - changep -> changedp (name of variable) - arround -> around - aproach -> approach - whould -> would - symobl -> symbol - recuse -> recurse - outter -> outer - freeds -> frees - contex -> context Tested on x86_64-linux. Reviewed-By: Tom Tromey <tom@tromey.com>
2023-05-30gdb: add interp::on_breakpoint_modified methodSimon Marchi1-19/+28
Same idea as previous patches, but for breakpoint_modified. Change-Id: I4f0a9edea912de431e32451d74224b2022a7c328
2023-05-30gdb: add interp::on_breakpoint_deleted methodSimon Marchi1-1/+10
Same idea as previous patches, but for breakpoint_deleted. Change-Id: I59c231ce963491bb1eee1432ee1090138f09e19c
2023-05-30gdb: add interp::on_breakpoint_created methodSimon Marchi1-1/+11
Same idea as previous patches, but for breakpoint_created. Change-Id: I614113c924edc243590018b8fb3bf69cb62215ef
2023-05-25gdb: remove breakpoint_pointer_iteratorSimon Marchi1-304/+301
Remove the breakpoint_pointer_iterator layer. Adjust all users of all_breakpoints and all_tracepoints to use references instead of pointers. Change-Id: I376826f812117cee1e6b199c384a10376973af5d Reviewed-By: Andrew Burgess <aburgess@redhat.com>
2023-05-25gdb: link breakpoints with intrusive_listSimon Marchi1-26/+10
Change-Id: I043d8d6f3dd864d80d5088f6ffc2c098337249ea Reviewed-By: Andrew Burgess <aburgess@redhat.com>
2023-05-25gdb: remove bp_location_pointer_iteratorSimon Marchi1-124/+123
Remove the bp_location_pointer_iterator layer. Adjust all users of breakpoint::locations to use references instead of pointers. Change-Id: Iceed34f5e0f5790a9cf44736aa658be6d1ba1afa Reviewed-By: Andrew Burgess <aburgess@redhat.com>
2023-05-25gdb: use intrusive_list for breakpoint locationsSimon Marchi1-126/+113
Replace the hand-maintained linked lists of breakpoint locations with and intrusive list. - Remove breakpoint::loc, add breakpoint::m_locations. - Add methods for the various manipulations that need to be done on the location list, while maintaining reasonably good encapsulation. - bp_location currently has a default constructor because of one use in hoist_existing_locations. hoist_existing_locations now returns a bp_location_list, and doesn't need the default-constructor bp_location anymore, so remove the bp_location default constructor. - I needed to add a call to clear_locations in delete_breakpoint to avoid a use-after-free. - Add a breakpoint::last_loc method, for use in set_breakpoint_condition. bp_location_range uses reference_to_pointer_iterator, so that all existing callers of breakpoint::locations don't need to change right now. It will be removed in the next patch. The rest of the changes are to adapt the call sites to use the new methods, of breakpoint::locations, rather than breakpoint::loc directly. Change-Id: I25f7ee3d66a4e914a0540589ac414b3b820b6e70 Reviewed-By: Andrew Burgess <aburgess@redhat.com>
2023-05-25gdb: add breakpoint::first_loc methodsSimon Marchi1-57/+55
Add convenience first_loc methods to struct breakpoint (const and non-const overloads). A subsequent patch changes the list of locations to be an intrusive_list and makes the actual list private, so these spots would need to change from: b->loc to something ugly like: *b->locations ().begin () That would make the code much heavier and not readable. There is a surprisingly big number of places that access the first location of breakpoints. Whether this is correct, or these spots fail to consider the possibility of multi-location breakpoints, I don't know. But anyhow, I think that using this instead: b->first_loc () conveys the intention better than the other two forms. Change-Id: Ibbefe3e4ca6cdfe570351fe7e2725f2ce11d1e95 Reviewed-By: Andrew Burgess <aburgess@redhat.com>
2023-05-25gdb: add breakpoint "has locations" methodsSimon Marchi1-29/+33
Add three convenience methods to struct breakpoint: - has_locations: returns true if the breakpoint has at least one location - has_single_location: returns true if the breakpoint has exactly one location - has_multiple_locations: returns true if the breakpoint has more than one location A subsequent patch changes the list of breakpoints to be an intrusive_list, so all these spots would need to change. But in any case, I think that this: if (b->has_multiple_locations ()) conveys the intention better than: if (b->loc != nullptr && b->loc->next != nullptr) Change-Id: Ib18c3605fd35d425ef9df82cb7aacff1606c6747 Reviewed-By: Andrew Burgess <aburgess@redhat.com>
generated by cgit v1.1 at 2024-11-22 15:35:52 +0000