[Lldb-commits] [PATCH] D71440: Extending step-over range past calls was causing deadlocks, fix that.

[Jim Ingham via lldb-commits]

> On Dec 17, 2019, at 2:41 AM, Pavel Labath via Phabricator <reviews at reviews.llvm.org> wrote:
> 
> labath added a comment.
> 
> Thanks for the explanation (and for updating the test). This actually explains why it sometimes seemed that I lose control over other threads while stepping one of them. I'll be sure to use the --run-mode argument next time. This seems fine given how the current stepping logic works, though I personally would expect that the other also threads stay stopped when i do something called "thread step-over", but I get the feeling I expect a different kind of threading behavior from my debugger than most people...

For folks that know how debuggers work, and are aware that "thread step-over" might cause deadlocks because it is only running one thread, and are willing to manage that themselves, sticking to one thread can make debugging multi-threaded apps more accurate.  Since you can suspend & resume individual threads, you can even move the blocking thread a just past releasing the lock before continuing on the first thread.  Some day lldb will also know about all the locking primitives, and can know "Thread A is blocked on a lock held by Thread B" and can tell when Thread B releases the lock.  At that point we could do thread stepping in a much more fine grained way.

For now, my experience supporting lldb is that for most people the debugger is a black box, and if they see this sort of behavior they will think the debugger has hung and not know (or want to know) that they can control this behavior.  So I'm pretty sure the current default mode is appropriate for the majority of our users.

BTW, if you use the "step", "next" and "fin" aliases rather than "thread step-in", etc. you could just switch the aliases to set the run mode to this-thread  for your uses.  It would also be appropriate to add a setting for the default run mode as well, as that would make it easier to switch behaviors on the fly.  I don't think I omitted this for a reason other than time...

Jim


> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D71440/new/
> 
> https://reviews.llvm.org/D71440
> 
> 
>