aboutsummaryrefslogtreecommitdiff
path: root/gdb/inferior.h
AgeCommit message (Collapse)AuthorFilesLines
2023-09-11Specialize std::hash for ptid_tTom Tromey1-1/+1
This changes hash_ptid to instead be a specialization of std::hash. This makes it a little easier to use with standard containers. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-08-23gdb: remove the silent parameter from exit_inferior_1 and cleanupAndrew Burgess1-4/+3
After the previous commit, exit_inferior_1 no longer makes use of the silent parameter. This commit removes this parameter and cleans up the callers. After doing this exit_inferior_1, exit_inferior, and exit_inferior_silent are all equivalent, so rename exit_inferior_1 to exit_inferior and delete exit_inferior_silent, update all the callers. Also I spotted the declaration exit_inferior_num_silent in inferior.h, but this function is not defined anywhere, so I deleted the declaration. There should be no user visible changes after this commit.
2023-08-23gdb: make inferior::clear_thread_list always silentPedro Alves1-3/+2
After this commit: commit a78ef8757418105c35685c5d82b9fdf79459321b Date: Wed Jun 22 18:10:00 2022 +0100 Always emit =thread-exited notifications, even if silent The function mi_interp::on_thread_exited (or mi_thread_exit as the function was called back then) no longer makes use of the "silent" parameter. As a result there is no difference between inferior::clear_thread_list with silent true or false, because: - None of the interpreter ::on_thread_exited functions rely on the silent parameter, and - None of GDB's thread_exit observers rely on the silent parameter either. This commit removes the silent parameter from inferior::clear_thread_list, and makes the function always silent. This commit was originally 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. I had an interest in seeing this patch merged: https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-31-pedro@palves.net/ Which also didn't really need to be part of the larger series, but does depend, at least a little, on this commit. In order to get the fix I'm interested in merged quicker, 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. There should be no user visible changes after this commit. Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
2023-08-17gdb: add inferior-specific breakpointsAndrew Burgess1-0/+11
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-15Mention process_stratum in inferior::priv commentTom Tromey1-1/+1
From what I can tell, inferior::priv is reserved for the process_stratum target. It seems to me that it has to be, because currenlty only such targets use it, and if a target at another stratum started using this field, then conflicts could occur. This patch documents this. Reviewed-by: John Baldwin <jhb@FreeBSD.org>
2023-07-19Fix gdb.Inferior.read_memory without execution (PR dap/30644)Pedro Alves1-4/+4
Andrew reported that the previous change to gdb.Inferior.read_memory & friends introducing scoped_restore_current_inferior_for_memory broke gdb.dap/stop-at-main.exp. This is also reported as PR dap/30644. The root of the problem is that all the methods that now use scoped_restore_current_inferior_for_memory cause GDB to crash with a failed assert if they are run on an inferior that is not yet started. E.g.: (gdb) python i = gdb.selected_inferior () (gdb) python i.read_memory (4,4) gdb/thread.c:626: internal-error: any_thread_of_inferior: Assertion `inf->pid != 0' failed. This patch fixes the problem by removing scoped_restore_current_inferior_for_memory's ctor ptid parameter and the any_thread_of_inferior calls completely, and making scoped_restore_current_inferior_for_memory switch inferior_ptid to a pid ptid. I was a little worried that some port might be assuming inferior_ptid points at a thread in the xfer_partial memory access routines. We know that anything that supports forks must not assume that, due to how detach_breakpoints works. I looked at a number of xfer_partial implementations, and didn't see anything that is looking at inferior_ptid in a way that would misbehave. I'm thinking that we could go forward with this and just fix ports if they break. While on some ports like on AMD GPU we have thread-specific address spaces, and so when accessing memory for those address spaces, we must have the right thread context (via inferior_ptid) selected, in Inferior.read_memory, we only have the inferior to work with, so this API as is can't be used to access thread-specific address spaces. IOW, it can only be used to access the global address space that is visible to both the CPU and the GPUs. In proc-service.c:ps_xfer_memory, the other spot using scoped_restore_current_inferior_for_memory, we're always accessing per-inferior memory. If we end up using scoped_restore_current_inferior_for_memory later to set up the context to read memory from a specific thread, then we can add an alternative ctor that takes a thread_info pointer, and make inferior_ptid point to the thread, for example. New test added to gdb.python/py-inferior.exp, exercising Inferior.read_memory without execution. No regressions on native and extended-gdbserver x86_64 GNU/Linux. Reviewed-By: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30644 Change-Id: I11309c5ddbbb51a4594cf63c21b3858bfd9aed19
2023-07-17Remove unused declaration of child_terminal_init_with_pgrpTom Tromey1-2/+0
child_terminal_init_with_pgrp is declared but not defined. This patch removes the declaration. Tested by grep and rebuilding.
2023-07-14Introduce scoped_restore_current_inferior_for_memoryTom Tromey1-0/+29
This introduces a new class, scoped_restore_current_inferior_for_memory, and arranges to use it in a few places. This class is intended to handle setting up and restoring the various globals that are needed to read or write memory -- but without invalidating the frame cache. I wasn't able to test the change to aix-thread.c. Approved-By: Pedro Alves <pedro@palves.net>
2023-05-01Turn set_inferior_args_vector into method of inferiorTom Tromey1-2/+3
This patch turns set_inferior_args_vector into an overload of inferior::set_args. Regression tested on x86-64 Fedora 36.
2023-04-17gdb: add maybe_switch_inferior functionSimon Marchi1-0/+7
Add the maybe_switch_inferior function, which ensures that the given inferior is the current one. Return an instantiated scoped_restore_current_thread object only we actually needed to switch inferior. Returning a scoped_restore_current_thread requires it to be move-constructible, so give it a move constructor. Change-Id: I1231037102ed6166f2530399e8257ad937fb0569 Reviewed-By: Pedro Alves <pedro@palves.net>
2023-04-04gdb: make find_thread_ptid an inferior methodSimon Marchi1-0/+3
Make find_thread_ptid (the overload that takes an inferior) a method of struct inferior. Change-Id: Ie5b9fa623ff35aa7ddb45e2805254fc8e83c9cd4 Reviewed-By: Tom Tromey <tom@tromey.com>
2023-02-06gdb: adjust comment on target_desc_info::from_user_pSimon Marchi1-1/+1
Remove the stale reference to INFO, which is now "this target description info" now. Change-Id: I35dbdb089048ed7cfffe730d3134ee391b176abf
2023-02-03gdb: make target_desc_info_from_user_p a method of target_desc_infoSimon Marchi1-0/+5
Move the implementation over to target_desc_info. Remove the target_desc_info forward declaration in target-descriptions.h, it's no longer needed. Change-Id: Ic95060341685afe0b73af591ca6efe32f5e7e892
2023-02-03gdb: change inferior::tdesc_info to non-pointerSimon Marchi1-1/+1
I initially made this field a unique pointer, to have automatic memory management. But I then thought that the field didn't really need to be allocated separately from struct inferior. So make it a regular non-pointer field of inferior. Remove target_desc_info_free, as it's no longer needed. Change-Id: Ica2b97071226f31c40e86222a2f6922454df1229
2023-02-03gdb: move target_desc_info to inferior.hSimon Marchi1-0/+23
In preparation for the following patch, where struct inferior needs to "see" struct target_desc_info, move target_desc_info to the header file. I initially moved the structure to target-descriptions.h, and later made inferior.h include target-descriptions.h. This worked, but it then occured to me that target_desc_info is really an inferior property that involves a target description, so I think it makes sense to have it in inferior.h. Change-Id: I3e81d04faafcad431e294357389f3d4c601ee83d
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
2022-12-14gdb: remove the pop_all_targets (and friends) global functionsAndrew Burgess1-0/+20
This commit removes the global functions pop_all_targets, pop_all_targets_above, and pop_all_targets_at_and_above, and makes them methods on the inferior class. As the pop_all_targets functions will unpush each target, which decrements the targets reference count, it is possible that the target might be closed. Right now, closing a target, in some cases, depends on the current inferior being set correctly, that is, to the inferior from which the target was popped. To facilitate this I have used switch_to_inferior_no_thread within the new methods. Previously it was the responsibility of the caller to ensure that the correct inferior was selected. In a couple of places (event-top.c and top.c) I have been able to remove a previous switch_to_inferior_no_thread call. In remote_unpush_target (remote.c) I have left the switch_to_inferior_no_thread call as it is required for the generic_mourn_inferior call.
2022-12-13Fix control-c handling on WindowsTom Tromey1-0/+10
As Hannes pointed out, the Windows target-async patches broke C-c handling there. Looking into this, I found a few oddities, fixed here. First, windows_nat_target::interrupt calls GenerateConsoleCtrlEvent. I think this event can be ignored by the inferior, so it's not a great way to interrupt. Instead, using DebugBreakProcess (or a more complicated thing for Wow64) seems better. Second, windows_nat_target did not implement the pass_ctrlc method. Implementing this lets us remove the special code to call SetConsoleCtrlHandler and instead integrate into gdb's approach to C-c handling. I believe that this should also fix the race that's described in the comment that's being removed. Initially, I thought a simpler version of this patch would work. However, I think what happens is that some other library (I'm not sure what) calls SetConsoleCtrlHandler while gdb is running, and this intercepts and handles C-c -- so that the gdb SIGINT handler is not called. C-break continues to work, presumably because whatever handler is installed ignores it. This patch works around this issue by ensuring that the gdb handler always comes first.
2022-12-13Refactor code to check for terminal sharingTom Tromey1-0/+11
This refactors the code to check for terminal sharing. is_gdb_terminal is exported, and sharing_input_terminal_1 is renamed, slightly refactored, and moved to posix-hdep.c. A new Windows-specific implementation of this function is added to mingw-hdep.c. MSDN has a warning about GetConsoleProcessList This API is not recommended and does not have a virtual terminal equivalent. [...] Applications remoting via cross-platform utilities and transports like SSH may not work as expected if using this API. However, we believe this isn't likely to be an issue for gdb.
2022-10-31Use enum for gdbarch's call_dummy_locationTom Tromey1-3/+0
This changes gdbarch to use an enum for call_dummy_location, providing a little more type safety.
2022-10-10Change GDB to use frame_info_ptrTom Tromey1-3/+3
This changes GDB to use frame_info_ptr instead of frame_info * The substitution was done with multiple sequential `sed` commands: sed 's/^struct frame_info;/class frame_info_ptr;/' sed 's/struct frame_info \*/frame_info_ptr /g' - which left some issues in a few files, that were manually fixed. sed 's/\<frame_info \*/frame_info_ptr /g' sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace problems. The changed files were then manually checked and some 'sed' changes undone, some constructors and some gets were added, according to what made sense, and what Tromey originally did Co-Authored-By: Bruno Larsen <blarsen@redhat.com> Approved-by: Tom Tomey <tom@tromey.com>
2022-10-03gdb: constify inferior::target_is_pushedSimon Marchi1-1/+1
Change-Id: Ia4143b9c63cb76e2c824ba773c66f5c5cd94b2aa
2022-09-29gdb: constify target_stack::is_pushedSimon Marchi1-1/+1
The target_ops parameters here can be made const. Change-Id: Ibc18b17d6b21d06145251a03e68aca90538117d6
2022-07-28Rewrite registry.hTom Tromey1-6/+1
This rewrites registry.h, removing all the macros and replacing it with relatively ordinary template classes. The result is less code than the previous setup. It replaces large macros with a relatively straightforward C++ class, and now manages its own cleanup. The existing type-safe "key" class is replaced with the equivalent template class. This approach ended up requiring relatively few changes to the users of the registry code in gdb -- code using the key system just required a small change to the key's declaration. All existing users of the old C-like API are now converted to use the type-safe API. This mostly involved changing explicit deletion functions to be an operator() in a deleter class. The old "save/free" two-phase process is removed, and replaced with a single "free" phase. No existing code used both phases. The old "free" callbacks took a parameter for the enclosing container object. However, this wasn't truly needed and is removed here as well.
2022-06-28gdb+gdbserver/Linux: avoid reading registers while going through shellPedro Alves1-0/+7
For every stop, Linux GDB and GDBserver save the stopped thread's PC, in lwp->stop_pc. This is done in save_stop_reason, in both gdb/linux-nat.c and gdbserver/linux-low.cc. However, while we're going through the shell after "run", in startup_inferior, we shouldn't be reading registers, as we haven't yet determined the target's architecture -- the shell's architecture may not even be the same as the final inferior's. In gdb/linux-nat.c, lwp->stop_pc is only needed when the thread has stopped for a breakpoint, and since when going through the shell, no breakpoint is going to hit, we could simply teach save_stop_reason to only record the stop pc when the thread stopped for a breakpoint. However, in gdbserver/linux-low.cc, lwp->stop_pc is used in more cases than breakpoint hits (e.g., it's used in tracepoints & the "while-stepping" feature). So to avoid GDB vs GDBserver divergence, we apply the same approach to both implementations. We set a flag in the inferior (process in GDBserver) whenever it is being nursed through the shell, and when that flag is set, save_stop_reason bails out early. While going through the shell, we'll only ever get process exits (normal or signalled), random signals, and exec events, so nothing is lost. Change-Id: If0f01831514d3a74d17efd102875de7d2c6401ad
2022-04-04gdb: replace inferior::waiting_for_vfork_done with ↵Simon Marchi1-4/+4
inferior::thread_waiting_for_vfork_done The inferior::waiting_for_vfork_done flag indicates that some thread in that inferior is waiting for a vfork-done event. Subsequent patches will need to know which thread precisely is waiting for that event. Replace the boolean flag (waiting_for_vfork_done) with a thread_info pointer (thread_waiting_for_vfork_done). I think there is a latent buglet in that waiting_for_vfork_done is currently not reset on inferior exec or exit. I could imagine that if a thread in the parent process calls exec or exit while another thread of the parent process is waiting for its vfork child to exec or exit, we could end up with inferior::waiting_for_vfork_done without a thread actually waiting for a vfork-done event anymore. And since that flag is checked in resume_1, things could misbehave there. Since the new field points to a thread_info object, and those are destroyed on exec or exit, it could be worse now since we could try to access freed memory, if thread_waiting_for_vfork_done were to point to a stale thread_info. To avoid this, clear the field in infrun_inferior_exit and infrun_inferior_execd. Change-Id: I31b847278613a49ba03fc4915f74d9ceb228fdce
2022-03-07gdb/mi: fix regression in mi -add-inferior commandUmair Sair1-0/+7
Prior to the multi-target support commit: commit 5b6d1e4fa4fc6827c7b3f0e99ff120dfa14d65d2 Date: Fri Jan 10 20:06:08 2020 +0000 Multi-target support When a new inferior was added using the MI -add-inferior command, the new inferior would be using the same target as all the other inferiors. This makes sense, GDB only supported a single target stack at a time. After the above commit, each inferior has its own target stack. To maintain backward compatibility, for the CLI add-inferior command, when a new inferior is added the above commit has the new inferior inherit a copy of the target stack from the current inferior. Unfortunately, this same backward compatibility is missing for the MI. This commit fixes this oversight. Now, when the -add-inferior MI command is used, the new inferior will inherit a copy of the target stack from the current inferior.
2022-02-15gdb: add a symbol* argument to get_return_valueLancelot SIX1-2/+8
Add an argument to the get_return_value function to indicate the symbol of the function the debuggee is returning from. This will be used by the following patch. Since the function return type can be deduced from the symbol remove the value_type argument which becomes redundant. No user visible change after this patch. Tested on x86_64-linux. Change-Id: Idf1279f1f7199f5022738a6679e0fa63fbd22edc Co-authored-by: Simon Marchi <simon.marchi@polymtl.ca>
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
This commit brings all the changes made by running gdb/copyright.py as per GDB's Start of New Year Procedure. For the avoidance of doubt, all changes in this commits were performed by the script.
2021-07-23gdb: make inferior::m_terminal an std::stringSimon Marchi1-8/+10
Same idea as the previous patch, but for m_terminal. Change-Id: If9367d5db8c976a4336680adca4ea5bc31ab64d2
2021-07-23gdb: make inferior::m_cwd an std::stringSimon Marchi1-10/+8
Same idea as the previous patch, but for m_cwd. To keep things consistent across the board, change get_inferior_cwd as well, which is shared with GDBserver. So update the related GDBserver code too. Change-Id: Ia2c047fda738d45f3d18bc999eb67ceb8400ce4e
2021-07-23gdb: make inferior::m_args an std::stringSimon Marchi1-18/+8
With the current code, both a NULL pointer and an empty string can mean "no arguments". We don't need this distinction. Changing to a string has the advantage that there is now a single state for that (an empty string), which makes the code a bit simpler in my opinion. Change-Id: Icdc622820f7869478791dbaa84b4a1c7fec21ced
2021-07-23gdb: add setter/getter for inferior cwdSimon Marchi1-4/+23
Add cwd/set_cwd to the inferior class, remove set_inferior_args. Keep get_inferior_args, because it is used from fork_inferior, in shared code. The cwd could eventually be passed as a parameter eventually, though, I think that would be cleaner. Change-Id: Ifb72ea865d7e6f9a491308f0d5c1595579d8427e
2021-07-23gdb: add setter/getter for inferior argumentsSimon Marchi1-7/+29
Add args/set_args to the inferior class, remove the set_inferior_args and get_inferior_args functions, that would just be wrappers around them. Change-Id: If87d52f3402ce08be26c32897ae8915d9f6d1ea3
2021-07-23gdb: remove inferior::{argc,argv}Simon Marchi1-9/+0
There are currently two states that the inferior args can be stored. The main one is the `args` field, where they are stored as a single string. The other one is the `argc`/`argv` fields. This last one is only used for arguments passed in GDB's command line. And the only outcome is that when get_inferior_args is called, `argc`/`argv` are serialized into `args`. So really, `argc`/`argv` is just a staging area before moving the arguments in `args`. Simplify this by only keeping the `args` field. Change set_inferior_args_vector to immediately serialize the arguments into `args`, work that would be done in get_inferior_args later anyway. The only time where this work would be "wasted" is when the user passes some arguments on the command line, but does not end up running the program. But that just seems unlikely. And it's not that much work. Change-Id: Ica0b9859397c095f6530350c8fb3c36905f2044a
2021-07-17gdb: make all_inferiors_safe actually workSimon Marchi1-1/+1
The test gdb.threads/fork-plus-threads.exp fails since 08bdefb58b78 ("gdb: make inferior_list use intrusive_list"): FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left Looking at the log, we see that we are left with a bunch of inferiors in the detach-on-fork=off case: info inferiors^M Num Description Connection Executable ^M * 1 <null> <snip>/fork-plus-threads ^M 2 <null> <snip>/fork-plus-threads ^M 3 <null> <snip>/fork-plus-threads ^M 4 <null> <snip>/fork-plus-threads ^M 5 <null> <snip>/fork-plus-threads ^M 6 <null> <snip>/fork-plus-threads ^M 7 <null> <snip>/fork-plus-threads ^M 8 <null> <snip>/fork-plus-threads ^M 9 <null> <snip>/fork-plus-threads ^M 10 <null> <snip>/fork-plus-threads ^M 11 <null> <snip>/fork-plus-threads ^M (gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left when we expect to have just one. The problem is prune_inferiors not pruning inferiors. And this is caused by all_inferiors_safe not actually iterating on inferiors. The current implementation: inline all_inferiors_safe_range all_inferiors_safe () { return {}; } default-constructs an all_inferiors_safe_range, which default-constructs an all_inferiors_safe_iterator as its m_begin field, which default-constructs a all_inferiors_iterator. A default-constructed all_inferiors_iterator is an end iterator, which means we have constructed an (end,end) all_inferiors_safe_range. We actually need to pass down the list on which we want to iterator (that is the inferior_list global), so that all_inferiors_iterator's first constructor is chosen. We also pass nullptr as the proc_target filter. In this case, we don't do any filtering, but if in the future all_inferiors_safe needed to allow filtering on process target (like all_inferiors does), we could pass down a process target pointer. basic_safe_iterator's constructor needs to be changed to allow constructing the wrapped iterator with multiple arguments, not just one. With this, gdb.threads/fork-plus-threads.exp is passing once again for me. Change-Id: I650552ede596e3590c4b7606ce403690a0278a01
2021-07-12gdb: maintain ptid -> thread map, optimize find_thread_ptidSimon Marchi1-0/+6
When debugging a large number of threads (thousands), looking up a thread by ptid_t using the inferior::thread_list linked list can add up. Add inferior::thread_map, an std::unordered_map indexed by ptid_t, and change the find_thread_ptid function to look up a thread using std::unordered_map::find, instead of iterating on all of the inferior's threads. This should make it faster to look up a thread from its ptid. Change-Id: I3a8da0a839e18dee5bb98b8b7dbeb7f3dfa8ae1c Co-Authored-By: Pedro Alves <pedro@palves.net>
2021-07-12gdb: maintain per-process-target list of resumed threads with pending wait ↵Simon Marchi1-2/+1
status Looking up threads that are both resumed and have a pending wait status to report is something that we do quite often in the fast path and is expensive if there are many threads, since it currently requires walking whole thread lists. The first instance is in maybe_set_commit_resumed_all_targets. This is called after handling each event in fetch_inferior_event, to see if we should ask targets to commit their resumed threads or not. If at least one thread is resumed but has a pending wait status, we don't ask the targets to commit their resumed threads, because we want to consume and handle the pending wait status first. The second instance is in random_pending_event_thread, where we want to select a random thread among all those that are resumed and have a pending wait status. This is called every time we try to consume events, to see if there are any pending events that we we want to consume, before asking the targets for more events. To allow optimizing these cases, maintain a per-process-target list of threads that are resumed and have a pending wait status. In maybe_set_commit_resumed_all_targets, we'll be able to check in O(1) if there are any such threads simply by checking whether the list is empty. In random_pending_event_thread, we'll be able to use that list, which will be quicker than iterating the list of threads, especially when there are no resumed with pending wait status threads. About implementation details: using the new setters on class thread_info, it's relatively easy to maintain that list. Any time the "resumed" or "pending wait status" property is changed, we check whether that should cause the thread to be added or removed from the list. In set_thread_exited, we try to remove the thread from the list, because keeping an exited thread in that list would make no sense (especially if the thread is freed). My first implementation assumed that a process stratum target was always present when set_thread_exited is called. That's however, not the case: in some cases, targets unpush themselves from an inferior and then call "exit_inferior", which exits all the threads. If the target is unpushed before set_thread_exited is called on the threads, it means we could mistakenly leave some threads in the list. I tried to see how hard it would be to make it such that targets have to exit all threads before unpushing themselves from the inferior (that would seem logical to me, we don't want threads belonging to an inferior that has no process target). That seemed quite difficult and not worth the time at the moment. Instead, I changed inferior::unpush_target to remove all threads of that inferior from the list. As of this patch, the list is not used, this is done in the subsequent patches. The debug messages in process-stratum-target.c need to print some ptids. However, they can't use target_pid_to_str to print them without introducing a dependency on the current inferior (the current inferior is used to get the current target stack). For debug messages, I find it clearer to print the spelled out ptid anyway (the pid, lwp and tid values). Add a ptid_t::to_string method that returns a string representation of the ptid that is meant for debug messages, a bit like we already have frame_id::to_string. Change-Id: Iad8f93db2d13984dd5aa5867db940ed1169dbb67
2021-07-12gdb: make inferior_list use intrusive_listPedro Alves1-5/+4
Change inferior_list, the global list of inferiors, to use intrusive_list. I think most other changes are somewhat obvious fallouts from this change. There is a small change in behavior in scoped_mock_context. Before this patch, constructing a scoped_mock_context would replace the whole inferior list with only the new mock inferior. Tests using two scoped_mock_contexts therefore needed to manually link the two inferiors together, as the second scoped_mock_context would bump the first mock inferior from the thread list. With this patch, a scoped_mock_context adds its mock inferior to the inferior list on construction, and removes it on destruction. This means that tests run with mock inferiors in the inferior list in addition to any pre-existing inferiors (there is always at least one). There is no possible pid clash problem, since each scoped mock inferior uses its own process target, and pids are per process target. Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: I7eb6a8f867d4dcf8b8cd2dcffd118f7270756018
2021-07-12gdb: introduce intrusive_list, make thread_info use itPedro Alves1-5/+9
GDB currently has several objects that are put in a singly linked list, by having the object's type have a "next" pointer directly. For example, struct thread_info and struct inferior. Because these are simply-linked lists, and we don't keep track of a "tail" pointer, when we want to append a new element on the list, we need to walk the whole list to find the current tail. It would be nice to get rid of that walk. Removing elements from such lists also requires a walk, to find the "previous" position relative to the element being removed. To eliminate the need for that walk, we could make those lists doubly-linked, by adding a "prev" pointer alongside "next". It would be nice to avoid the boilerplate associated with maintaining such a list manually, though. That is what the new intrusive_list type addresses. With an intrusive list, it's also possible to move items out of the list without destroying them, which is interesting in our case for example for threads, when we exit them, but can't destroy them immediately. We currently keep exited threads on the thread list, but we could change that which would simplify some things. Note that with std::list, element removal is O(N). I.e., with std::list, we need to walk the list to find the iterator pointing to the position to remove. However, we could store a list iterator inside the object as soon as we put the object in the list, to address it, because std::list iterators are not invalidated when other elements are added/removed. However, if you need to put the same object in more than one list, then std::list<object> doesn't work. You need to instead use std::list<object *>, which is less efficient for requiring extra memory allocations. For an example of an object in multiple lists, see the step_over_next/step_over_prev fields in thread_info: /* Step-over chain. A thread is in the step-over queue if these are non-NULL. If only a single thread is in the chain, then these fields point to self. */ struct thread_info *step_over_prev = NULL; struct thread_info *step_over_next = NULL; The new intrusive_list type gives us the advantages of an intrusive linked list, while avoiding the boilerplate associated with manually maintaining it. intrusive_list's API follows the standard container interface, and thus std::list's interface. It is based the API of Boost's intrusive list, here: https://www.boost.org/doc/libs/1_73_0/doc/html/boost/intrusive/list.html Our implementation is relatively simple, while Boost's is complicated and intertwined due to a lot of customization options, which our version doesn't have. The easiest way to use an intrusive_list is to make the list's element type inherit from intrusive_node. This adds a prev/next pointers to the element type. However, to support putting the same object in more than one list, intrusive_list supports putting the "node" info as a field member, so you can have more than one such nodes, one per list. As a first guinea pig, this patch makes the per-inferior thread list use intrusive_list using the base class method. Unlike Boost's implementation, ours is not a circular list. An earlier version of the patch was circular: the intrusive_list type included an intrusive_list_node "head". In this design, a node contained pointers to the previous and next nodes, not the previous and next elements. This wasn't great for when debugging GDB with GDB, as it was difficult to get from a pointer to the node to a pointer to the element. With the design proposed in this patch, nodes contain pointers to the previous and next elements, making it easy to traverse the list by hand and inspect each element. The intrusive_list object contains pointers to the first and last elements of the list. They are nullptr if the list is empty. Each element's node contains a pointer to the previous and next elements. The first element's previous pointer is nullptr and the last element's next pointer is nullptr. Therefore, if there's a single element in the list, both its previous and next pointers are nullptr. To differentiate such an element from an element that is not linked into a list, the previous and next pointers contain a special value (-1) when the node is not linked. This is necessary to be able to reliably tell if a given node is currently linked or not. A begin() iterator points to the first item in the list. An end() iterator contains nullptr. This makes iteration until end naturally work, as advancing past the last element will make the iterator contain nullptr, making it equal to the end iterator. If the list is empty, a begin() iterator will contain nullptr from the start, and therefore be immediately equal to the end. Iterating on an intrusive_list yields references to objects (e.g. `thread_info&`). The rest of GDB currently expects iterators and ranges to yield pointers (e.g. `thread_info*`). To bridge the gap, add the reference_to_pointer_iterator type. It is used to define inf_threads_iterator. Add a Python pretty-printer, to help inspecting intrusive lists when debugging GDB with GDB. Here's an example of the output: (top-gdb) p current_inferior_.m_obj.thread_list $1 = intrusive list of thread_info = {0x61700002c000, 0x617000069080, 0x617000069400, 0x61700006d680, 0x61700006eb80} It's not possible with current master, but with this patch [1] that I hope will be merged eventually, it's possible to index the list and access the pretty-printed value's children: (top-gdb) p current_inferior_.m_obj.thread_list[1] $2 = (thread_info *) 0x617000069080 (top-gdb) p current_inferior_.m_obj.thread_list[1].ptid $3 = { m_pid = 406499, m_lwp = 406503, m_tid = 0 } Even though iterating the list in C++ yields references, the Python pretty-printer yields pointers. The reason for this is that the output of printing the thread list above would be unreadable, IMO, if each thread_info object was printed in-line, since they contain so much information. I think it's more useful to print pointers, and let the user drill down as needed. [1] https://sourceware.org/pipermail/gdb-patches/2021-April/178050.html Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: I3412a14dc77f25876d742dab8f44e0ba7c7586c0
2021-07-06gdb: introduce iterator_range, remove next_adapterSimon Marchi1-2/+2
I was always a bit confused by next_adapter, because it kind of mixes the element type and the iterator type. In reality, it is not much more than a class that wraps two iterators (begin and end). However, it assumes that: - you can construct the begin iterator by passing a pointer to the first element of the iterable - you can default-construct iterator to make the end iterator I think that by generalizing it a little bit, we can re-use it at more places. Rename it to "iterator_range". I think it describes a bit better: it's a range made by wrapping a begin and end iterator. Move it to its own file, since it's not related to next_iterator anymore. iterator_range has two constructors. The variadic one, where arguments are forwarded to construct the underlying begin iterator. The end iterator is constructed through default construction. This is a generalization of what we have today. There is another constructor which receives already constructed begin and end iterators, useful if the end iterator can't be obtained by default-construction. Or, if you wanted to make a range that does not end at the end of the container, you could pass any iterator as the "end". This generalization allows removing some "range" classes, like all_inferiors_range. These classes existed only to pass some arguments when constructing the begin iterator. With iterator_range, those same arguments are passed to the iterator_range constructed and then forwarded to the constructed begin iterator. There is a small functional difference in how iterator_range works compared to next_adapter. next_adapter stored the pointer it received as argument and constructeur an iterator in the `begin` method. iterator_range constructs the begin iterator and stores it as a member. Its `begin` method returns a copy of that iterator. With just iterator_range, uses of next_adapter<foo> would be replaced with: using foo_iterator = next_iterator<foo>; using foo_range = iterator_range<foo_iterator>; However, I added a `next_range` wrapper as a direct replacement for next_adapter<foo>. IMO, next_range is a slightly better name than next_adapter. The rest of the changes are applications of this new class. gdbsupport/ChangeLog: * next-iterator.h (class next_adapter): Remove. * iterator-range.h: New. gdb/ChangeLog: * breakpoint.h (bp_locations_range): Remove. (bp_location_range): New. (struct breakpoint) <locations>: Adjust type. (breakpoint_range): Use iterator_range. (tracepoint_range): Use iterator_range. * breakpoint.c (breakpoint::locations): Adjust return type. * gdb_bfd.h (gdb_bfd_section_range): Use iterator_range. * gdbthread.h (all_threads_safe): Pass argument to all_threads_safe_range. * inferior-iter.h (all_inferiors_range): Use iterator_range. (all_inferiors_safe_range): Use iterator_range. (all_non_exited_inferiors_range): Use iterator_range. * inferior.h (all_inferiors, all_non_exited_inferiors): Pass inferior_list as argument. * objfiles.h (struct objfile) <compunits_range>: Remove. <compunits>: Return compunit_symtab_range. * progspace.h (unwrapping_objfile_iterator) <unwrapping_objfile_iterator>: Take parameter by value. (unwrapping_objfile_range): Use iterator_range. (struct program_space) <objfiles_range>: Define with "using". <objfiles>: Adjust. <objfiles_safe_range>: Define with "using". <objfiles_safe>: Adjust. <solibs>: Return so_list_range, define here. * progspace.c (program_space::solibs): Remove. * psymtab.h (class psymtab_storage) <partial_symtab_iterator>: New. <partial_symtab_range>: Use iterator_range. * solist.h (so_list_range): New. * symtab.h (compunit_symtab_range): New. (symtab_range): New. (compunit_filetabs): Change to a function. * thread-iter.h (inf_threads_range, inf_non_exited_threads_range, safe_inf_threads_range, all_threads_safe_range): Use iterator_range. * top.h (ui_range): New. (all_uis): Use ui_range. Change-Id: Ib7a9d2a3547f45f01aa1c6b24536ba159db9b854
2021-06-08gdb: try to load libthread_db only after reading all shared libraries when ↵Simon Marchi1-0/+4
attaching / handling a fork child When trying to attach to a pthread process on a Linux system with glibc 2.33, we get: $ ./gdb -q -nx --data-directory=data-directory -p 1472010 Attaching to process 1472010 [New LWP 1472013] [New LWP 1472014] [New LWP 1472015] Error while reading shared library symbols for /usr/lib/libpthread.so.0: Cannot find user-level thread for LWP 1472015: generic error 0x00007ffff6d3637f in poll () from /usr/lib/libc.so.6 (gdb) When attaching to a process (or handling a fork child, an operation very similar to attaching), GDB reads the shared library list from the process. For each shared library (if "set auto-solib-add" is on), it reads its symbols and calls the "new_objfile" observable. The libthread-db code monitors this observable, and if it sees an objfile named somewhat like "libpthread.so" go by, it tries to load libthread_db.so in the GDB process itself. libthread_db knows how to navigate libpthread's data structures to get information about the existing threads. To locate these data structures, libthread_db calls ps_pglobal_lookup (implemented in proc-service.c), passing in a symbol name and expecting an address in return. Before glibc 2.33, libthread_db always asked for symbols found in libpthread. There was no ordering problem: since we were always trying to load libthread_db in reaction to processing libpthread (and reading in its symbols) and libthread_db only asked symbols from libpthread, the requested symbols could always be found. Starting with glibc 2.33, libthread_db now asks for a symbol name that can be found in /lib/ld-linux-x86-64.so.2 (_rtld_global). And the ordering in which GDB reads the shared libraries from the inferior when attaching is unfortunate, in that libpthread is processed before ld-linux. So when loading libthread_db in reaction to processing libpthread, and libthread_db requests the symbol that is from ld-linux, GDB is not yet able to supply it. That problematic symbol lookup happens in the thread_from_lwp function, when we call td_ta_map_lwp2thr_p, and an exception is thrown at this point: #0 0x00007ffff6681012 in __cxxabiv1::__cxa_throw (obj=0x60e000006100, tinfo=0x555560033b50 <typeinfo for gdb_exception_error>, dest=0x55555d9404bc <gdb_exception_error::~gdb_exception_error()>) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_throw.cc:78 #1 0x000055555e5d3734 in throw_it(return_reason, errors, const char *, typedef __va_list_tag __va_list_tag *) (reason=RETURN_ERROR, error=GENERIC_ERROR, fmt=0x55555f0c5360 "Cannot find user-level thread for LWP %ld: %s", ap=0x7fffffffaae0) at /home/simark/src/binutils-gdb/gdbsupport/common-exceptions.cc:200 #2 0x000055555e5d37d4 in throw_verror (error=GENERIC_ERROR, fmt=0x55555f0c5360 "Cannot find user-level thread for LWP %ld: %s", ap=0x7fffffffaae0) at /home/simark/src/binutils-gdb/gdbsupport/common-exceptions.cc:208 #3 0x000055555e0b0ed2 in verror (string=0x55555f0c5360 "Cannot find user-level thread for LWP %ld: %s", args=0x7fffffffaae0) at /home/simark/src/binutils-gdb/gdb/utils.c:171 #4 0x000055555e5e898a in error (fmt=0x55555f0c5360 "Cannot find user-level thread for LWP %ld: %s") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:43 #5 0x000055555d06b4bc in thread_from_lwp (stopped=0x617000035d80, ptid=...) at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:418 #6 0x000055555d07040d in try_thread_db_load_1 (info=0x60c000011140) at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:912 #7 0x000055555d071103 in try_thread_db_load (library=0x55555f0c62a0 "libthread_db.so.1", check_auto_load_safe=false) at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:1014 #8 0x000055555d072168 in try_thread_db_load_from_sdir () at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:1091 #9 0x000055555d072d1c in thread_db_load_search () at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:1146 #10 0x000055555d07365c in thread_db_load () at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:1203 #11 0x000055555d07373e in check_for_thread_db () at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:1246 #12 0x000055555d0738ab in thread_db_new_objfile (objfile=0x61300000c0c0) at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:1275 #13 0x000055555bd10740 in std::__invoke_impl<void, void (*&)(objfile*), objfile*> (__f=@0x616000068d88: 0x55555d073745 <thread_db_new_objfile(objfile*)>) at /usr/include/c++/10.2.0/bits/invoke.h:60 #14 0x000055555bd02096 in std::__invoke_r<void, void (*&)(objfile*), objfile*> (__fn=@0x616000068d88: 0x55555d073745 <thread_db_new_objfile(objfile*)>) at /usr/include/c++/10.2.0/bits/invoke.h:153 #15 0x000055555bce0392 in std::_Function_handler<void (objfile*), void (*)(objfile*)>::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7fffffffb4a0: 0x61300000c0c0) at /usr/include/c++/10.2.0/bits/std_function.h:291 #16 0x000055555d3595c0 in std::function<void (objfile*)>::operator()(objfile*) const (this=0x616000068d88, __args#0=0x61300000c0c0) at /usr/include/c++/10.2.0/bits/std_function.h:622 #17 0x000055555d356b7f in gdb::observers::observable<objfile*>::notify (this=0x555566727020 <gdb::observers::new_objfile>, args#0=0x61300000c0c0) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/observable.h:106 #18 0x000055555da3f228 in symbol_file_add_with_addrs (abfd=0x61200001ccc0, name=0x6190000d9090 "/usr/lib/libpthread.so.0", add_flags=..., addrs=0x7fffffffbc10, flags=..., parent=0x0) at /home/simark/src/binutils-gdb/gdb/symfile.c:1131 #19 0x000055555da3f763 in symbol_file_add_from_bfd (abfd=0x61200001ccc0, name=0x6190000d9090 "/usr/lib/libpthread.so.0", add_flags=<error reading variable: Cannot access memory at address 0xffffffffffffffb0>, addrs=0x7fffffffbc10, flags=<error reading variable: Cannot access memory at address 0xffffffffffffffc0>, parent=0x0) at /home/simark/src/binutils-gdb/gdb/symfile.c:1167 #20 0x000055555d95f9fa in solib_read_symbols (so=0x6190000d8e80, flags=...) at /home/simark/src/binutils-gdb/gdb/solib.c:681 #21 0x000055555d96233d in solib_add (pattern=0x0, from_tty=0, readsyms=1) at /home/simark/src/binutils-gdb/gdb/solib.c:987 #22 0x000055555d93646e in enable_break (info=0x608000008f20, from_tty=0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2238 #23 0x000055555d93cfc0 in svr4_solib_create_inferior_hook (from_tty=0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:3049 #24 0x000055555d96610d in solib_create_inferior_hook (from_tty=0) at /home/simark/src/binutils-gdb/gdb/solib.c:1195 #25 0x000055555cdee318 in post_create_inferior (from_tty=0) at /home/simark/src/binutils-gdb/gdb/infcmd.c:318 #26 0x000055555ce00e6e in setup_inferior (from_tty=0) at /home/simark/src/binutils-gdb/gdb/infcmd.c:2439 #27 0x000055555ce59c34 in handle_one (event=...) at /home/simark/src/binutils-gdb/gdb/infrun.c:4887 #28 0x000055555ce5cd00 in stop_all_threads () at /home/simark/src/binutils-gdb/gdb/infrun.c:5064 #29 0x000055555ce7f0da in stop_waiting (ecs=0x7fffffffd170) at /home/simark/src/binutils-gdb/gdb/infrun.c:8006 #30 0x000055555ce67f5c in handle_signal_stop (ecs=0x7fffffffd170) at /home/simark/src/binutils-gdb/gdb/infrun.c:6062 #31 0x000055555ce63653 in handle_inferior_event (ecs=0x7fffffffd170) at /home/simark/src/binutils-gdb/gdb/infrun.c:5727 #32 0x000055555ce4f297 in fetch_inferior_event () at /home/simark/src/binutils-gdb/gdb/infrun.c:4105 #33 0x000055555cdbe3bf in inferior_event_handler (event_type=INF_REG_EVENT) at /home/simark/src/binutils-gdb/gdb/inf-loop.c:42 #34 0x000055555d018047 in handle_target_event (error=0, client_data=0x0) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:4060 #35 0x000055555e5ea77e in handle_file_event (file_ptr=0x60600008b1c0, ready_mask=1) at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:575 #36 0x000055555e5eb09c in gdb_wait_for_event (block=0) at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:701 #37 0x000055555e5e8d19 in gdb_do_one_event () at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:212 #38 0x000055555dd6e0d4 in wait_sync_command_done () at /home/simark/src/binutils-gdb/gdb/top.c:528 #39 0x000055555dd6e372 in maybe_wait_sync_command_done (was_sync=0) at /home/simark/src/binutils-gdb/gdb/top.c:545 #40 0x000055555d0ec7c8 in catch_command_errors (command=0x55555ce01bb8 <attach_command(char const*, int)>, arg=0x7fffffffe28d "1472010", from_tty=1, do_bp_actions=false) at /home/simark/src/binutils-gdb/gdb/main.c:452 #41 0x000055555d0f03ad in captured_main_1 (context=0x7fffffffdd10) at /home/simark/src/binutils-gdb/gdb/main.c:1149 #42 0x000055555d0f1239 in captured_main (data=0x7fffffffdd10) at /home/simark/src/binutils-gdb/gdb/main.c:1232 #43 0x000055555d0f1315 in gdb_main (args=0x7fffffffdd10) at /home/simark/src/binutils-gdb/gdb/main.c:1257 #44 0x000055555bb70cf9 in main (argc=7, argv=0x7fffffffde88) at /home/simark/src/binutils-gdb/gdb/gdb.c:32 The exception is caught here: #0 __cxxabiv1::__cxa_begin_catch (exc_obj_in=0x60e0000060e0) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_catch.cc:84 #1 0x000055555d95fded in solib_read_symbols (so=0x6190000d8e80, flags=...) at /home/simark/src/binutils-gdb/gdb/solib.c:689 #2 0x000055555d96233d in solib_add (pattern=0x0, from_tty=0, readsyms=1) at /home/simark/src/binutils-gdb/gdb/solib.c:987 #3 0x000055555d93646e in enable_break (info=0x608000008f20, from_tty=0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2238 #4 0x000055555d93cfc0 in svr4_solib_create_inferior_hook (from_tty=0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:3049 #5 0x000055555d96610d in solib_create_inferior_hook (from_tty=0) at /home/simark/src/binutils-gdb/gdb/solib.c:1195 #6 0x000055555cdee318 in post_create_inferior (from_tty=0) at /home/simark/src/binutils-gdb/gdb/infcmd.c:318 #7 0x000055555ce00e6e in setup_inferior (from_tty=0) at /home/simark/src/binutils-gdb/gdb/infcmd.c:2439 #8 0x000055555ce59c34 in handle_one (event=...) at /home/simark/src/binutils-gdb/gdb/infrun.c:4887 #9 0x000055555ce5cd00 in stop_all_threads () at /home/simark/src/binutils-gdb/gdb/infrun.c:5064 #10 0x000055555ce7f0da in stop_waiting (ecs=0x7fffffffd170) at /home/simark/src/binutils-gdb/gdb/infrun.c:8006 #11 0x000055555ce67f5c in handle_signal_stop (ecs=0x7fffffffd170) at /home/simark/src/binutils-gdb/gdb/infrun.c:6062 #12 0x000055555ce63653 in handle_inferior_event (ecs=0x7fffffffd170) at /home/simark/src/binutils-gdb/gdb/infrun.c:5727 #13 0x000055555ce4f297 in fetch_inferior_event () at /home/simark/src/binutils-gdb/gdb/infrun.c:4105 #14 0x000055555cdbe3bf in inferior_event_handler (event_type=INF_REG_EVENT) at /home/simark/src/binutils-gdb/gdb/inf-loop.c:42 #15 0x000055555d018047 in handle_target_event (error=0, client_data=0x0) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:4060 #16 0x000055555e5ea77e in handle_file_event (file_ptr=0x60600008b1c0, ready_mask=1) at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:575 #17 0x000055555e5eb09c in gdb_wait_for_event (block=0) at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:701 #18 0x000055555e5e8d19 in gdb_do_one_event () at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:212 #19 0x000055555dd6e0d4 in wait_sync_command_done () at /home/simark/src/binutils-gdb/gdb/top.c:528 #20 0x000055555dd6e372 in maybe_wait_sync_command_done (was_sync=0) at /home/simark/src/binutils-gdb/gdb/top.c:545 #21 0x000055555d0ec7c8 in catch_command_errors (command=0x55555ce01bb8 <attach_command(char const*, int)>, arg=0x7fffffffe28d "1472010", from_tty=1, do_bp_actions=false) at /home/simark/src/binutils-gdb/gdb/main.c:452 #22 0x000055555d0f03ad in captured_main_1 (context=0x7fffffffdd10) at /home/simark/src/binutils-gdb/gdb/main.c:1149 #23 0x000055555d0f1239 in captured_main (data=0x7fffffffdd10) at /home/simark/src/binutils-gdb/gdb/main.c:1232 #24 0x000055555d0f1315 in gdb_main (args=0x7fffffffdd10) at /home/simark/src/binutils-gdb/gdb/main.c:1257 #25 0x000055555bb70cf9 in main (argc=7, argv=0x7fffffffde88) at /home/simark/src/binutils-gdb/gdb/gdb.c:32 Catching the exception at this point means that the thread_db_info object for this inferior will be left in place, despite the failure to load libthread_db. This means that there won't be further attempts at loading libthread_db, because thread_db_load will think that libthread_db is already loaded for this inferior and will always exit early. To fix this, add a try/catch around calling try_thread_db_load_1 in try_thread_db_load, such that if some exception is thrown while trying to load libthread_db, we reset / delete the thread_db_info for that inferior. That alone makes attach work fine again, because check_for_thread_db is called again in the thread_db_inferior_created observer (that happens after we learned about all shared libraries and their symbols), and libthread_db is successfully loaded then. When attaching, I think that the inferior_created observer is a good place to try to load libthread_db: it is called once everything has stabilized, when we learned about all shared libraries. The only problem then is that when we first try (and fail) to load libthread_db, in reaction to learning about libpthread, we show this warning: warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. This is misleading, because we do succeed in loading it later. So when attaching, I think we shouldn't try to load libthread_db in reaction to the new_objfile events, we should wait until we have learned about all shared libraries (using the inferior_created observable). To do so, add an `in_initial_library_scan` flag to struct inferior. This flag is used to postpone loading libthread_db if we are attaching or handling a fork child. When debugging remotely with GDBserver, the same problem happens, except that the qSymbol mechanism (allowing the remote side to ask GDB for symbols values) is involved. The fix there is the same idea, we make GDB wait until all shared libraries and their symbols are known before sending out a qSymbol packet. This way, we never present the remote side a state where libpthread.so's symbols are known but ld-linux's symbols aren't. gdb/ChangeLog: * inferior.h (class inferior) <in_initial_library_scan>: New. * infcmd.c (post_create_inferior): Set in_initial_library_scan. * infrun.c (follow_fork_inferior): Likewise. * linux-thread-db.c (try_thread_db_load): Catch exception thrown by try_thread_db_load_1 (thread_db_load): Return early if in_initial_library_scan is set. * remote.c (remote_new_objfile): Return early if in_initial_library_scan is set. Change-Id: I7a279836cfbb2b362b4fde11b196b4aab82f5efb
2021-05-07gdb: some int to bool conversionAndrew Burgess1-1/+1
Change int parameter to bool in remote_notice_new_inferior (remote.c) and notice_new_inferior (infcmd.c), and update the callers. There should be no user visible changes after this commit. gdb/ChangeLog: * infcmd.c (notice_new_inferior): Change parameter type. * inferior.h (notice_new_inferior): Change parameter type. * remote.c (remote_notice_new_inferior): Change parameter type to bool. Also update type of local variable to bool. (remote_target::update_thread_list): Change type of local variable to bool. (remote_target::process_stop_reply): Pass bool instead of int to remote_notice_new_inferior.
2021-05-06gdb: make inferior::args a unique_xmalloc_ptrSimon Marchi1-1/+1
Use unique_xmalloc_ptr to avoid manual memory management. gdb/ChangeLog: * inferior.h (class inferior) <args>: Change type to unique_xmalloc_ptr. * inferior.c (inferior::~inferior): Don't free args. * infcmd.c (get_inferior_args): Adjust. (set_inferior_args): Adjust. Change-Id: I96300e59eb2faf2d80660416a8f5694d243a944e
2021-04-22gdb/continuations: turn continuation functions into inferior methodsTankut Baris Aktemur1-4/+11
Turn continuations-related functions into methods of the inferior class. This is a refactoring. gdb/ChangeLog: 2021-04-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * Makefile.in (COMMON_SFILES): Remove continuations.c. * inferior.c (inferior::add_continuation): New method, adapted from 'add_inferior_continuation'. (inferior::do_all_continuations): New method, adapted from 'do_all_inferior_continuations'. (inferior::~inferior): Clear the list of continuations directly. * inferior.h (class inferior) <continuations>: Rename into... <m_continuations>: ...this and make private. * continuations.c: Remove. * continuations.h: Remove. * event-top.c: Don't include "continuations.h". Update the users below. * inf-loop.c (inferior_event_handler) * infcmd.c (attach_command) (notice_new_inferior): Update.
2021-04-22gdb/continuations: use lambdas instead of function pointersTankut Baris Aktemur1-2/+2
Use lambdas and std::list to track inferior continuations. This is a refactoring. gdb/ChangeLog: 2021-04-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * inferior.h (class inferior) <continuations>: Change the type to be an std::list of std::function's. Update the references and uses below. * continuations.c (struct continuation): Delete. (make_continuation): Delete. (do_my_continuations_1): Delete. (do_my_continuations): Delete. (discard_my_continuations_1): Delete. (discard_my_continuations): Delete. (add_inferior_continuation): Update. (do_all_inferior_continuations): Update. (discard_all_inferior_continuations): Update. * continuations.h (add_inferior_continuation): Update to take an std::function as the parameter. * infcmd.c (struct attach_command_continuation_args): Delete. (attach_command_continuation): Delete. (attach_command_continuation_free_args): Delete. (attach_command): Update. (notice_new_inferior): Update.
2021-04-22gdb/continuations: do minor cleanupTankut Baris Aktemur1-2/+1
Inferior continuations are no longer used by the until and finish command. It is used only by the attach command and the remote target upon detecting new inferiors. Update the comment accordingly. Also update another comment about non-existent thread continuations and remove an unused #include. gdb/ChangeLog: 2021-04-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * continuations.h: Update the general comment. * inferior.h (class inferior) <continuations>: Update the comment. * interps.c: Do not include "continuations.h".
2021-03-23gdb: remove push_target free functionsSimon Marchi1-0/+7
Same as the previous patch, but for the push_target functions. The implementation of the move variant is moved to a new overload of inferior::push_target. gdb/ChangeLog: * target.h (push_target): Remove, update callers to use inferior::push_target. * target.c (push_target): Remove. * inferior.h (class inferior) <push_target>: New overload. Change-Id: I5a95496666278b8f3965e5e8aecb76f54a97c185
2021-01-01Update copyright year range in all GDB filesJoel Brobecker1-1/+1
This commits the result of running gdb/copyright.py as per our Start of New Year procedure... gdb/ChangeLog Update copyright year range in copyright header of all GDB files.
2020-12-04gdb: move displaced stepping types to displaced-stepping.{h,c}Simon Marchi1-0/+1
Move displaced-stepping related stuff unchanged to displaced-stepping.h and displaced-stepping.c. This helps make the following patch a bit smaller and easier to read. gdb/ChangeLog: * Makefile.in (COMMON_SFILES): Add displaced-stepping.c. * aarch64-tdep.h: Include displaced-stepping.h. * displaced-stepping.h (struct displaced_step_copy_insn_closure): Move here. (displaced_step_copy_insn_closure_up): Move here. (struct buf_displaced_step_copy_insn_closure): Move here. (struct displaced_step_inferior_state): Move here. (debug_displaced): Move here. (displaced_debug_printf_1): Move here. (displaced_debug_printf): Move here. * displaced-stepping.c: New file. * gdbarch.sh: Include displaced-stepping.h in gdbarch.h. * gdbarch.h: Re-generate. * inferior.h: Include displaced-stepping.h. * infrun.h (debug_displaced): Move to displaced-stepping.h. (displaced_debug_printf_1): Likewise. (displaced_debug_printf): Likewise. (struct displaced_step_copy_insn_closure): Likewise. (displaced_step_copy_insn_closure_up): Likewise. (struct buf_displaced_step_copy_insn_closure): Likewise. (struct displaced_step_inferior_state): Likewise. * infrun.c (show_debug_displaced): Move to displaced-stepping.c. (displaced_debug_printf_1): Likewise. (displaced_step_copy_insn_closure::~displaced_step_copy_insn_closure): Likewise. (_initialize_infrun): Don't register "set/show debug displaced". Change-Id: I29935f5959b80425370630a45148fc06cd4227ca