aboutsummaryrefslogtreecommitdiff
path: root/gdb/linux-nat.c
AgeCommit message (Collapse)AuthorFilesLines
2022-07-22Change target_ops::async to accept boolTom Tromey1-3/+3
This changes the parameter of target_ops::async from int to bool. Regression tested on x86-64 Fedora 34.
2022-06-28gdb+gdbserver/Linux: avoid reading registers while going through shellPedro Alves1-0/+4
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-05-26gdb/linux-nat: xfer_memory_partial return E_IO on errorLancelot SIX1-1/+1
When accessing /proc/PID/mem, if pread64/pwrite64/read/write encounters an error and return -1, linux_proc_xfer_memory_partial return TARGET_XFER_EOF. I think it should return TARGET_XFER_E_IO in this case. TARGET_XFER_EOF is returned when pread64/pwrite64/read/frite returns 0, which indicates that the address space is gone and the whole process has exited or execed. This patch makes this change. Regression tested on x86_64-linux-gnu. Change-Id: I6030412459663b8d7933483fdda22a6c2c5d7221
2022-05-13Constify target_pid_to_exec_fileTom Tromey1-1/+1
This changes target_pid_to_exec_file and target_ops::pid_to_exec_file to return a "const char *". I couldn't build many of these targets, but did examine the code by hand -- also, as this only affects the return type, it's normally pretty safe. This brings gdb and gdbserver a bit closer, and allows for the removal of a const_cast as well.
2022-04-29Slightly tweak and clarify target_resume's interfacePedro Alves1-19/+10
The current target_resume interface is a bit odd & non-intuitive. I've found myself explaining it a couple times the recent past, while reviewing patches that assumed STEP/SIGNAL always applied to the passed in PTID. It goes like this today: - if the passed in PTID is a thread, then the step/signal request is for that thread. - otherwise, if PTID is a wildcard (all threads or all threads of process), the step/signal request is for inferior_ptid, and PTID indicates which set of threads run free. Because GDB always switches the current thread to "leader" thread being resumed/stepped/signalled, we can simplify this a bit to: - step/signal are always for inferior_ptid. - PTID indicates the set of threads that run free. Still not ideal, but it's a minimal change and at least there are no special cases this way. That's what this patch does. It renames the PTID parameter to SCOPE_PTID, adds some assertions to target_resume, and tweaks target_resume's description. In addition, it also renames PTID to SCOPE_PTID in the remote and linux-nat targets, and simplifies their implementation a little bit. Other targets could do the same, but they don't have to. Change-Id: I02a2ec2ab3a3e9b191de1e9a84f55c17cab7daaf
2022-03-31gdb/linux-nat: remove check based on current_inferior in ↵Simon Marchi1-13/+4
linux_handle_extended_wait The check removed by this patch, using current_inferior, looks wrong. When debugging multiple inferiors with the Linux native target and linux_handle_extended_wait is called, there's no guarantee about which is the current inferior. The vfork-done event we receive could be for any inferior. If the vfork-done event is for a non-current inferior, we end up wrongfully ignoring it. As a result, the core never processes a TARGET_WAITKIND_VFORK_DONE event, program_space::breakpoints_not_allowed is never cleared, and breakpoints are never reinserted. However, because the Linux native target decided to ignore the event, it resumed the thread - while breakpoints out. And that's bad. The proposed fix is to remove this check. Always report vfork-done events and let infrun's logic decide if it should be ignored. We don't save much cycles by filtering the event here. Add a test that replicates the situation described above. See comments in the test for more details. Change-Id: Ibe33c1716c3602e847be6c2093120696f2286fbf
2022-03-29Unify gdb printf functionsTom Tromey1-4/+4
Now that filtered and unfiltered output can be treated identically, we can unify the printf family of functions. This is done under the name "gdb_printf". Most of this patch was written by script.
2022-03-29Remove some uses of printf_unfilteredTom Tromey1-2/+2
A number of spots call printf_unfiltered only because they are in code that should not be interrupted by the pager. However, I believe these cases are all handled by infrun's blanket ban on paging, and so can be converted to the default (_filtered) API. After this patch, I think all the remaining _unfiltered calls are ones that really ought to be. A few -- namely in complete_command -- could be replaced by a scoped assignment to pagination_enabled, but for the remainder, the code seems simple enough like this.
2022-03-10Re-add zombie leader on exit, gdb/linuxPedro Alves1-27/+80
The current zombie leader detection code in linux-nat.c has a race -- if a multi-threaded inferior exits just before check_zombie_leaders finds that the leader is now zombie via checking /proc/PID/status, check_zombie_leaders deletes the leader, assuming we won't get an event for that exit (which we won't in some scenarios, but not in this one). That might seem mostly harmless, but it has some downsides: - later when we continue pulling events out of the kernel, we will collect the exit event of the non-leader threads, and once we see the last lwp in our list exit, we return _that_ lwp's exit code as whole-process exit code to infrun, instead of the leader's exit code. - this can cause a hang in stop_all_threads in infrun.c. Say there are 2 threads in the process. stop_all_threads stops each of those threads, and then waits for two stop or exit events, one for each thread. If the whole process exits, and check_zombie_leaders hits the false-positive case, linux-nat.c will only return one event to GDB (the whole-process exit returned when we see the last thread, the non-leader thread, exit), making stop_all_threads hang forever waiting for a second event that will never come. However, in this false-positive scenario, where the whole process is exiting, as opposed to just the leader (with pthread_exit(), for example), we _will_ get an exit event shortly for the leader, after we collect the exit event of all the other non-leader threads. Or put another way, we _always_ get an event for the leader after we see it become zombie. I tried a number of approaches to fix this: #1 - My first thought to address the race was to make GDB always report the whole-process exit status for the leader thread, not for whatever is the last lwp in the list. We _always_ get a final exit (or exec) event for the leader, and when the race triggers, we're not collecting it. #2 - My second thought was to try to plug the race in the first place. I thought of making GDB call waitpid/WNOHANG for all non-leader threads immediately when the zombie leader is detected, assuming there would be an exit event pending for each of them waiting to be collected. Turns out that that doesn't work -- you can see the leader become zombie _before_ the kernel kills all other threads. Waitpid in that small time window returns 0, indicating no-event. Thankfully we hit that race window all the time, which avoided trading one race for another. Looking at the non-leader thread's status in /proc doesn't help either, the threads are still in running state for a bit, for the same reason. #3 - My next attempt, which seemed promising, was to synchronously stop and wait for the stop for each of the non-leader threads. For the scenario in question, this will collect all the exit statuses of the non-leader threads. Then, if we are left with only the zombie leader in the lwp list, it means we either have a normal while-process exit or an exec, in which case we should not delete the leader. If _only_ the leader exited, like in gdb.threads/leader-exit.exp, then after pausing threads, we will still have at least one live non-leader thread in the list, and so we delete the leader lwp. I got this working and polished, and it was only after staring at the kernel code to convince myself that this would really work (and it would, for the scenario I considered), that I realized I had failed to account for one scenario -- if any non-leader thread is _already_ stopped when some thread triggers a group exit, like e.g., if you have some threads stopped and then resume just one thread with scheduler-locking or non-stop, and that thread exits the process. I also played with PTRACE_EVENT_EXIT, see if it would help in any way to plug the race, and I couldn't find a way that it would result in any practical difference compared to looking at /proc/PID/status, with respect to having a race. So I concluded that there's no way to plug the race, we just have to deal with it. Which means, going back to approach #1. That is the approach taken by this patch. Change-Id: I6309fd4727da8c67951f9cea557724b77e8ee979
2022-03-10gdb: Reorganize linux_nat_filter_eventPedro Alves1-35/+40
Reorganize linux-nat.c:linux_nat_filter_event such that all the handling for events for LWPs not in the LWP list is together. This helps make a following patch clearer. The comments and debug messages have also been tweaked - the end goal is to have them synchronized with the gdbserver counterpart. Change-Id: I8586d8dcd76d8bd3795145e3056fc660e3b2cd22
2022-02-22inf-ptrace: Add an event_pipe to be used for async mode in subclasses.John Baldwin1-99/+24
Subclasses of inf_ptrace_target have to opt-in to using the event_pipe by implementing the can_async_p and async methods. For subclasses which do this, inf_ptrace_target provides is_async_p, async_wait_fd and closes the pipe in the close target method. inf_ptrace_target also provides wrapper routines around the event pipe (async_file_open, async_file_close, async_file_flush, and async_file_mark) for use in target methods such as async. inf_ptrace_target also exports a static async_file_mark_if_open function which can be used in SIGCHLD signal handlers.
2022-02-22Enable async mode in the target in attach_cmd.John Baldwin1-3/+0
If the attach target supports async mode, enable it after the attach target's ::attach method returns.
2022-02-22Don't enable async mode at the end of target ::resume methods.John Baldwin1-3/+0
Now that target_resume always enables async mode after target::resume returns, these calls are redundant. The other place that target resume methods are invoked outside of target_resume are as the beneath target in record_full_wait_1. In this case, async mode should already be enabled when supported by the target before the resume method is invoked due to the following: In general, targets which support async mode run as async until ::wait returns TARGET_WAITKIND_NO_RESUMED to indicate that there are no unwaited for children (either they have exited or are stopped). When that occurs, the loop in wait_one disables async mode. Later if a stopped child is resumed, async mode is re-enabled in do_target_resume before waiting for the next event. In the case of record_full_wait_1, this function is invoked from the ::wait target method when fetching an event. If the underlying target supports async mode, then an earlier call to do_target_resume to resume the child reporting an event in the loop in record_full_wait_1 would have already enabled async mode before ::wait was invoked. In addition, nothing in the code executed in the loop in record_full_wait_1 disables async mode. Async mode is only disabled higher in the call stack in wait_one after ::wait returns. It is also true that async mode can be disabled by an INF_EXEC_COMPLETE event passed to inferior_event_handle, but all of the places that invoke that are in the gdb core which is "above" a target ::wait method. Note that there is an earlier call to enable async mode in linux_nat_target::resume. That call also marks the async event pipe to report an existing event after enabling async mode, so it needs to stay.
2022-02-22gdb linux-nat: Convert linux_nat_event_pipe to the event_pipe class.John Baldwin1-43/+16
Use event_pipe from gdbsupport in place of the existing file descriptor array.
2022-02-18gdb: remove newlines from some linux_nat_debug_printf callsSimon Marchi1-3/+3
Change-Id: I80328fab7096221356864b5a4fb30858b48d2c10
2022-02-10gdb/linux: remove ptrace support check for exec, fork, vfork, vforkdone, ↵Simon Marchi1-69/+8
clone, sysgood I think it's safe to remove checking support for these ptrace features, they have all been added in what is now ancient times (around the beginning of Linux 2.6). This allows removing a bit of complexity in linux-nat.c and nat/linux-ptrace.c. It also allows saving one extra fork every time we start debugging on Linux: linux_check_ptrace_features forks a child process to test if some ptrace features are supported. That child process forks a grand-child, to test whether ptrace reports an event for the fork by the child. This is no longer needed, if we assume the kernel supports reporting forks. PTRACE_O_TRACEVFORKDONE was introduced in Linux in this change, in 2003: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=45c1a159b85b3b30afd26a77b4be312226bba416 PTRACE_O_TRACESYSGOOD was supported at least as of this change, in 2002: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=acc7088569c8eef04eeed0eff51d23bb5bcff964 PTRACE_O_TRACEFORK, PTRACE_O_TRACEVFORK, PTRACE_O_TRACEEXEC and PTRACE_O_TRACECLONE were introduced in this change, in 2002: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=a0691b116f6a4473f0fa264210ab9b95771a2b46 Change-Id: Iffb906549a89cc6b619427f976ec044706ab1e8d
2022-01-18gdb: use ptid_t::to_string instead of target_pid_to_str in debug statementsSimon Marchi1-46/+46
Same idea as 0fab79556484 ("gdb: use ptid_t::to_string in infrun debug messages"), but throughout GDB. Change-Id: I62ba36eaef29935316d7187b9b13d7b88491acc1
2022-01-12gdb: rename lin-lwp to linux-nat in set/show debugAndrew Burgess1-3/+3
Rename 'set debug lin-lwp' to 'set debug linux-nat' and 'show debug lin-lwp' to 'show debug linux-nat'. I've updated the documentation and help text to match, as well as making it clear that the debug that is coming out relates to all aspects of Linux native inferior support, not just the LWP aspect of it. The boundary between general "native" target debug, and the lwp specific part of that debug was always a little blurry, but the actual debug variable inside GDB is debug_linux_nat, and the print routine linux_nat_debug_printf, is used throughout the linux-nat.c file, not just for lwp related debug, so the new name seems to make more sense.
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-12-22gdb: convert 'set debug lin-lwp' to a boolean commandAndrew Burgess1-9/+20
Convert the 'set debug lin-lwp' command to a boolean. Adds a new LINUX_NAT_SCOPED_DEBUG_ENTER_EXIT macro, and makes use of it in one place (linux_nat_target::stop). The manual entry for 'set debug lin-lwp' is already vague about exactly what arguments this command takes, and the description talks about turning debug on and off, so I don't think there's any updates required there. I have updated the doc strings shown when the users enters 'help show debug lin-lwp' or 'help show debug lin-lwp'. The old title lines used to talk about the 'GNU/Linux lwp module', but this debug flag is now used for any native linux target debug, so we now talk about 'GNU/Linux native target'. The body string for this setting has been changed from 'Enables printf debugging output.' to 'When on, print debug messages relating to the GNU/Linux native target.', the old value looks like a cut&paste error to me.
2021-12-13gdb: make post_startup_inferior a virtual method on inf_ptrace_targetAndrew Burgess1-0/+2
While working on a later patch that required me to understand how GDB starts up inferiors, I was confused by the target_ops::post_startup_inferior method. The post_startup_inferior target function is only called from inf_ptrace_target::create_inferior. Part of the target class hierarchy looks like this: inf_child_target | '-- inf_ptrace_target | |-- linux_nat_target | |-- fbsd_nat_target | |-- nbsd_nat_target | |-- obsd_nat_target | '-- rs6000_nat_target Every sub-class of inf_ptrace_target, except rs6000_nat_target, implements ::post_startup_inferior. The rs6000_nat_target picks up the implementation of ::post_startup_inferior not from inf_ptrace_target, but from inf_child_target. No descendent of inf_child_target, outside the inf_ptrace_target sub-tree, implements ::post_startup_inferior, which isn't really surprising, as they would never see the method called (remember, the method is only called from inf_ptrace_target::create_inferior). What I find confusing is the role inf_child_target plays in implementing, what is really a helper function for just one of its descendents. In this commit I propose that we formally make ::post_startup_inferior a helper function of inf_ptrace_target. To do this I will remove the ::post_startup_inferior from the target_ops API, and instead make this a protected, pure virtual function on inf_ptrace_target. I'll remove the empty implementation of ::post_startup_inferior from the inf_child_target class, and add a new empty implementation to the rs6000_nat_target class. All the other descendents of inf_ptrace_target already provide an implementation of this method and so don't need to change beyond making the method protected within their class declarations. To me, this makes much more sense now. The helper function, which is only called from within the inf_ptrace_target class, is now a part of the inf_ptrace_target class. The only way in which this change is visible to a user is if the user turns on 'set debug target 1'. With this debug flag on, prior to this patch the user would see something like: -> native->post_startup_inferior (...) <- native->post_startup_inferior (2588939) After this patch these lines are no longer present, as the post_startup_inferior is no longer a top level target method. For me, this is an acceptable change.
2021-12-08gdb, gdbserver: detach fork child when detaching from fork parentSimon Marchi1-1/+52
While working with pending fork events, I wondered what would happen if the user detached an inferior while a thread of that inferior had a pending fork event. What happens with the fork child, which is ptrace-attached by the GDB process (or by GDBserver), but not known to the core? Sure enough, neither the core of GDB or the target detach the child process, so GDB (or GDBserver) just stays ptrace-attached to the process. The result is that the fork child process is stuck, while you would expect it to be detached and run. Make GDBserver detach of fork children it knows about. That is done in the generic handle_detach function. Since a process_info already exists for the child, we can simply call detach_inferior on it. GDB-side, make the linux-nat and remote targets detach of fork children known because of pending fork events. These pending fork events can be stored in: - thread_info::pending_waitstatus, if the core has consumed the event but then saved it for later (for example, because it got the event while stopping all threads, to present an all-stop stop on top of a non-stop target) - thread_info::pending_follow: if we ran to a "catch fork" and we detach at that moment Additionally, pending fork events can be in target-specific fields: - For linux-nat, they can be in lwp_info::status and lwp_info::waitstatus. - For the remote target, they could be stored as pending stop replies, saved in `remote_state::notif_state::pending_event`, if not acknowledged yet, or in `remote_state::stop_reply_queue`, if acknowledged. I followed the model of remove_new_fork_children for this: call remote_notif_get_pending_events to process / acknowledge any unacknowledged notification, then look through stop_reply_queue. Update the gdb.threads/pending-fork-event.exp test (and rename it to gdb.threads/pending-fork-event-detach.exp) to try to detach the process while it is stopped with a pending fork event. In order to verify that the fork child process is correctly detached and resumes execution outside of GDB's control, make that process create a file in the test output directory, and make the test wait $timeout seconds for that file to appear (it happens instantly if everything goes well). This test catches a bug in linux-nat.c, also reported as PR 28512 ("waitstatus.h:300: internal-error: gdb_signal target_waitstatus::sig() const: Assertion `m_kind == TARGET_WAITKIND_STOPPED || m_kind == TARGET_WAITKIND_SIGNALLED' failed.). When detaching a thread with a pending event, get_detach_signal unconditionally fetches the signal stored in the waitstatus (`tp->pending_waitstatus ().sig ()`). However, that is only valid if the pending event is of type TARGET_WAITKIND_STOPPED, and this is now enforced using assertions (iit would also be valid for TARGET_WAITKIND_SIGNALLED, but that would mean the thread does not exist anymore, so we wouldn't be detaching it). Add a condition in get_detach_signal to access the signal number only if the wait status is of kind TARGET_WAITKIND_STOPPED, and use GDB_SIGNAL_0 instead (since the thread was not stopped with a signal to begin with). Add another test, gdb.threads/pending-fork-event-ns.exp, specifically to verify that we consider events in pending stop replies in the remote target. This test has many threads constantly forking, and we detach from the program while the program is executing. That gives us some chance that we detach while a fork stop reply is stored in the remote target. To verify that we correctly detach all fork children, we ask the parent to exit by sending it a SIGUSR1 signal and have it write a file to the filesystem before exiting. Because the parent's main thread joins the forking threads, and the forking threads wait for their fork children to exit, if some fork child is not detach by GDB, the parent will not write the file, and the test will time out. If I remove the new remote_detach_pid calls in remote.c, the test fails eventually if I run it in a loop. There is a known limitation: we don't remove breakpoints from the children before detaching it. So the children, could hit a trap instruction after being detached and crash. I know this is wrong, and it should be fixed, but I would like to handle that later. The current patch doesn't fix everything, but it's a step in the right direction. Change-Id: I6d811a56f520e3cb92d5ea563ad38976f92e93dd Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28512
2021-12-08gdb/linux-nat: factor ptrace-detach code to new detach_one_pid functionSimon Marchi1-36/+40
The following patch will add some code paths that need to ptrace-detach a given PID. Factor out the code that does this and put it in its own function, so that it can be re-used. Change-Id: Ie65ca0d89893b41aea0a23d9fc6ffbed042a9705
2021-12-03gdb: change store_waitstatus to return a target_waitstatus by valueSimon Marchi1-3/+3
store_waitstatus is basically a translation function between a status integer and an equivalent target_waitstatus object. It would make sense for it to take the integer as a parameter and return the target_waitstatus by value. Do that, and rename to host_status_to_waitstatus. Users can then do: ws = host_status_to_waitstatus (status) which does the right thing, given the move constructor of target_waitstatus. Change-Id: I7a07d59d3dc19d3ed66929642f82f44f3e85d61b
2021-11-25gdb: hoist target_async_permitted checks into target.cAndrew Burgess1-3/+5
This commit moves the target_async_permitted check out of each targets ::can_async_p method and into the target_can_async_p wrapper function. I've left some asserts in the two ::can_async_p methods that I changed, which will hopefully catch any direct calls to these methods that might be added in the future. There should be no user visible changes after this commit.
2021-11-05Avoid /proc/pid/mem races (PR 28065)Pedro Alves1-185/+139
PR 28065 (gdb.threads/access-mem-running-thread-exit.exp intermittent failure) shows that GDB can hit an unexpected scenario -- it can happen that the kernel manages to open a /proc/PID/task/LWP/mem file, but then reading from the file returns 0/EOF, even though the process hasn't exited or execed. "0" out of read/write is normally what you get when the address space of the process the file was open for is gone, because the process execed or exited. So when GDB gets the 0, it returns memory access failure. In the bad case in question, the process hasn't execed or exited, so GDB fails a memory access when the access should have worked. GDB has code in place to gracefully handle the case of opening the /proc/PID/task/LWP/mem just while the LWP is exiting -- most often the open fails with EACCES or ENOENT. When it happens, GDB just tries opening the file for a different thread of the process. The testcase is written such that it stresses GDB's logic of closing/reopening the /proc/PID/task/LWP/mem file, by constantly spawning short lived threads. However, there's a window where the kernel manages to find the thread, but the thread exits just after and clears its address space pointer. In this case, the kernel creates a file successfully, but the file ends up with no address space associated, so a subsequent read/write returns 0/EOF too, just like if the whole process had execed or exited. This is the case in question that GDB does not handle. Oleg Nesterov gave this suggestion as workaround for that race: gdb can open(/proc/pid/mem) and then read (say) /proc/pid/statm. If statm reports something non-zero, then open() was "successfull". I think that might work. However, I didn't try it, because I realized we have another nasty race that that wouldn't fix. The other race I realized is that because we close/reopen the /proc/PID/task/LWP/mem file when GDB switches to a different inferior, then it can happen that GDB reopens /proc/PID/task/LWP/mem just after a thread execs, and before GDB has seen the corresponding exec event. I.e., we can open a /proc/PID/task/LWP/mem file accessing the post-exec address space thinking we're accessing the pre-exec address space. A few months back, Simon, Oleg and I discussed a similar race: [Bug gdb/26754] Race condition when resuming threads and one does an exec https://sourceware.org/bugzilla/show_bug.cgi?id=26754 The solution back then was to make the kernel fail any ptrace operation until the exec event is consumed, with this kernel commit: commit dbb5afad100a828c97e012c6106566d99f041db6 Author: Oleg Nesterov <oleg@redhat.com> AuthorDate: Wed May 12 15:33:08 2021 +0200 Commit: Linus Torvalds <torvalds@linux-foundation.org> CommitDate: Wed May 12 10:45:22 2021 -0700 ptrace: make ptrace() fail if the tracee changed its pid unexpectedly This however, only applies to ptrace, not to the /proc/pid/mem file opening case. Also, even if it did apply to the file open case, we would want to support current kernels until such a fix is more wide spread anyhow. So all in all, this commit gives up on the idea of only ever keeping one /proc/pid/mem file descriptor open. Instead, make GDB open a /proc/pid/mem per inferior, and keep it open until the inferior exits, is detached or execs. Make GDB open the file right after the inferior is created or is attached to or forks, at which point we know the inferior is stable and stopped and isn't thus going to exec, or have a thread exit, and so the file open won't fail (unless the whole process is SIGKILLed from outside GDB, at which point it doesn't matter whether we open the file). This way, we avoid both races described above, at the expense of using more file descriptors (one per inferior). Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28065 Change-Id: Iff943b95126d0f98a7973a07e989e4f020c29419
2021-10-21gdb, gdbserver: make target_waitstatus safeSimon Marchi1-33/+36
I stumbled on a bug caused by the fact that a code path read target_waitstatus::value::sig (expecting it to contain a gdb_signal value) while target_waitstatus::kind was TARGET_WAITKIND_FORKED. This meant that the active union field was in fact target_waitstatus::value::related_pid, and contained a ptid. The read signal value was therefore garbage, and that caused GDB to crash soon after. Or, since that GDB was built with ubsan, this nice error message: /home/simark/src/binutils-gdb/gdb/linux-nat.c:1271:12: runtime error: load of value 2686365, which is not a valid value for type 'gdb_signal' Despite being a large-ish change, I think it would be nice to make target_waitstatus safe against that kind of bug. As already done elsewhere (e.g. dynamic_prop), validate that the type of value read from the union matches what is supposed to be the active field. - Make the kind and value of target_waitstatus private. - Make the kind initialized to TARGET_WAITKIND_IGNORE on target_waitstatus construction. This is what most users appear to do explicitly. - Add setters, one for each kind. Each setter takes as a parameter the data associated to that kind, if any. This makes it impossible to forget to attach the associated data. - Add getters, one for each associated data type. Each getter validates that the data type fetched by the user matches the wait status kind. - Change "integer" to "exit_status", "related_pid" to "child_ptid", just because that's more precise terminology. - Fix all users. That last point is semi-mechanical. There are a lot of obvious changes, but some less obvious ones. For example, it's not possible to set the kind at some point and the associated data later, as some users did. But in any case, the intent of the code should not change in this patch. This was tested on x86-64 Linux (unix, native-gdbserver and native-extended-gdbserver boards). It was built-tested on x86-64 FreeBSD, NetBSD, MinGW and macOS. The rest of the changes to native files was done as a best effort. If I forgot any place to update in these files, it should be easy to fix (unless the change happens to reveal an actual bug). Change-Id: I0ae967df1ff6e28de78abbe3ac9b4b2ff4ad03b7
2021-09-30gdbsupport: make gdb_open_cloexec return scoped_fdSimon Marchi1-1/+1
Make gdb_open_cloexec return a scoped_fd, to encourage using automatic management of the file descriptor closing. Except in the most trivial cases, I changed the callers to just release the fd, which retains their existing behavior. That will allow the transition to using scoped_fd more to go gradually, one caller at a time. Change-Id: Ife022b403f96e71d5ebb4f1056ef6251b30fe554
2021-09-27gdb: use intrusive_list for linux-nat lwp_listSimon Marchi1-22/+24
Replace the manually maintained linked list of lwp_info objects with intrusive_list. Replace the ALL_LWPS macro with all_lwps, which returns a range. Add all_lwps_safe as well, for use in iterate_over_lwps, which currently iterates in a safe manner. Change-Id: I355313502510acc0103f5eaf2fbde80897d6376c
2021-09-27gdb: add destructor to lwp_infoSimon Marchi1-7/+4
Replace the lwp_free function with a destructor. Make lwp_info non-copyable, since there is now a destructor (we wouldn't want an lwp_info object getting copied and this->arch_private getting deleted twice). Change-Id: I09fcbe967e362566d3a06fed2abca2a9955570fa
2021-09-27gdb: make lwp_info non-PODSimon Marchi1-21/+6
Initialize all fields in the class declaration directly. This opens the door to using intrusive_list, done in the following patch. Change-Id: I38bb27410cd9ebf511d310bb86fe2ea1872c3b05
2021-09-23Remove defaulted 'tid' parameter to ptid_t constructorTom Tromey1-8/+7
I wanted to find, and potentially modify, all the spots where the 'tid' parameter to the ptid_t constructor was used. So, I temporarily removed this parameter and then rebuilt. In order to make it simpler to search through the "real" (nonzero) uses of this parameter, something I knew I'd have to do multiple times, I removed any ", 0" from constructor calls. Co-Authored-By: John Baldwin <jhb@FreeBSD.org>
2021-09-07gdb: make thread_info::executing privateAndrew Burgess1-1/+1
Rename thread_info::executing to thread_info::m_executing, and make it private. Add a new get/set member functions, and convert GDB to make use of these. The only real change of interest in this patch is in thread.c where I have deleted the helper function set_executing_thread, and now just use the new set function thread_info::set_executing. However, the old helper function set_executing_thread included some code to reset the thread's stop_pc, so I moved this code into the new function thread_info::set_executing. However, I don't believe there is anywhere that this results in a change of behaviour, previously the executing flag was always set true through a call to set_executing_thread anyway.
2021-08-26gdb: remove some stray newlines in debug outputAndrew Burgess1-2/+2
I spotted a couple of stray newlines that were left at the end of debug message during conversion to the new debug output scheme. These messages are part of the 'set debug lin-lwp 1' output.
2021-08-03gdb: follow-fork: push target and add thread in target_follow_forkSimon Marchi1-7/+8
In the context of ROCm-gdb [1], the ROCm target sits on top of the linux-nat target. when a process forks, it needs to carry over some data from the forking inferior to the fork child inferior. Ideally, the ROCm target would implement the follow_fork target_ops method, but there are some small problems. This patch fixes these, which helps the ROCm target, but also makes things more consistent and a bit nicer in general, I believe. The main problem is: when follow-fork-mode is "parent", target_follow_fork is called with the parent as the current inferior. When it's "child", target_follow_fork is called with the child as the current inferior. This means that target_follow_fork is sometimes called on the parent's target stack and sometimes on the child's target stack. The parent's target stack may contain targets above the process target, such as the ROCm target. So if follow-fork-child is "parent", the ROCm target would get notified of the fork and do whatever is needed. But the child's target stack, at that moment, only contains the exec and process target copied over from the parent. The child's target stack is set up by follow_fork_inferior, before calling target_follow_fork. In that case, the ROCm target wouldn't get notified of the fork. For consistency, I think it would be good to always call target_follow_fork on the parent inferior's target stack. I think it makes sense as a way to indicate "this inferior has called fork, do whatever is needed". The desired outcome of the fork (whether an inferior is created for the child, do we need to detach from the child) can be indicated by passed parameter. I therefore propose these changes: - make follow_fork_inferior always call target_follow_fork with the parent as the current inferior. That lets all targets present on the parent's target stack do some fork-related handling and push themselves on the fork child's target stack if needed. For this purpose, pass the child inferior down to target_follow_fork and follow_fork implementations. This is nullptr if no inferior is created for the child, because we want to detach from it. - as a result, in follow_fork_inferior, detach from the parent inferior (if needed) only after the target_follow_fork call. This is needed because we want to call target_follow_fork before the parent's target stack is torn down. - hand over to the targets in the parent's target stack (including the process target) the responsibility to push themselves, if needed, to the child's target stack. Also hand over the responsibility to the process target, at the same time, to create the child's initial thread (just like we do for follow_exec). - pass the child inferior to exec_on_vfork, so we don't need to swap the current inferior between parent and child. Nothing in exec_on_vfork depends on the current inferior, after this change. Although this could perhaps be replaced with just having the exec target implement follow_fork and push itself in the child's target stack, like the process target does... We would just need to make sure the process target calls beneath()->follow_fork(...). I'm not sure about this one. gdb/ChangeLog: * target.h (struct target_ops) <follow_fork>: Add inferior* parameter. (target_follow_fork): Likewise. * target.c (default_follow_fork): Likewise. (target_follow_fork): Likewise. * fbsd-nat.h (class fbsd_nat_target) <follow_fork>: Likewise. (fbsd_nat_target::follow_fork): Likewise, and call inf_ptrace_target::follow_fork. * linux-nat.h (class linux_nat_target) <follow_fork>: Likewise. * linux-nat.c (linux_nat_target::follow_fork): Likewise, and call inf_ptrace_target::follow_fork. * obsd-nat.h (obsd_nat_target) <follow_fork>: Likewise. * obsd-nat.c (obsd_nat_target::follow_fork): Likewise, and call inf_ptrace_target::follow_fork. * remote.c (class remote_target) <follow_fork>: Likewise. (remote_target::follow_fork): Likewise, and call process_stratum_target::follow_fork. * process-stratum-target.h (class process_stratum_target) <follow_fork>: New. * process-stratum-target.c (process_stratum_target::follow_fork): New. * target-delegates.c: Re-generate. [1] https://github.com/ROCm-Developer-Tools/ROCgdb Change-Id: I460bd0af850f0485e8aed4b24c6d8262a4c69929
2021-07-14gdb: pass child_ptid and fork kind to target_ops::follow_forkSimon Marchi1-12/+7
This is a small cleanup I think would be nice, that I spotted while doing the following patch. gdb/ChangeLog: * target.h (struct target_ops) <follow_fork>: Add ptid and target_waitkind parameters. (target_follow_fork): Likewise. * target.c (default_follow_fork): Likewise. (target_follow_fork): Likewise. * fbsd-nat.h (class fbsd_nat_target) <follow_fork>: Likewise. * fbsd-nat.c (fbsd_nat_target::follow_fork): Likewise. * linux-nat.h (class linux_nat_target) <follow_fork>: Likewise. * linux-nat.c (linux_nat_target::follow_fork): Likewise. * obsd-nat.h (class obsd_nat_target) <follow_fork>: Likewise. * obsd-nat.c (obsd_nat_target::follow_fork): Likewise. * remote.c (class remote_target) <follow_fork>: Likewise. * target-debug.h (target_debug_print_target_waitkind): New. * target-delegates.c: Re-generate. Change-Id: I5421a542f2e19100a22b74cc333d2b235d0de3c8
2021-07-14gdb: call post_create_inferior at end of follow_fork_inferiorSimon Marchi1-15/+0
GDB doesn't handle well the case of an inferior using the JIT interface to register JIT-ed objfiles and forking. If an inferior registers a code object using the JIT interface and then forks, the child process conceptually has the same code object loaded, so GDB should look it up and learn about it (it currently doesn't). To achieve this, I think it would make sense to have the inferior_created observable called when an inferior is created due to a fork in follow_fork_inferior. The inferior_created observable is currently called both after starting a new inferior and after attaching to an inferior, allowing various sub-components to learn about that new executing inferior. We can see handling a fork child just like attaching to it, so any work done when attaching should also be done in the case of a fork child. Instead of just calling the inferior_created observable, this patch makes follow_fork_inferior call the whole post_create_inferior function. This way, the attach and follow-fork code code paths are more alike. Given that post_create_inferior calls solib_create_inferior_hook, follow_fork_inferior doesn't need to do it itself, so those calls to solib_create_inferior_hook are removed. One question you may have: why not just call post_create_inferior at the places where solib_create_inferior_hook is currently called, instead of after target_follow_fork? - there's something fishy for the second solib_create_inferior_hook call site: at this point we have switched the current program space to the child's, but not the current inferior nor the current thread. So solib_create_inferior_hook (and everything under, including check_for_thread_db, for example) is called with inferior 1 as the current inferior and inferior 2's program space as the current program space. I think that's wrong, because at this point we are setting up inferior 2, and all that code relies on the current inferior. We could just add a switch_to_thread call before it to make inferior 2 the current one, but there are other problems (see below). - solib_create_inferior_hook is currently not called on the `follow_child && detach_fork` path. I think we need to call it, because we still get a new inferior in that case (even though we detach the parent). If we only call post_create_inferior where solib_create_inferior_hook used to be called, then the JIT subcomponent doesn't get informed about the new inferior, and that introduces a failure in the new gdb.base/jit-elf-fork.exp test. - if we try to put the post_create_inferior just after the switch_to_thread that was originally at line 662, or just before the call to target_follow_fork, we introduce a subtle failure in gdb.threads/fork-thread-pending.exp. What happens then is that libthread_db gets loaded (somewhere under post_create_inferior) before the linux-nat target learns about the LWPs (which happens in linux_nat_target::follow_fork). As a result, the ALL_LWPS loop in try_thread_db_load_1 doesn't see the child LWP, and the thread-db target doesn't have the chance to fill in thread_info::priv. A bit later, when the test does "info threads", and thread_db_target::pid_to_str is called, the thread-db target doesn't recognize the thread as one of its own, and delegates the request to the target below. Because the pid_to_str output is not the expected one, the test fails. This tells me that we need to call the process target's follow_fork first, to make the process target create the necessary LWP and thread structures. Then, we can call post_create_inferior to let the other components of GDB do their thing. But then you may ask: check_for_thread_db is already called today, somewhere under solib_create_inferior_hook, and that is before target_follow_fork, why don't we see this ordering problem!? Well, because of the first bullet point: when check_for_thread_db / thread_db_load are called, the current inferior is (erroneously) inferior 1, the parent. Because libthread_db is already loaded for the parent, thread_db_load early returns. check_for_thread_db later gets called by linux_nat_target::follow_fork. At this point, the current inferior is the correct one and the child's LWP exists, so all is well. Since we now call post_create_inferior after target_follow_fork, which calls the inferior_created observable, which calls check_for_thread_db, I don't think linux_nat_target needs to explicitly call check_for_thread_db itself, so that is removed. In terms of testing, this patch adds a new gdb.base/jit-elf-fork.exp test. It makes an inferior register a JIT code object and then fork. It then verifies that whatever the detach-on-fork and follow-fork-child parameters are, GDB knows about the JIT code object in all the inferiors that survive the fork. It verifies that the inferiors can unload that code object. There isn't currently a way to get visibility into GDB's idea of the JIT code objects for each inferior. For the purpose of this test, add the "maintenance info jit" command. There isn't much we can print about the JIT code objects except their load address. So the output looks a bit bare, but it's good enough for the test. gdb/ChangeLog: * NEWS: Mention "maint info jit" command. * infrun.c (follow_fork_inferior): Don't call solib_create_inferior_hook, call post_create_inferior if a new inferior was created. * jit.c (maint_info_jit_cmd): New. (_initialize_jit): Register new command. * linux-nat.c (linux_nat_target::follow_fork): Don't call check_for_thread_db. * linux-nat.h (check_for_thread_db): Remove declaration. * linux-thread-db.c (check_thread_signals): Make static. gdb/doc/ChangeLog: * gdb.texinfo (Maintenance Commands): Mention "maint info jit". gdb/testsuite/ChangeLog: * gdb.base/jit-elf-fork-main.c: New test. * gdb.base/jit-elf-fork-solib.c: New test. * gdb.base/jit-elf-fork.exp: New test. Change-Id: I9a192e55b8a451c00e88100669283fc9ca60de5c
2021-07-12gdb: make thread_info::suspend private, add getters / settersSimon Marchi1-6/+6
A following patch will want to take some action when a pending wait status is set on or removed from a thread. Add a getter and a setter on thread_info for the pending waitstatus, so that we can add some code in the setter later. The thing is, the pending wait status field is in the thread_suspend_state, along with other fields that we need to backup before and restore after the thread does an inferior function call. Therefore, make the thread_suspend_state member private (thread_info::suspend becomes thread_info::m_suspend), and add getters / setters for all of its fields: - pending wait status - stop signal - stop reason - stop pc For the pending wait status, add the additional has_pending_waitstatus and clear_pending_waitstatus methods. I think this makes the thread_info interface a bit nicer, because we now access the fields as: thread->stop_pc () rather than thread->suspend.stop_pc The stop_pc field being in the `suspend` structure is an implementation detail of thread_info that callers don't need to be aware of. For the backup / restore of the thread_suspend_state structure, add save_suspend_to and restore_suspend_from methods. You might wonder why `save_suspend_to`, as opposed to a simple getter like thread_suspend_state &suspend (); I want to make it clear that this is to be used only for backing up and restoring the suspend state, _not_ to access fields like: thread->suspend ()->stop_pc Adding some getters / setters allows adding some assertions. I find that this helps understand how things are supposed to work. Add: - When getting the pending status (pending_waitstatus method), ensure that there is a pending status. - When setting a pending status (set_pending_waitstatus method), ensure there is no pending status. There is one case I found where this wasn't true - in remote_target::process_initial_stop_replies - which needed adjustments to respect that contract. I think it's because process_initial_stop_replies is kind of (ab)using the thread_info::suspend::waitstatus to store some statuses temporarily, for its internal use (statuses it doesn't intent on leaving pending). process_initial_stop_replies pulls out stop replies received during the initial connection using target_wait. It always stores the received event in `evthread->suspend.waitstatus`. But it only sets waitstatus_pending_p, if it deems the event interesting enough to leave pending, to be reported to the core: if (ws.kind != TARGET_WAITKIND_STOPPED || ws.value.sig != GDB_SIGNAL_0) evthread->suspend.waitstatus_pending_p = 1; It later uses this flag a bit below, to choose which thread to make the "selected" one: if (selected == NULL && thread->suspend.waitstatus_pending_p) selected = thread; And ultimately that's used if the user-visible mode is all-stop, so that we print the stop for that interesting thread: /* In all-stop, we only print the status of one thread, and leave others with their status pending. */ if (!non_stop) { thread_info *thread = selected; if (thread == NULL) thread = lowest_stopped; if (thread == NULL) thread = first; print_one_stopped_thread (thread); } But in any case (all-stop or non-stop), print_one_stopped_thread needs to access the waitstatus value of these threads that don't have a pending waitstatus (those that had TARGET_WAITKIND_STOPPED + GDB_SIGNAL_0). This doesn't work with the assertions I've put. So, change the code to only set the thread's wait status if it is an interesting one that we are going to leave pending. If the thread stopped due to a non-interesting event (TARGET_WAITKIND_STOPPED + GDB_SIGNAL_0), don't store it. Adjust print_one_stopped_thread to understand that if a thread has no pending waitstatus, it's because it stopped with TARGET_WAITKIND_STOPPED + GDB_SIGNAL_0. The call to set_last_target_status also uses the pending waitstatus. However, given that the pending waitstatus for the thread may have been cleared in print_one_stopped_thread (and that there might not even be a pending waitstatus in the first place, as explained above), it is no longer possible to do it at this point. To fix that, move the call to set_last_target_status in print_one_stopped_thread. I think this will preserve the existing behavior, because set_last_target_status is currently using the current thread's wait status. And the current thread is the last one for which print_one_stopped_thread is called. So by calling set_last_target_status in print_one_stopped_thread, we'll get the same result. set_last_target_status will possibly be called multiple times, but only the last call will matter. It just means possibly more calls to set_last_target_status, but those are cheap. Change-Id: Iedab9653238eaf8231abcf0baa20145acc8b77a7
2021-07-01Linux: Access memory even if threads are runningPedro Alves1-47/+218
Currently, on GNU/Linux, if you try to access memory and you have a running thread selected, GDB fails the memory accesses, like: (gdb) c& Continuing. (gdb) p global_var Cannot access memory at address 0x555555558010 Or: (gdb) b main Breakpoint 2 at 0x55555555524d: file access-mem-running.c, line 59. Warning: Cannot insert breakpoint 2. Cannot access memory at address 0x55555555524d This patch removes this limitation. It teaches the native Linux target to read/write memory even if the target is running. And it does this without temporarily stopping threads. We now get: (gdb) c& Continuing. (gdb) p global_var $1 = 123 (gdb) b main Breakpoint 2 at 0x555555555259: file access-mem-running.c, line 62. (The scenarios above work correctly with current GDBserver, because GDBserver temporarily stops all threads in the process whenever GDB wants to access memory (see prepare_to_access_memory / done_accessing_memory). Freezing the whole process makes sense when we need to be sure that we have a consistent view of memory and don't race with the inferior changing it at the same time as GDB is accessing it. But I think that's a too-heavy hammer for the default behavior. I think that ideally, whether to stop all threads or not should be policy decided by gdb core, probably best implemented by exposing something like gdbserver's prepare_to_access_memory / done_accessing_memory to gdb core.) Currently, if we're accessing (reading/writing) just a few bytes, then the Linux native backend does not try accessing memory via /proc/<pid>/mem and goes straight to ptrace PTRACE_PEEKTEXT/PTRACE_POKETEXT. However, ptrace always fails when the ptracee is running. So the first step is to prefer /proc/<pid>/mem even for small accesses. Without further changes however, that may cause a performance regression, due to constantly opening and closing /proc/<pid>/mem for each memory access. So the next step is to keep the /proc/<pid>/mem file open across memory accesses. If we have this, then it doesn't make sense anymore to even have the ptrace fallback, so the patch disables it. I've made it such that GDB only ever has one /proc/<pid>/mem file open at any time. As long as a memory access hits the same inferior process as the previous access, then we reuse the previously open file. If however, we access memory of a different process, then we close the previous file and open a new one for the new process. If we wanted, we could keep one /proc/<pid>/mem file open per inferior, and never close them (unless the inferior exits or execs). However, having seen bfd patches recently about hitting too many open file descriptors, I kept the logic to have only one file open tops. Also, we need to handle memory accesses for processes for which we don't have an inferior object, for when we need to detach a fork-child, and we'd probaly want to handle caching the open file for that scenario (no inferior for process) too, which would probably end up meaning caching for last non-inferior process, which is very much what I'm proposing anyhow. So always having one file open likely ends up a smaller patch. The next step is handling the case of GDB reading/writing memory through a thread that is running and exits. The access should not result in a user-visible failure if the inferior/process is still alive. Once we manage to open a /proc/<lwpid>/mem file, then that file is usable for memory accesses even if the corresponding lwp exits and is reaped. I double checked that trying to open the same /proc/<lwpid>/mem path again fails because the lwp is really gone so there's no /proc/<lwpid>/ entry on the filesystem anymore, but the previously open file remains usable. It's only when the whole process execs that we need to reopen a new file. When the kernel destroys the whole address space, i.e., when the process exits or execs, the reads/writes fail with 0 aka EOF, in which case there's nothing else to do than returning a memory access failure. Note this means that when we get an exec event, we need to reopen the file, to access the process's new address space. If we need to open (or reopen) the /proc/<pid>/mem file, and the LWP we're opening it for exits before we open it and before we reap the LWP (i.e., the LWP is zombie), the open fails with EACCES. The patch handles this by just looking for another thread until it finds one that we can open a /proc/<pid>/mem successfully for. If we need to open (or reopen) the /proc/<pid>/mem file, and the LWP we're opening has exited and we already reaped it, which is the case if the selected thread is in THREAD_EXIT state, the open fails with ENOENT. The patch handles this the same way as a zombie race (EACCES), instead of checking upfront whether we're accessing a known-exited thread, because that would result in more complicated code, because we also need to handle accessing lwps that are not listed in the core thread list, and it's the core thread list that records the THREAD_EXIT state. The patch includes two testcases: #1 - gdb.base/access-mem-running.exp This is the conceptually simplest - it is single-threaded, and has GDB read and write memory while the program is running. It also tests setting a breakpoint while the program is running, and checks that the breakpoint is hit immediately. #2 - gdb.threads/access-mem-running-thread-exit.exp This one is more elaborate, as it continuously spawns short-lived threads in order to exercise accessing memory just while threads are exiting. It also spawns two different processes and alternates accessing memory between the two processes to exercise the reopening the /proc file frequently. This also ends up exercising GDB reading from an exited thread frequently. I confirmed by putting abort() calls in the EACCES/ENOENT paths added by the patch that we do hit all of them frequently with the testcase. It also exits the process's main thread (i.e., the main thread becomes zombie), to make sure accessing memory in such a corner-case scenario works now and in the future. The tests fail on GNU/Linux native before the code changes, and pass after. They pass against current GDBserver, again because GDBserver supports memory access even if all threads are running, by transparently pausing the whole process. gdb/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> PR mi/15729 PR gdb/13463 * linux-nat.c (linux_nat_target::detach): Close the /proc/<pid>/mem file if it was open for this process. (linux_handle_extended_wait) <PTRACE_EVENT_EXEC>: Close the /proc/<pid>/mem file if it was open for this process. (linux_nat_target::mourn_inferior): Close the /proc/<pid>/mem file if it was open for this process. (linux_nat_target::xfer_partial): Adjust. Do not fall back to inf_ptrace_target::xfer_partial for memory accesses. (last_proc_mem_file): New. (maybe_close_proc_mem_file): New. (linux_proc_xfer_memory_partial_pid): New, with bits factored out from linux_proc_xfer_partial. (linux_proc_xfer_partial): Delete. (linux_proc_xfer_memory_partial): New. gdb/testsuite/ChangeLog yyyy-mm-dd Pedro Alves <pedro@palves.net> PR mi/15729 PR gdb/13463 * gdb.base/access-mem-running.c: New. * gdb.base/access-mem-running.exp: New. * gdb.threads/access-mem-running-thread-exit.c: New. * gdb.threads/access-mem-running-thread-exit.exp: New. Change-Id: Ib3c082528872662a3fc0ca9b31c34d4876c874c9
2021-05-08gdb, gdbserver: make status_to_str return std::stringSimon Marchi1-9/+11
Instead of using a static buffer. This is safer, and we don't really mind about any extra dynamic allocation here, since it's only used for debug purposes. gdb/ChangeLog: * nat/linux-waitpid.c (status_to_str): Return std::string. * nat/linux-waitpid.h (status_to_str): Likewise. * linux-nat.c (linux_nat_post_attach_wait): Adjust. (linux_nat_target::attach): Adjust. (linux_handle_extended_wait): Adjust. (wait_lwp): Adjust. (stop_wait_callback): Adjust. (linux_nat_filter_event): Adjust. (linux_nat_wait_1): Adjust. * nat/linux-waitpid.c (status_to_str): Adjust. * nat/linux-waitpid.h (status_to_str): Adjust. gdbserver/ChangeLog: * linux-low.cc (linux_process_target::wait_for_event_filtered): Adjust to status_to_str returning std::string. Change-Id: Ia8aead70270438a5690f243e6faafff6c38ff757
2021-05-08Don't run personality syscall at configure time; don't check it at allPedro Alves1-4/+0
Currently, in order to tell whether support for disabling address space randomization on Linux is available, GDB checks if the personality syscall works, at configure time. I.e., it does a run test, instead of a compile/link test: AC_RUN_IFELSE([PERSONALITY_TEST], [have_personality=true], [have_personality=false], This is a bit bogus, because the machine the build is done on may not (and is when you consider distro gdbs) be the machine that eventually runs gdb. It would be better if this were a compile/link test instead, and then at runtime, GDB coped with the personality syscall failing. Actually, GDB already copes. One environment where this is problematic is building GDB in a Docker container -- by default, Docker runs the container with seccomp, with a profile that disables the personality syscall. You can tell Docker to use a less restricted seccomp profile, but I think we should just fix it in GDB. "man 2 personality" says: This system call first appeared in Linux 1.1.20 (and thus first in a stable kernel release with Linux 1.2.0); library support was added in glibc 2.3. ... ADDR_NO_RANDOMIZE (since Linux 2.6.12) With this flag set, disable address-space-layout randomization. glibc 2.3 was released in 2002. Linux 2.6.12 was released in 2005. The original patch that added the configure checks was submitted in 2008. The first version of the patch that was submitted to the list called personality from common code: https://sourceware.org/pipermail/gdb-patches/2008-June/058204.html and then was moved to Linux-specific code: https://sourceware.org/pipermail/gdb-patches/2008-June/058209.html Since HAVE_PERSONALITY is only checked in Linux code, and ADDR_NO_RANDOMIZE exists for over 15 years, I propose just completely removing the configure checks. If for some odd reason, some remotely modern system still needs a configure check, then we can revert this commit but drop the AC_RUN_IFELSE in favor of always doing the AC_LINK_IFELSE cross-compile fallback. gdb/ChangeLog: * linux-nat.c (linux_nat_target::supports_disable_randomization): Remove references to HAVE_PERSONALITY. * nat/linux-personality.c: Remove references to HAVE_PERSONALITY. (maybe_disable_address_space_randomization) (~maybe_disable_address_space_randomizatio): Remove references to HAVE_PERSONALITY. * config.in, configure: Regenerate. gdbserver/ChangeLog: * linux-low.cc: (linux_process_target::supports_disable_randomization): Remove reference to HAVE_PERSONALITY. * config.in, configure: Regenerate. gdbsupport/ChangeLog: * common.m4 (personality test): Remove.
2021-04-07gdb: make target_ops::follow_fork return voidSimon Marchi1-3/+1
I noticed that all implementations return false, so target_ops::follow_fork doesn't really need to return a value. Change it to return void. gdb/ChangeLog: * target.h (struct target_ops) <follow_fork>: Return void. (target_follow_fork): Likewise. * target.c (default_follow_fork): Likewise. (target_follow_fork): Likewise. * infrun.c (follow_fork_inferior): Adjust. * fbsd-nat.h (class fbsd_nat_target) <follow_fork>: Return void. * fbsd-nat.c (fbsd_nat_target:::follow_fork): Likewise. * linux-nat.h (class linux_nat_target) <follow_fork>: Likewise. * linux-nat.c (linux_nat_target::follow_fork): Return void. * obsd-nat.h (class obsd_nat_target) <follow_fork>: Return void. * obsd-nat.c (obsd_nat_target::follow_fork): Likewise. * remote.c (class remote_target) <follow_fork>: Likewise. (remote_target::follow_fork): Likewise. * target-delegates.c: Re-generate. Change-Id: If908c2f68b29fa275be2b0b9deb41e4c6a1b7879
2021-02-23gdb: linux-nat: make linux_nat_filter_event return voidSimon Marchi1-12/+12
I noticed that linux_nat_filter_event returns a value, but its caller doesn't use it. This has been since 9c02b52532ac ("linux-nat.c: better starvation avoidance, handle non-stop mode too"). Before that commit, the return value was used to tell the caller whether to continue processing that event or not. But since then, the model is that we pull all events from the kernel and linux_nat_filter_event just saves the status to the lwp_info structure if it thinks it's relevant. And the caller, linux_nat_wait_1, selects a status at random amongst the threads with a pending status. So essentially, the return value of linux_nat_filter_event does not have a reason to be anymore. Change it so it returns void. gdb/ChangeLog: * linux-nat.c (linux_nat_filter_event): Return void. Change-Id: I35662868910f5122772ed92a512adfbf4da12d87
2021-02-12[gdb/threads] Fix lin_thread_get_thread_signals for glibc 2.28Tom de Vries1-9/+17
When running test-case gdb.threads/create-fail.exp on openSUSE Factory (with glibc version 2.32) I run into: ... (gdb) continue Continuing. [New Thread 0x7ffff7c83700 (LWP 626354)] [New Thread 0x7ffff7482700 (LWP 626355)] [Thread 0x7ffff7c83700 (LWP 626354) exited] [New Thread 0x7ffff6c81700 (LWP 626356)] [Thread 0x7ffff7482700 (LWP 626355) exited] [New Thread 0x7ffff6480700 (LWP 626357)] [Thread 0x7ffff6c81700 (LWP 626356) exited] [New Thread 0x7ffff5c7f700 (LWP 626358)] [Thread 0x7ffff6480700 (LWP 626357) exited] pthread_create: 22: Invalid argument Thread 6 "create-fail" received signal SIG32, Real-time event 32. [Switching to Thread 0x7ffff5c7f700 (LWP 626358)] 0x00007ffff7d87695 in clone () from /lib64/libc.so.6 (gdb) FAIL: gdb.threads/create-fail.exp: iteration 1: run till end ... The problem is that glibc-internal signal SIGCANCEL is not recognized by gdb. There's code in check_thread_signals that is supposed to take care of that, but it's not working because this code in lin_thread_get_thread_signals has stopped working: ... /* NPTL reserves the first two RT signals, but does not provide any way for the debugger to query the signal numbers - fortunately they don't change. */ sigaddset (set, __SIGRTMIN); sigaddset (set, __SIGRTMIN + 1); ... Since glibc commit d2dc5467c6 "Filter out NPTL internal signals (BZ #22391)" (first released as part of glibc 2.28), a sigaddset with a glibc-internal signal has no other effect than setting errno to EINVALID. Fix this by eliminating the usage of sigset_t in check_thread_signals and lin_thread_get_thread_signals. The same problem was observed on Ubuntu 20.04. Tested on x86_64-linux, openSUSE Factory. Tested on aarch64-linux, Ubuntu 20.04 and Ubuntu 18.04. gdb/ChangeLog: 2021-02-12 Tom de Vries <tdevries@suse.de> PR threads/26228 * linux-nat.c (lin_thread_get_thread_signals): Remove. (lin_thread_signals): New static var. (lin_thread_get_thread_signal_num, lin_thread_get_thread_signal): New function. * linux-nat.h (lin_thread_get_thread_signals): Remove. (lin_thread_get_thread_signal_num, lin_thread_get_thread_signal): Declare. * linux-thread-db.c (check_thread_signals): Use lin_thread_get_thread_signal_num and lin_thread_get_thread_signal.
2021-02-03detach and breakpoint removalPedro Alves1-0/+5
A following patch will add a testcase that has a number of threads constantly stepping over a breakpoint, and then has GDB detach the process. That testcase sometimes fails with the inferior crashing with SIGTRAP after the detach because of the bug fixed by this patch, when tested with the native target. The problem is that target_detach removes breakpoints from the target immediately, and that does not work with the native GNU/Linux target (and probably no other native target) currently. The test wouldn't fail with this issue when testing against gdbserver, because gdbserver does allow accessing memory while the current thread is running, by transparently pausing all threads temporarily, without GDB noticing. Implementing that in gdbserver was a lot of work, so I'm not looking forward right now to do the same in the native target. Instead, I came up with a simpler solution -- push the breakpoints removal down to the targets. The Linux target conveniently already pauses all threads before detaching them, since PTRACE_DETACH only works with stopped threads, so we move removing breakpoints to after that. Only the remote and GNU/Linux targets support support async execution, so no other target should really need this. gdb/ChangeLog: * linux-nat.c (linux_nat_target::detach): Remove breakpoints here... * remote.c (remote_target::remote_detach_1): ... and here ... * target.c (target_detach): ... instead of here. * target.h (target_ops::detach): Add comment.
2021-01-20gdb: make some variables staticSimon Marchi1-1/+1
I'm trying to enable clang's -Wmissing-variable-declarations warning. This patch fixes all the obvious spots where we can simply add "static" (at least, found when building on x86-64 Linux). gdb/ChangeLog: * aarch64-linux-tdep.c (aarch64_linux_record_tdep): Make static. * aarch64-tdep.c (tdesc_aarch64_list, aarch64_prologue_unwind, aarch64_stub_unwind, aarch64_normal_base, ): Make static. * arm-linux-tdep.c (arm_prologue_unwind): Make static. * arm-tdep.c (struct frame_unwind): Make static. * auto-load.c (auto_load_safe_path_vec): Make static. * csky-tdep.c (csky_stub_unwind): Make static. * gdbarch.c (gdbarch_data_registry): Make static. * gnu-v2-abi.c (gnu_v2_abi_ops): Make static. * i386-netbsd-tdep.c (i386nbsd_mc_reg_offset): Make static. * i386-tdep.c (i386_frame_setup_skip_insns, i386_tramp_chain_in_reg_insns, i386_tramp_chain_on_stack_insns): Make static. * infrun.c (observer_mode): Make static. * linux-nat.c (sigchld_action): Make static. * linux-thread-db.c (thread_db_list): Make static. * maint-test-options.c (maintenance_test_options_list): * mep-tdep.c (mep_csr_registers): Make static. * mi/mi-cmds.c (struct mi_cmd_stats): Remove struct type name. (stats): Make static. * nat/linux-osdata.c (struct osdata_type): Make static. * ppc-netbsd-tdep.c (ppcnbsd_reg_offsets): Make static. * progspace.c (last_program_space_num): Make static. * python/py-param.c (struct parm_constant): Remove struct type name. (parm_constants): Make static. * python/py-record-btrace.c (btpy_list_methods): Make static. * python/py-record.c (recpy_gap_type): Make static. * record.c (record_goto_cmdlist): Make static. * regcache.c (regcache_descr_handle): Make static. * registry.h (DEFINE_REGISTRY): Make definition static. * symmisc.c (std_in, std_out, std_err): Make static. * top.c (previous_saved_command_line): Make static. * tracepoint.c (trace_user, trace_notes, trace_stop_notes): Make static. * unittests/command-def-selftests.c (nr_duplicates, nr_invalid_prefixcmd, lists): Make static. * unittests/observable-selftests.c (test_notification): Make static. * unittests/optional/assignment/1.cc (counter): Make static. * unittests/optional/assignment/2.cc (counter): Make static. * unittests/optional/assignment/3.cc (counter): Make static. * unittests/optional/assignment/4.cc (counter): Make static. * unittests/optional/assignment/5.cc (counter): Make static. * unittests/optional/assignment/6.cc (counter): Make static. gdbserver/ChangeLog: * ax.cc (bytecode_address_table): Make static. * debug.cc (debug_file): Make static. * linux-low.cc (stopping_threads): Make static. (step_over_bkpt): Make static. * linux-x86-low.cc (amd64_emit_ops, i386_emit_ops): Make static. * tracepoint.cc (stop_tracing_bkpt, flush_trace_buffer_bkpt, alloced_trace_state_variables, trace_buffer_ctrl, tracing_start_time, tracing_stop_time, tracing_user_name, tracing_notes, tracing_stop_note): Make static. Change-Id: Ic1d8034723b7802502bda23770893be2338ab020
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-11gdb: factor out debug_prefixed_printf_condSimon Marchi1-6/+1
The same pattern happens often to define a "debug_printf" macro: #define displaced_debug_printf(fmt, ...) \ do \ { \ if (debug_displaced) \ debug_prefixed_printf ("displaced", __func__, fmt, ##__VA_ARGS__); \ } \ while (0) Move this pattern behind a helper macro, debug_prefixed_printf_cond and update the existing macros to use it. gdb/ChangeLog: * displaced-stepping.h (displaced_debug_printf): Use debug_prefixed_printf_cond. * dwarf2/read.c (dwarf_read_debug_printf): Likewise. (dwarf_read_debug_printf_v): Likewise. * infrun.h (infrun_debug_printf): Likewise. * linux-nat.c (linux_nat_debug_printf): Likewise. gdbsupport/ChangeLog: * common-debug.h (debug_prefixed_printf_cond): New. * event-loop.h (event_loop_debug_printf): Use debug_prefixed_printf_cond. Change-Id: I1ff48b98b8d1cc405d1c7e8da8ceadf4e3a17f99
2020-11-02gdb, gdbserver, gdbsupport: fix leading space vs tabs issuesSimon Marchi1-3/+3
Many spots incorrectly use only spaces for indentation (for example, there are a lot of spots in ada-lang.c). I've always found it awkward when I needed to edit one of these spots: do I keep the original wrong indentation, or do I fix it? What if the lines around it are also wrong, do I fix them too? I probably don't want to fix them in the same patch, to avoid adding noise to my patch. So I propose to fix as much as possible once and for all (hopefully). One typical counter argument for this is that it makes code archeology more difficult, because git-blame will show this commit as the last change for these lines. My counter counter argument is: when git-blaming, you often need to do "blame the file at the parent commit" anyway, to go past some other refactor that touched the line you are interested in, but is not the change you are looking for. So you already need a somewhat efficient way to do this. Using some interactive tool, rather than plain git-blame, makes this trivial. For example, I use "tig blame <file>", where going back past the commit that changed the currently selected line is one keystroke. It looks like Magit in Emacs does it too (though I've never used it). Web viewers of Github and Gitlab do it too. My point is that it won't really make archeology more difficult. The other typical counter argument is that it will cause conflicts with existing patches. That's true... but it's a one time cost, and those are not conflicts that are difficult to resolve. I have also tried "git rebase --ignore-whitespace", it seems to work well. Although that will re-introduce the faulty indentation, so one needs to take care of fixing the indentation in the patch after that (which is easy). gdb/ChangeLog: * aarch64-linux-tdep.c: Fix indentation. * aarch64-ravenscar-thread.c: Fix indentation. * aarch64-tdep.c: Fix indentation. * aarch64-tdep.h: Fix indentation. * ada-lang.c: Fix indentation. * ada-lang.h: Fix indentation. * ada-tasks.c: Fix indentation. * ada-typeprint.c: Fix indentation. * ada-valprint.c: Fix indentation. * ada-varobj.c: Fix indentation. * addrmap.c: Fix indentation. * addrmap.h: Fix indentation. * agent.c: Fix indentation. * aix-thread.c: Fix indentation. * alpha-bsd-nat.c: Fix indentation. * alpha-linux-tdep.c: Fix indentation. * alpha-mdebug-tdep.c: Fix indentation. * alpha-nbsd-tdep.c: Fix indentation. * alpha-obsd-tdep.c: Fix indentation. * alpha-tdep.c: Fix indentation. * amd64-bsd-nat.c: Fix indentation. * amd64-darwin-tdep.c: Fix indentation. * amd64-linux-nat.c: Fix indentation. * amd64-linux-tdep.c: Fix indentation. * amd64-nat.c: Fix indentation. * amd64-obsd-tdep.c: Fix indentation. * amd64-tdep.c: Fix indentation. * amd64-windows-tdep.c: Fix indentation. * annotate.c: Fix indentation. * arc-tdep.c: Fix indentation. * arch-utils.c: Fix indentation. * arch/arm-get-next-pcs.c: Fix indentation. * arch/arm.c: Fix indentation. * arm-linux-nat.c: Fix indentation. * arm-linux-tdep.c: Fix indentation. * arm-nbsd-tdep.c: Fix indentation. * arm-pikeos-tdep.c: Fix indentation. * arm-tdep.c: Fix indentation. * arm-tdep.h: Fix indentation. * arm-wince-tdep.c: Fix indentation. * auto-load.c: Fix indentation. * auxv.c: Fix indentation. * avr-tdep.c: Fix indentation. * ax-gdb.c: Fix indentation. * ax-general.c: Fix indentation. * bfin-linux-tdep.c: Fix indentation. * block.c: Fix indentation. * block.h: Fix indentation. * blockframe.c: Fix indentation. * bpf-tdep.c: Fix indentation. * break-catch-sig.c: Fix indentation. * break-catch-syscall.c: Fix indentation. * break-catch-throw.c: Fix indentation. * breakpoint.c: Fix indentation. * breakpoint.h: Fix indentation. * bsd-uthread.c: Fix indentation. * btrace.c: Fix indentation. * build-id.c: Fix indentation. * buildsym-legacy.h: Fix indentation. * buildsym.c: Fix indentation. * c-typeprint.c: Fix indentation. * c-valprint.c: Fix indentation. * c-varobj.c: Fix indentation. * charset.c: Fix indentation. * cli/cli-cmds.c: Fix indentation. * cli/cli-decode.c: Fix indentation. * cli/cli-decode.h: Fix indentation. * cli/cli-script.c: Fix indentation. * cli/cli-setshow.c: Fix indentation. * coff-pe-read.c: Fix indentation. * coffread.c: Fix indentation. * compile/compile-cplus-types.c: Fix indentation. * compile/compile-object-load.c: Fix indentation. * compile/compile-object-run.c: Fix indentation. * completer.c: Fix indentation. * corefile.c: Fix indentation. * corelow.c: Fix indentation. * cp-abi.h: Fix indentation. * cp-namespace.c: Fix indentation. * cp-support.c: Fix indentation. * cp-valprint.c: Fix indentation. * cris-linux-tdep.c: Fix indentation. * cris-tdep.c: Fix indentation. * darwin-nat-info.c: Fix indentation. * darwin-nat.c: Fix indentation. * darwin-nat.h: Fix indentation. * dbxread.c: Fix indentation. * dcache.c: Fix indentation. * disasm.c: Fix indentation. * dtrace-probe.c: Fix indentation. * dwarf2/abbrev.c: Fix indentation. * dwarf2/attribute.c: Fix indentation. * dwarf2/expr.c: Fix indentation. * dwarf2/frame.c: Fix indentation. * dwarf2/index-cache.c: Fix indentation. * dwarf2/index-write.c: Fix indentation. * dwarf2/line-header.c: Fix indentation. * dwarf2/loc.c: Fix indentation. * dwarf2/macro.c: Fix indentation. * dwarf2/read.c: Fix indentation. * dwarf2/read.h: Fix indentation. * elfread.c: Fix indentation. * eval.c: Fix indentation. * event-top.c: Fix indentation. * exec.c: Fix indentation. * exec.h: Fix indentation. * expprint.c: Fix indentation. * f-lang.c: Fix indentation. * f-typeprint.c: Fix indentation. * f-valprint.c: Fix indentation. * fbsd-nat.c: Fix indentation. * fbsd-tdep.c: Fix indentation. * findvar.c: Fix indentation. * fork-child.c: Fix indentation. * frame-unwind.c: Fix indentation. * frame-unwind.h: Fix indentation. * frame.c: Fix indentation. * frv-linux-tdep.c: Fix indentation. * frv-tdep.c: Fix indentation. * frv-tdep.h: Fix indentation. * ft32-tdep.c: Fix indentation. * gcore.c: Fix indentation. * gdb_bfd.c: Fix indentation. * gdbarch.sh: Fix indentation. * gdbarch.c: Re-generate * gdbarch.h: Re-generate. * gdbcore.h: Fix indentation. * gdbthread.h: Fix indentation. * gdbtypes.c: Fix indentation. * gdbtypes.h: Fix indentation. * glibc-tdep.c: Fix indentation. * gnu-nat.c: Fix indentation. * gnu-nat.h: Fix indentation. * gnu-v2-abi.c: Fix indentation. * gnu-v3-abi.c: Fix indentation. * go32-nat.c: Fix indentation. * guile/guile-internal.h: Fix indentation. * guile/scm-cmd.c: Fix indentation. * guile/scm-frame.c: Fix indentation. * guile/scm-iterator.c: Fix indentation. * guile/scm-math.c: Fix indentation. * guile/scm-ports.c: Fix indentation. * guile/scm-pretty-print.c: Fix indentation. * guile/scm-value.c: Fix indentation. * h8300-tdep.c: Fix indentation. * hppa-linux-nat.c: Fix indentation. * hppa-linux-tdep.c: Fix indentation. * hppa-nbsd-nat.c: Fix indentation. * hppa-nbsd-tdep.c: Fix indentation. * hppa-obsd-nat.c: Fix indentation. * hppa-tdep.c: Fix indentation. * hppa-tdep.h: Fix indentation. * i386-bsd-nat.c: Fix indentation. * i386-darwin-nat.c: Fix indentation. * i386-darwin-tdep.c: Fix indentation. * i386-dicos-tdep.c: Fix indentation. * i386-gnu-nat.c: Fix indentation. * i386-linux-nat.c: Fix indentation. * i386-linux-tdep.c: Fix indentation. * i386-nto-tdep.c: Fix indentation. * i386-obsd-tdep.c: Fix indentation. * i386-sol2-nat.c: Fix indentation. * i386-tdep.c: Fix indentation. * i386-tdep.h: Fix indentation. * i386-windows-tdep.c: Fix indentation. * i387-tdep.c: Fix indentation. * i387-tdep.h: Fix indentation. * ia64-libunwind-tdep.c: Fix indentation. * ia64-libunwind-tdep.h: Fix indentation. * ia64-linux-nat.c: Fix indentation. * ia64-linux-tdep.c: Fix indentation. * ia64-tdep.c: Fix indentation. * ia64-tdep.h: Fix indentation. * ia64-vms-tdep.c: Fix indentation. * infcall.c: Fix indentation. * infcmd.c: Fix indentation. * inferior.c: Fix indentation. * infrun.c: Fix indentation. * iq2000-tdep.c: Fix indentation. * language.c: Fix indentation. * linespec.c: Fix indentation. * linux-fork.c: Fix indentation. * linux-nat.c: Fix indentation. * linux-tdep.c: Fix indentation. * linux-thread-db.c: Fix indentation. * lm32-tdep.c: Fix indentation. * m2-lang.c: Fix indentation. * m2-typeprint.c: Fix indentation. * m2-valprint.c: Fix indentation. * m32c-tdep.c: Fix indentation. * m32r-linux-tdep.c: Fix indentation. * m32r-tdep.c: Fix indentation. * m68hc11-tdep.c: Fix indentation. * m68k-bsd-nat.c: Fix indentation. * m68k-linux-nat.c: Fix indentation. * m68k-linux-tdep.c: Fix indentation. * m68k-tdep.c: Fix indentation. * machoread.c: Fix indentation. * macrocmd.c: Fix indentation. * macroexp.c: Fix indentation. * macroscope.c: Fix indentation. * macrotab.c: Fix indentation. * macrotab.h: Fix indentation. * main.c: Fix indentation. * mdebugread.c: Fix indentation. * mep-tdep.c: Fix indentation. * mi/mi-cmd-catch.c: Fix indentation. * mi/mi-cmd-disas.c: Fix indentation. * mi/mi-cmd-env.c: Fix indentation. * mi/mi-cmd-stack.c: Fix indentation. * mi/mi-cmd-var.c: Fix indentation. * mi/mi-cmds.c: Fix indentation. * mi/mi-main.c: Fix indentation. * mi/mi-parse.c: Fix indentation. * microblaze-tdep.c: Fix indentation. * minidebug.c: Fix indentation. * minsyms.c: Fix indentation. * mips-linux-nat.c: Fix indentation. * mips-linux-tdep.c: Fix indentation. * mips-nbsd-tdep.c: Fix indentation. * mips-tdep.c: Fix indentation. * mn10300-linux-tdep.c: Fix indentation. * mn10300-tdep.c: Fix indentation. * moxie-tdep.c: Fix indentation. * msp430-tdep.c: Fix indentation. * namespace.h: Fix indentation. * nat/fork-inferior.c: Fix indentation. * nat/gdb_ptrace.h: Fix indentation. * nat/linux-namespaces.c: Fix indentation. * nat/linux-osdata.c: Fix indentation. * nat/netbsd-nat.c: Fix indentation. * nat/x86-dregs.c: Fix indentation. * nbsd-nat.c: Fix indentation. * nbsd-tdep.c: Fix indentation. * nios2-linux-tdep.c: Fix indentation. * nios2-tdep.c: Fix indentation. * nto-procfs.c: Fix indentation. * nto-tdep.c: Fix indentation. * objfiles.c: Fix indentation. * objfiles.h: Fix indentation. * opencl-lang.c: Fix indentation. * or1k-tdep.c: Fix indentation. * osabi.c: Fix indentation. * osabi.h: Fix indentation. * osdata.c: Fix indentation. * p-lang.c: Fix indentation. * p-typeprint.c: Fix indentation. * p-valprint.c: Fix indentation. * parse.c: Fix indentation. * ppc-linux-nat.c: Fix indentation. * ppc-linux-tdep.c: Fix indentation. * ppc-nbsd-nat.c: Fix indentation. * ppc-nbsd-tdep.c: Fix indentation. * ppc-obsd-nat.c: Fix indentation. * ppc-ravenscar-thread.c: Fix indentation. * ppc-sysv-tdep.c: Fix indentation. * ppc64-tdep.c: Fix indentation. * printcmd.c: Fix indentation. * proc-api.c: Fix indentation. * producer.c: Fix indentation. * producer.h: Fix indentation. * prologue-value.c: Fix indentation. * prologue-value.h: Fix indentation. * psymtab.c: Fix indentation. * python/py-arch.c: Fix indentation. * python/py-bpevent.c: Fix indentation. * python/py-event.c: Fix indentation. * python/py-event.h: Fix indentation. * python/py-finishbreakpoint.c: Fix indentation. * python/py-frame.c: Fix indentation. * python/py-framefilter.c: Fix indentation. * python/py-inferior.c: Fix indentation. * python/py-infthread.c: Fix indentation. * python/py-objfile.c: Fix indentation. * python/py-prettyprint.c: Fix indentation. * python/py-registers.c: Fix indentation. * python/py-signalevent.c: Fix indentation. * python/py-stopevent.c: Fix indentation. * python/py-stopevent.h: Fix indentation. * python/py-threadevent.c: Fix indentation. * python/py-tui.c: Fix indentation. * python/py-unwind.c: Fix indentation. * python/py-value.c: Fix indentation. * python/py-xmethods.c: Fix indentation. * python/python-internal.h: Fix indentation. * python/python.c: Fix indentation. * ravenscar-thread.c: Fix indentation. * record-btrace.c: Fix indentation. * record-full.c: Fix indentation. * record.c: Fix indentation. * reggroups.c: Fix indentation. * regset.h: Fix indentation. * remote-fileio.c: Fix indentation. * remote.c: Fix indentation. * reverse.c: Fix indentation. * riscv-linux-tdep.c: Fix indentation. * riscv-ravenscar-thread.c: Fix indentation. * riscv-tdep.c: Fix indentation. * rl78-tdep.c: Fix indentation. * rs6000-aix-tdep.c: Fix indentation. * rs6000-lynx178-tdep.c: Fix indentation. * rs6000-nat.c: Fix indentation. * rs6000-tdep.c: Fix indentation. * rust-lang.c: Fix indentation. * rx-tdep.c: Fix indentation. * s12z-tdep.c: Fix indentation. * s390-linux-tdep.c: Fix indentation. * score-tdep.c: Fix indentation. * ser-base.c: Fix indentation. * ser-mingw.c: Fix indentation. * ser-uds.c: Fix indentation. * ser-unix.c: Fix indentation. * serial.c: Fix indentation. * sh-linux-tdep.c: Fix indentation. * sh-nbsd-tdep.c: Fix indentation. * sh-tdep.c: Fix indentation. * skip.c: Fix indentation. * sol-thread.c: Fix indentation. * solib-aix.c: Fix indentation. * solib-darwin.c: Fix indentation. * solib-frv.c: Fix indentation. * solib-svr4.c: Fix indentation. * solib.c: Fix indentation. * source.c: Fix indentation. * sparc-linux-tdep.c: Fix indentation. * sparc-nbsd-tdep.c: Fix indentation. * sparc-obsd-tdep.c: Fix indentation. * sparc-ravenscar-thread.c: Fix indentation. * sparc-tdep.c: Fix indentation. * sparc64-linux-tdep.c: Fix indentation. * sparc64-nbsd-tdep.c: Fix indentation. * sparc64-obsd-tdep.c: Fix indentation. * sparc64-tdep.c: Fix indentation. * stabsread.c: Fix indentation. * stack.c: Fix indentation. * stap-probe.c: Fix indentation. * stubs/ia64vms-stub.c: Fix indentation. * stubs/m32r-stub.c: Fix indentation. * stubs/m68k-stub.c: Fix indentation. * stubs/sh-stub.c: Fix indentation. * stubs/sparc-stub.c: Fix indentation. * symfile-mem.c: Fix indentation. * symfile.c: Fix indentation. * symfile.h: Fix indentation. * symmisc.c: Fix indentation. * symtab.c: Fix indentation. * symtab.h: Fix indentation. * target-float.c: Fix indentation. * target.c: Fix indentation. * target.h: Fix indentation. * tic6x-tdep.c: Fix indentation. * tilegx-linux-tdep.c: Fix indentation. * tilegx-tdep.c: Fix indentation. * top.c: Fix indentation. * tracefile-tfile.c: Fix indentation. * tracepoint.c: Fix indentation. * tui/tui-disasm.c: Fix indentation. * tui/tui-io.c: Fix indentation. * tui/tui-regs.c: Fix indentation. * tui/tui-stack.c: Fix indentation. * tui/tui-win.c: Fix indentation. * tui/tui-winsource.c: Fix indentation. * tui/tui.c: Fix indentation. * typeprint.c: Fix indentation. * ui-out.h: Fix indentation. * unittests/copy_bitwise-selftests.c: Fix indentation. * unittests/memory-map-selftests.c: Fix indentation. * utils.c: Fix indentation. * v850-tdep.c: Fix indentation. * valarith.c: Fix indentation. * valops.c: Fix indentation. * valprint.c: Fix indentation. * valprint.h: Fix indentation. * value.c: Fix indentation. * value.h: Fix indentation. * varobj.c: Fix indentation. * vax-tdep.c: Fix indentation. * windows-nat.c: Fix indentation. * windows-tdep.c: Fix indentation. * xcoffread.c: Fix indentation. * xml-syscall.c: Fix indentation. * xml-tdesc.c: Fix indentation. * xstormy16-tdep.c: Fix indentation. * xtensa-config.c: Fix indentation. * xtensa-linux-nat.c: Fix indentation. * xtensa-linux-tdep.c: Fix indentation. * xtensa-tdep.c: Fix indentation. gdbserver/ChangeLog: * ax.cc: Fix indentation. * dll.cc: Fix indentation. * inferiors.h: Fix indentation. * linux-low.cc: Fix indentation. * linux-nios2-low.cc: Fix indentation. * linux-ppc-ipa.cc: Fix indentation. * linux-ppc-low.cc: Fix indentation. * linux-x86-low.cc: Fix indentation. * linux-xtensa-low.cc: Fix indentation. * regcache.cc: Fix indentation. * server.cc: Fix indentation. * tracepoint.cc: Fix indentation. gdbsupport/ChangeLog: * common-exceptions.h: Fix indentation. * event-loop.cc: Fix indentation. * fileio.cc: Fix indentation. * filestuff.cc: Fix indentation. * gdb-dlfcn.cc: Fix indentation. * gdb_string_view.h: Fix indentation. * job-control.cc: Fix indentation. * signals.cc: Fix indentation. Change-Id: I4bad7ae6be0fbe14168b8ebafb98ffe14964a695
2020-10-31gdb: restore some checks of debug flagsAndrew Burgess1-1/+6
This partially reverts some parts of the commit: commit 17417fb0ec9842de1774e1e76f1f11c00cdafc47 Date: Sat Oct 31 09:01:25 2020 -0400 gdb, gdbsupport: add debug_prefixed_printf, remove boilerplate functions This commit removed 3 places where some debug flags were being checked. The result was that debug tracing was being printed unconditionally. This commit adds back the 3 flag checks. gdb/ChangeLog: * infrun.h (infrun_debug_printf): Add check of debug_infrun flag. (debug_prefixed_printf): Add check of debug_displaced flag. * linux-nat.c (linux_nat_debug_printf): Add check of debug_linux_nat flag.
generated by cgit v1.1 at 2025-01-11 02:01:13 +0000