This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: single-stepping and internal breakpoints on a multi-threaded program


Jim and Michael,

Thank you for your comments.  

From: Michael Snyder <Michael dot Snyder at access-company dot com>
Subject: Re: single-stepping and internal breakpoints on a multi-threaded program
Date: Fri, 06 Apr 2007 15:25:09 -0700

> > I have forgetten exactly how GDB handles multi-threaded single
> > stepping; I'm afraid I can't suggest how to do this.  If you're unable
> > to fix it yourself, please file a bug report, and include your test
> > program.
> 
> I'm thinking that gdb just loses the "I'm stepping this thread" 
> bit of state info, which is normally handled in "proceed" and 
> stored in the infrun-state struct - whereupon it just continues
> both threads without stepping.

I think it's true in some ways: it seemed that the clue for GDB to
decide that "I'm stepping this thread" is eventually only the value of
step_range_end.  

When the target get stopped on a thread different from which GDB
expected to stop, it was preserved in the thread_info structure by
context_switch, but never had an oppotunity to be looked back till the
target get stopped on that thread again.  It is not just lost, but no
better than lost.  

I think I should work more on the problem, but unfortunately, my
copyright assignment to FSF is still not ready.  So I will file it to
the bug tracking system, following Jim's advice.  
I will be back on it when I find that anything is not done for it
after my assignment is ready.  I hope not, though :-)

Thanks anyway, 
-- 
Emi SUZUKI


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]