Works for me with top of tree: % PYTHONPATH=/tmp/lldb/build/Debug/LLDB.framework/Resources/Python ; ./foo.py ) Creating a target for './a.out' SBBreakpoint: id = 1, name = 'main', module = a.out, locations = 1 SBProcess: pid = 62855, state = stopped, threads = 1, executable = a.out thread #1: tid = 0x558f56, 0x000000010226bf74 a.out`main(argc=1, argv=0x00007fff5d994ec8) at main.cpp:15, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x000000010226bf74 a.out`main(argc=1, argv=0x00007fff5d994ec8) at main.cpp:15 SBFunction: id = 0x0000004b, name = main, type = main a.out[0x100000f60]: pushq %rbp a.out[0x100000f61]: movq %rsp, %rbp a.out[0x100000f64]: xorl %eax, %eax a.out[0x100000f66]: movl $0x0, -0x4(%rbp) a.out[0x100000f6d]: movl %edi, -0x8(%rbp) a.out[0x100000f70]: movq %rsi, -0x10(%rbp) a.out[0x100000f74]: popq %rbp a.out[0x100000f75]: retq
this is on a Mac though. Might be something specific to linux. Greg > On Feb 13, 2017, at 10:23 AM, Roman Popov <ripo...@gmail.com> wrote: > > Do you mean you were able to reproduce it? Because it is used to work on > trunk month ago, but since then I've switched from ubuntu 14.04 to fresh > 16.04 and it no longer works for me. > > 2017-02-13 21:21 GMT+03:00 Greg Clayton <gclay...@apple.com > <mailto:gclay...@apple.com>>: > I would be probably best to just step through it and see why it is > incorrectly returning. We know it is broken. We should also add a test for > this so we don't regress again. > > Greg > >> On Feb 13, 2017, at 10:19 AM, Roman Popov <ripo...@gmail.com >> <mailto:ripo...@gmail.com>> wrote: >> >> Yes Greg, this was my expectation that it should not return until stops on >> break-point. But I had to downgrade sequentially from 5.0 to 4.0 to 3.9 to >> make it work as expected. >> >> Can I get some diagnostics? Any log files? >> >> 2017-02-13 20:11 GMT+03:00 Greg Clayton <gclay...@apple.com >> <mailto:gclay...@apple.com>>: >> The example code is: >> >> #!/usr/bin/python >> >> import lldb >> import os >> >> def disassemble_instructions(insts): >> for i in insts: >> print i >> >> # Set the path to the executable to debug >> exe = "./a.out" >> >> # Create a new debugger instance >> debugger = lldb.SBDebugger.Create() >> >> # When we step or continue, don't return from the function until the process >> # stops. Otherwise we would have to handle the process events ourselves >> which, while doable is >> #a little tricky. We do this by setting the async mode to false. >> debugger.SetAsync (False) >> >> # Create a target from a file and arch >> print "Creating a target for '%s'" % exe >> >> target = debugger.CreateTargetWithFileAndArch (exe, lldb.LLDB_ARCH_DEFAULT) >> >> if target: >> # If the target is valid set a breakpoint at main >> main_bp = target.BreakpointCreateByName ("main", >> target.GetExecutable().GetFilename()); >> >> print main_bp >> >> # Launch the process. Since we specified synchronous mode, we won't >> return >> # from this function until we hit the breakpoint at main >> process = target.LaunchSimple (None, None, os.getcwd()) >> >> # Make sure the launch went ok >> if process: >> # Print some simple process info >> state = process.GetState () >> print process >> if state == lldb.eStateStopped: >> # Get the first thread >> thread = process.GetThreadAtIndex (0) >> if thread: >> # Print some simple thread info >> print thread >> # Get the first frame >> frame = thread.GetFrameAtIndex (0) >> if frame: >> # Print some simple frame info >> print frame >> function = frame.GetFunction() >> # See if we have debug info (a function) >> if function: >> # We do have a function, print some info for the >> function >> print function >> # Now get all instructions for this function and >> print them >> insts = function.GetInstructions(target) >> disassemble_instructions (insts) >> else: >> # See if we have a symbol in the symbol table for >> where we stopped >> symbol = frame.GetSymbol(); >> if symbol: >> # We do have a symbol, print some info for the >> symbol >> print symbol >> >> We set the async mode to false, so target.LaunchSimple() should not return >> until the process is stopped or exited. Note in your example it is returning >> with "state = launching", so this is what is failing. For some reason >> synchronous mode is not being obeyed. >> >> Greg >> >>> On Feb 11, 2017, at 10:07 AM, Roman Popov via lldb-dev >>> <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: >>> >>> I'm testing example from https://lldb.llvm.org/python-reference.html >>> <https://lldb.llvm.org/python-reference.html> (USING THE LLDB.PY MODULE IN >>> PYTHON) on Ubuntu 16.04 >>> >>> For some reason it works only with LLDB 3.9, is it because LLDB 4.0/5.0 are >>> not stable yet? >>> >>> #5.0 -- Does not work >>> deb http://apt.llvm.org/xenial/ <http://apt.llvm.org/xenial/> >>> llvm-toolchain-xenial main >>> # 3.9 -- Works >>> deb http://apt.llvm.org/xenial/ <http://apt.llvm.org/xenial/> >>> llvm-toolchain-xenial-3.9 main >>> # 4.0 -- Does not work >>> deb http://apt.llvm.org/xenial/ <http://apt.llvm.org/xenial/> >>> llvm-toolchain-xenial-4.0 main >>> >>> >clang-5.0 -g test.cpp >>> >./python_example.py >>> Creating a target for './a.out' >>> SBBreakpoint: id = 1, name = 'main', locations = 1 >>> SBProcess: pid = 0, state = launching, threads = 0, executable = a.out >>> Thanks, >>> Roman >>> _______________________________________________ >>> lldb-dev mailing list >>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> <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
