[lldb-dev] Status of prettyprint via MI

[Red Skotina via lldb-dev]

How i can use prettyprint for STL structures via MI (lldb-mi)?
Have it is difference from gdb ?
It is implemented?

I use lldb at windows and want use lldb-mi like gdb via MI inside IDE
Codelite with pretty printing of stl structures.

I can now do basic debug with lldb-mi, but when try examine variables take
some errors.

DEBUG>>0199-var-create - @ "vector_of_obj"
DEBUG>>0199^error,msg="Command 'var-create'. Option 'frame' not found"

It is just not implemented or dynamic variables cant used ?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Status of prettyprint via MI

[Zachary Turner via lldb-dev]

I can think of two problems with this scenario.

First, it depends what implementation of STL you're using.  If you're using
clang-cl or MSVC to compile your program, then you're getting the MSVC STL,
and we don't have any data formatters implemented for those yet.  It will
happen eventually, but no definite time frame yet.

Second, there are a number of general issues with dynamic variables on
windows, even if we did have data formatters for STL.  Simple types should
work but some things will have odd behavior.

I'm not sure if you just want to use LLDB and have it work, or if you're
interested in contributing.  But we're more than happy to have patches.
Otherwise we'll get to it eventually

On Sun, Feb 7, 2016 at 10:25 AM Red Skotina via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> How i can use prettyprint for STL structures via MI (lldb-mi)?
> Have it is difference from gdb ?
> It is implemented?
>
> I use lldb at windows and want use lldb-mi like gdb via MI inside IDE
> Codelite with pretty printing of stl structures.
>
> I can now do basic debug with lldb-mi, but when try examine variables take
> some errors.
>
> DEBUG>>0199-var-create - @ "vector_of_obj"
> DEBUG>>0199^error,msg="Command 'var-create'. Option 'frame' not found"
>
> It is just not implemented or dynamic variables cant used ?
>
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Why is storing SBTarget in a private field causing random crash?

[Jeffrey Tan via lldb-dev]

Hi,

I have been spending long time troubleshooting a race condition in our lldb
python test. I finally narrowed down to one code change that caused the
race: basically, whenever I store SBTarget in DebuggerTestCase's
self.target field lldb will randomly crash during destruction(see below).

In the code, if I modify the two "self.target" to local variable "target"
the random crash will disappear.

I am not a python expert. Why is holding SBTarget will cause the test to
random crash? Do I have to set every SBXXX fields to None before
calling SBDebugger.Destroy()?


==Crash Stack==
Crashed Thread:0  Dispatch queue: com.apple.main-thread

Exception Type:EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:   KERN_INVALID_ADDRESS at 0x0010

VM Regions Near 0x10:
-->
__TEXT 00010d145000-00010d146000 [4K]
r-x/rwx SM=COW
 
/System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.LLDB.framework   0x0001101c037d
lldb_private::Listener::BroadcasterWillDestruct(lldb_private::Broadcaster*)
+ 95
1   com.apple.LLDB.framework   0x0001101a0da2
lldb_private::Broadcaster::Clear() + 50
2   com.apple.LLDB.framework   0x0001101a0ced
lldb_private::Broadcaster::~Broadcaster() + 75
3   com.apple.LLDB.framework   0x0001103d6879
lldb_private::Target::~Target() + 741
4   com.apple.LLDB.framework   0x0001103d6c20
lldb_private::Target::~Target() + 14
5   libc++.1.dylib 0x7fff896448a6
std::__1::__shared_weak_count::__release_shared() + 44
6   com.apple.LLDB.framework   0x00010e560664
_wrap_delete_SBTarget(_object*, _object*) + 123
7   org.python.python 0x00010d15a50a PyObject_Call + 99


==Code==
from find_lldb import lldb
from simplest_event_thread import LLDBListenerThread
import unittest
import threading

running_signal = threading.Event()
stopped_signal = threading.Event()

def launch_debugging(debugger, stop_at_entry):
error = lldb.SBError()
listener = lldb.SBListener('Chrome Dev Tools Listener')
target = debugger.GetSelectedTarget()
process = target.Launch (listener,
None,  # argv
None,  # envp
None,  # stdin_path
None,  # stdout_path
None,  # stderr_path
None,  # working directory
0, # launch flags
stop_at_entry,  # Stop at entry
error) # error
print 'Launch result: %s' % str(error)

event_thread = LLDBListenerThread(debugger, running_signal,
stopped_signal)
event_thread.start()

running_signal.set()
return event_thread

class DebuggerTestCase:

def wait_for_process_stop(self):
running_signal.wait()
running_signal.clear()
stopped_signal.wait()
stopped_signal.clear()

def test_breakpoint_at_line(self):
debugger = lldb.SBDebugger.Create()
debugger.SetAsync(True)
executable_path =
'~/Personal/compiler/CompilerConstruction/code/compiler'
*self.target* =
debugger.CreateTargetWithFileAndArch(executable_path,
lldb.LLDB_ARCH_DEFAULT)

event_thread = launch_debugging(debugger, stop_at_entry=True)

process = debugger.GetSelectedTarget().process
self.wait_for_process_stop() # wait for entry breakpoint.
*self.target*.BreakpointCreateByName('main')
process.Continue()
self.wait_for_process_stop() # wait for main breakpoint.

event_thread.should_quit = True
event_thread.join()
lldb.SBDebugger.Destroy(debugger)

if __name__ == '__main__':
test = DebuggerTestCase()
for i in range(20):
test.test_breakpoint_at_line()
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev