[Lldb-commits] [PATCH] D5871: Add an OperatingSystem plugin to support goroutines

[Ryan Brown via lldb-commits]

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  

>  this?


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.


Repository:
  rL LLVM

http://reviews.llvm.org/D5871

Files:
  cmake/LLDBDependencies.cmake
  include/lldb/Core/PluginManager.h
  include/lldb/lldb-enumerations.h
  lib/Makefile
  lldb.xcodeproj/project.pbxproj
  source/Core/PluginManager.cpp
  source/Initialization/SystemInitializerCommon.cpp
  source/Plugins/Makefile
  source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
  source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
  source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
  source/Plugins/OperatingSystem/CMakeLists.txt
  source/Plugins/OperatingSystem/Go/CMakeLists.txt
  source/Plugins/OperatingSystem/Go/Makefile
  source/Plugins/OperatingSystem/Go/OperatingSystemGo.cpp
  source/Plugins/OperatingSystem/Go/OperatingSystemGo.h
  source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  source/Symbol/ObjectFile.cpp
  source/Target/Process.cpp
  source/Target/StackFrameList.cpp
  source/Target/ThreadList.cpp
  source/Utility/ConvertEnum.cpp
  test/lang/go/goroutines/TestGoroutines.py
  test/lang/go/goroutines/main.go

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D5871.34914.patch
Type: text/x-patch
Size: 49675 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20150916/df5a5e7a/attachment-0001.bin>