The codes is at http://reviews.llvm.org/D5871 But I don't think that will help. OperatingSystemGo::UpdateThreadList is getting called with the wrong real_thread_list the first time lldb stops.
This seems to fix it: diff --git a/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp b/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp index 3ab8c18..174d3e7 100644 --- a/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp +++ b/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp @@ -790,6 +790,8 @@ ProcessGDBRemote::DoConnectRemote (Stream *strm, const char *remote_url) } const StateType state = SetThreadStopInfo (response); + m_stop_packet_stack.clear(); + if (state == eStateStopped) { SetPrivateState (state); @@ -1080,6 +1082,7 @@ ProcessGDBRemote::DoLaunch (Module *exe_module, ProcessLaunchInfo &launch_info) } SetPrivateState (SetThreadStopInfo (response)); + m_stop_packet_stack.clear(); if (!disable_stdio) { -- Ryan Brown On Mon, Jun 1, 2015 at 12:53 PM, Greg Clayton <gclay...@apple.com> wrote: > One question for you: > > Are you associating your real threads with Go threads? Or are you letting > the real threads show and also showing the go threads? Any ThreadMemory > that has had ThreadMemory::SetBackingThread() called with a real thread > will be just a thread that is in memory. Any that have had this function > called with answer all thread related questions using the > ThreadMemory::m_backing_thread_sp. For any threads that aren't backed by a > real thread the thread registers will be created by calling > OperatingSystemGo::CreateRegisterContextForThread(...) so you should be > able to debug what is going wrong by stepping through this. For any threads > that are backed by a real thread, it will just get the register context > from the real thread via ThreadGDBRemote. > > If you can send me a copy of your OperatingSystemGo.cpp and .h file I > might be able to help out. > > Greg > > > On May 28, 2015, at 5:43 PM, Ryan Brown <rib...@google.com> wrote: > > > > I'm running into some issues trying to debug with lldb on linux. > > It started with errors that debugserver aborted. I ran lldb-server > manually and then used process connect, and got this error: > > > > lldb-server: > ../tools/lldb/source/Plugins/Process/Linux/NativeThreadLinux.cpp:227: > virtual NativeRegisterContextSP > lldb_private::process_linux::NativeThreadLinux::GetRegisterContext(): > Assertion `reg_interface && "OS or CPU not supported!"' failed. > > > > I synced lldb and llvm to head and rebuilt, and this error went away. > But then later it showed up again on a different machine when debugging the > same binary with the newly built lldb. > > > > Once I get the binary running under lldb I'm seeing strange things on my > OperatingSystem plugin. Sometimes things work normally, sometimes the OS > plugin seems to see incorrect register values but they're correct at the > lldb prompt, and sometimes the registers just seem completely wrong. > > The behaviour is pretty consistent when I set a breakpoint at the same > line, but if I move it to a different line or move to a different machine > I'll get a different behavior. > > > > Here's an example where the plugin sees invalid registers: > > (lldb) run > > OperatingSystemGo::UpdateThreadList(0, 1, 1) fetching thread data from > Go for pid 678 > > Process 678 launched: 'vc.test' (x86_64) > > I0528 17:09:01.105108 678 rand.go:86] Seeding pseudo-random number > generator with 1432858141105104474 > > OperatingSystemGo::UpdateThreadList(1, 1, 1) fetching thread data from > Go for pid 678 > > OperatingSystemGo: RealThread 0 has sp 7fffffffd430 > > Process 678 stopped > > * thread #1: tid = 0x02a6, 0x000000000049f379 > vc.test`vc.createVCs(~r0=stream.XVC at 0x000000c208030668, ~r1=stream.XVC > at 0x000000c208030678) + 73 at xvc_test.go:23, name = > > 'vc.test', stop reason = breakpoint 1.1 > > frame #0: 0x000000000049f379 vc.test`vc.createVCs(~r0=stream.XVC at > 0x000000c208030668, ~r1=stream.XVC at 0x000000c208030678) + 73 at > xvc_test.go:23 > > (lldb) register read > > General Purpose Registers: > > rax = 0x000000c208030580 > > rbx = 0x0000000000000000 > > rcx = 0x000000c208001a40 > > rdx = 0x000000000095e678 vc.test`vc.TestXVC.f > > rdi = 0x0000000000000000 > > rsi = 0x000000c208030768 > > rbp = 0x0000000000abe578 main.statictmp_0002 + 312 > > rsp = 0x000000c208030500 > > r8 = 0x000000005567ae1d > > r9 = 0x0000000000000007 > > r10 = 0x000000000300c146 > > r11 = 0x000000000000007b > > r12 = 0x0000000000000025 > > r13 = 0x000000000095d840 vc.test`runtime.gcbits.3082880518 > > r14 = 0x0000000000000008 > > r15 = 0x0000000000000000 > > rip = 0x000000000049f379 vc.test`vc.createVCs + 73 at > xvc_test.go:23 > > rflags = 0x0000000000000246 > > cs = 0x0000000000000033 > > fs = 0x0000000000000000 > > gs = 0x0000000000000000 > > ss = 0x000000000000002b > > ds = 0x0000000000000000 > > es = 0x0000000000000000 > > > > So my plugin sees one real thread, but the SP is bogus: 7fffffffd430 > > When I print registers at the prompt i get the correct value: > 0x000000c208030500 > > > > Then I run stepi: > > > > (lldb) stepi > > OperatingSystemGo::UpdateThreadList(8, 3, 3) fetching thread data from > Go for pid 678 > > OperatingSystemGo: RealThread 0 has sp c2080304f8 > > OperatingSystemGo: RealThread 1 has sp 7ffff77f5df8 > > OperatingSystemGo: RealThread 2 has sp 7ffff6fb4d70 > > > > Now my plugin is getting three threads. But we've only gone one > instruction, so where are these other threads coming from? Thread 0 has the > correct SP this time, but not the other threads. > > Now that we've got the right SP value, the OS plugin is able to find the > memory thread which confuses the threadplan so it keeps running till it > hits a breakpoint: > > > > OperatingSystemGo::UpdateThreadList(9, 3, 3) fetching thread data from > Go for pid 678 > > OperatingSystemGo: RealThread 0 has sp c208030500 > > OperatingSystemGo: RealThread 1 has sp 7ffff77f5df8 > > OperatingSystemGo: RealThread 2 has sp 7ffff6fb4d70 > > Process 678 stopped > > * thread #8: tid = 0x0006, 0x000000000049f3b1 > vc.test`vc.createVCs(~r0=stream.XVC at 0x000000c208030668, ~r1=stream.XVC > at 0x000000c208030678) + 129 at xvc_test.go:24, stop reason = breakpoint 2.1 > > frame #0: 0x000000000049f3b1 vc.test`vc.createVCs(~r0=stream.XVC at > 0x000000c208030668, ~r1=stream.XVC at 0x000000c208030678) + 129 at > xvc_test.go:24 > > (lldb) > > > > Debugging the same binary on a different machine with the same lldb > binary, I get different behavior: > > > > (lldb) r > > There is a running process, kill it and restart?: [Y/n] y > > Process 127429 exited with status = 9 (0x00000009) > > OperatingSystemGo::UpdateThreadList(0, 1, 1) fetching thread data from > Go for pid 127449 > > Process 127449 launched: 'vc.test' (x86_64) > > I0528 17:10:43.950815 127449 rand.go:86] Seeding pseudo-random number > generator with 1432858243950810731 > > OperatingSystemGo::UpdateThreadList(1, 1, 1) fetching thread data from > Go for pid 127449 > > OperatingSystemGo: RealThread 0 has sp 7fffffffde50 > > Process 127449 stopped > > * thread #1: tid = 0x1f1d9, 0x00007ffff7ddb2d0, name = 'vc.test', stop > reason = signal SIGSTOP > > frame #0: 0x00007ffff7ddb2d0 > > -> 0x7ffff7ddb2d0: movq %rsp, %rdi > > 0x7ffff7ddb2d3: callq 0x7ffff7ddea70 > > 0x7ffff7ddb2d8: movq %rax, %r12 > > 0x7ffff7ddb2db: movl 0x221b17(%rip), %eax > > (lldb) register read > > General Purpose Registers: > > rax = 0x0000000000000000 > > rbx = 0x0000000000000000 > > rcx = 0x0000000000000000 > > rdx = 0x0000000000000000 > > rdi = 0x0000000000000000 > > rsi = 0x0000000000000000 > > rbp = 0x0000000000000000 > > rsp = 0x00007fffffffde50 > > r8 = 0x0000000000000000 > > r9 = 0x0000000000000000 > > r10 = 0x0000000000000000 > > r11 = 0x0000000000000000 > > r12 = 0x0000000000000000 > > r13 = 0x0000000000000000 > > r14 = 0x0000000000000000 > > r15 = 0x0000000000000000 > > rip = 0x00007ffff7ddb2d0 > > rflags = 0x0000000000000200 > > cs = 0x0000000000000033 > > fs = 0x0000000000000000 > > gs = 0x0000000000000000 > > ss = 0x000000000000002b > > ds = 0x0000000000000000 > > es = 0x0000000000000000 > > > > (lldb) bt > > * thread #1: tid = 0x1f1d9, 0x00007ffff7ddb2d0, name = 'vc.test', stop > reason = signal SIGSTOP > > * frame #0: 0x00007ffff7ddb2d0 > > > > > > This time the plugin gets the invalid register values, but when lldb > stops at the prompt things are still invalid. The rip is garbage, so lldb > doesn't recognize that it's hit a breakpoint and the backtrace is wrong. > > > > Any ideas what could be going on here, or how I can debug this? > > > > -- Ryan Brown > > _______________________________________________ > > lldb-dev mailing list > > lldb-dev@cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev