[Lldb-commits] [PATCH] D5871: Add an OperatingSystem plugin to support goroutines
Ryan Brown via lldb-commits
lldb-commits at lists.llvm.org
Wed Sep 16 12:37:27 PDT 2015
ribrdb updated this revision to Diff 34914.
ribrdb added a comment.
> I am confused as to why we need to do this. If you have a memory thread, it
> might be backed by a real thread, or it might not. If it is backed by a
> real thread, we should be asking the real thread why it really stopped and
> the memory thread will say that it stopped for the same reason the real
> thread stopped. If it isn't backed by a real thread, then the memory thread
> will say why it stopped. Can you elaborate on why you think you need to do
Hmm. Actually I'm not sure this is necessary anymore -- the unittest seems to pass without it.
Originally I added this because we were occasionally having problems where you'd do 'next',
but lldb would never stop.
This was a long time ago so things might have changed, but I think this is what was going on:
- StepOver set some sort of thread specific breakpoint for the MemoryThread's tid (e.g. 1)
- When you hit the breakpoint the Process only checked against the real thread (e.g. tid 31984)
- The tids don't match so it ignores the breakpoint. Or sometimes stops with a strange reason.
Even with this I think there's still some problems with thread plans and memory threads.
I did a little testing with go and things seem to be working. But I tried creating a couple python
plugins (one that alternates between a core backed thread and no memory threads, and one with 2 memory threads that alternate between 1 backing thread). In both cases if I used "next" lldb stopped with a strange reason.
> Why is this needed? Do you have a case where sometimes you have a real
> thread that isn't backed by memory thread, and later it does become backed
> by a memory thread or vice versa?
Yes the go runtime creates some number of real "M" threads, and schedules
user level "g" threads across the "M"s. A "g" may move around between "M"s.
Also it's common that all the "g"s are blocked on io or locks, so an "M" is
just sitting around waiting for a "g" to unblock.
I suppose it also would be possible to stop while an "M" is switching
between "g"s. In either case there would be no memory thread at that moment.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 49675 bytes
Desc: not available
More information about the lldb-commits