summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@polymtl.ca>2021-08-17 15:23:41 -0400
committerSimon Marchi <simon.marchi@polymtl.ca>2021-08-17 15:26:10 -0400
commitc316c0b29d9991a231bdcbab0fcdc51114cddd13 (patch)
treeef79c661bc1d87ab11af252bae695b1417eaf478
parent5d9cff510e8c04ded28272ef2121d814f5787a57 (diff)
downloadbinutils-gdb-c316c0b29d9991a231bdcbab0fcdc51114cddd13.tar.gz
gdb: fix thread_step_over_chain_length
If I debug a single-thread program and look at the infrun debug logs, I see: [infrun] start_step_over: stealing global queue of threads to step, length = 2 That makes no sense... turns out there's a buglet in thread_step_over_chain_length, "num" should be initialized to 0. I think this bug is a leftover from an earlier version of the code (not merged upstream) that manually walked the list, where the first item was implicitly counted (hence the 1). Change-Id: I0af03aa93509aed36528be5076894dc156a0b5ce
-rw-r--r--gdb/thread.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/gdb/thread.c b/gdb/thread.c
index 8f0584e5238..a82fb49140a 100644
--- a/gdb/thread.c
+++ b/gdb/thread.c
@@ -380,7 +380,7 @@ thread_is_in_step_over_chain (struct thread_info *tp)
int
thread_step_over_chain_length (const thread_step_over_list &l)
{
- int num = 1;
+ int num = 0;
for (const thread_info &thread ATTRIBUTE_UNUSED : l)
++num;