aboutsummaryrefslogtreecommitdiff
path: root/gdbsupport/gdb-hashtab.h
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2023-07-22 15:28:28 +0100
committerAndrew Burgess <aburgess@redhat.com>2023-07-23 09:28:33 +0100
commit8a9da63e407c511df32841abcbe20effe2f3e398 (patch)
treeb65893eceb8cdcf6e575e394025b2268d5952f0e /gdbsupport/gdb-hashtab.h
parentdd82bbc1b3e79fb5e072ce4953cafc789333ce82 (diff)
downloadgdb-8a9da63e407c511df32841abcbe20effe2f3e398.zip
gdb-8a9da63e407c511df32841abcbe20effe2f3e398.tar.gz
gdb-8a9da63e407c511df32841abcbe20effe2f3e398.tar.bz2
gdb: two changes to linux_nat_debug_printf calls in linux-nat.c
This commit adjusts some of the debug output in linux-nat.c, but makes no other functional changes to GDB. In resume_lwp I've added the word "sibling" to one of the debug messages. All the other debug messages in this function talk about operating on the sibling thread, so I think it makes sense, for consistency, if the message I've updated also talks about the sibling thread. In resume_stopped_resumed_lwps I've reordered the condition checks so that the vfork-parent check now happens after the checks for whether the thread is already resumed or not. This makes no functional difference to GDB, but does, I think, mean we see more helpful debug messages first. Consider the situation where a vfork-parent thread is already resumed, and resume_stopped_resumed_lwps is called. Previously the message saying that the thread was not being resumed due to being a vfork-parent, was printed. This might give the impression that the thread is left in a not resumed state, which is misleading. After this change we now get a message saying that the thread is not being resumed due to it not being stopped (i.e. is already resumed). With this message the already resumed nature of the thread is much clearer. I found this change helpful when debugging some vfork related issues.
Diffstat (limited to 'gdbsupport/gdb-hashtab.h')
0 files changed, 0 insertions, 0 deletions