[lldb-dev] Call python script on stop?

Zachary Turner zturner at google.com
Thu Sep 11 15:44:56 PDT 2014 

lldb.debugger should work on Windows, but python still has some kinks to
work out on Windows, definitely.  For starters, "script print" doesn't work
on Windows.  I know how to fix it, but I'm just not there yet and it's a
large fix.

Any chance you want to just try fixing this python stuff on Windows
instead?  :)

On Thu, Sep 11, 2014 at 2:25 PM, Ted Woodward <ted.woodward at codeaurora.org>
wrote:

> I think I found the problem. I'm running on Windows. :-)
>
> OK, the real problem:
> (lldb) script print lldb.debugger
> No value
>
> I tried passing the debugger as a variable, but that crashes on both
> Windows and Linux.
>
> My code looks like:
>
> def __lldb_init_module(debugger, dict):
>   debugger.HandleCommand('command script add -f vregwin.vrs vrs')
>
> def vrs(debugger, command, result, dict):
>   foo = thread.start_new_thread(vregwin, (debugger,))
>
> def vregwin(debugger):
>   result = lldb.SBCommandReturnObject()
>   debugger.GetCommandInterpreter().HandleCommand('help gdb-remote', result)
>   print result.GetOutput()
>   print result.GetError()
>
>
> A "print debugger" in there gives:
> Debugger (instance: "HÄ]ÃåHì@", id: 140736691407232)
>
> So I need to use lldb.debugger, which doesn't work on Windows. I guess
> I'll switch to Linux.
>
> Ted
>
> -----Original Message-----
> From: Greg Clayton [mailto:gclayton at apple.com]
> Sent: Wednesday, September 10, 2014 3:25 PM
> To: Ted Woodward
> Cc: Jim Ingham; lldb-dev at cs.uiuc.edu
> Subject: Re: [lldb-dev] Call python script on stop?
>
>
> > On Sep 10, 2014, at 1:00 PM, Ted Woodward <ted.woodward at codeaurora.org>
> wrote:
> >
> > Let me back up a little - I'm running this from lldb, not python.
>
> Ah, gotcha.
>
> > Ultimately I want to have lldb run from eclipse, connected to a gdb
> server, but use python to pop up TK windows so we can enhance the gui
> without having to write  eclipse java code.
>
> Got it.
>
> > I've got my script creating the TK window, and I can populate the window
> by reading registers. Then I moved the window code to another thread, but
> now I can't read registers.
>
> Many windowing frameworks require UI updates happen on a specific thread.
> I am not sure if you are running into such a problem here. There should be
> nothing stopping you from being able to read registers from another thread.
> You will need to make sure your target is stopped (otherwise the register
> read will fail saying the process is running).
>
> > I'm connected to the gdb server, and can read registers from the command
> line. I pass the debugger in to my handler code in the other thread, and
> lldb crashes when I try to access it.
>
> That shouldn't happen if you have a valid debugger handle.
>
> > If I create a new debugger instead, I get "error: invalid frame".
>
> Each debugger has a target list:
>
> debugger
>    target = 0x11110000
>    target = 0x22220000
>
> Each target may or may not have a process
>
> debugger
>    target = 0x11110000
>        process = 0x12340000
>    target = 0x22220000
>        process = 0x00000000
>
> Then each process, if valid might have one or more threads and one or more
> frames within each thread:
>
> debugger
>    target = 0x11110000
>        process = 0x12340000
>             thread 1 = 0x12310000
>             thread 2 = 0x12310000
>                 frame[0] = 0x123092302
>                 frame[1] = 0x223092302
>    target = 0x22220000
>        process = 0x00000000
>
>
> So there is no reason to create a new debugger, it won't contain anything.
> You need to access the current debugger. If you are running through the
> embedded python interpreter, you can just use "lldb.debugger". That will
> always be correct for your current session.
>
> >
> > How do I start up a new thread, but access the debugger on the main
> thread, which is attached to the remote gdb server?
>
> All LLDB code is multi-theaded so you should be able to read registers on
> any thread. You need to make sure you have good instances:
>
> (lldb) script print lldb.debugger
> Debugger (instance: "debugger_1", id: 1)
>
>
> When you print the debugger, you get valid text. You should also validate
> that you have valid target, process, thread, and frame objects before you
> use them.
>
> Maybe you can post the code that is using the debugger to get the current
> target, and how you are getting the thread and frame that you are getting
> registers from?
>
> Greg
> >
> > -----Original Message-----
> > From: Greg Clayton [mailto:gclayton at apple.com]
> > Sent: Tuesday, September 09, 2014 7:08 PM
> > To: Ted Woodward
> > Cc: Jim Ingham; lldb-dev at cs.uiuc.edu
> > Subject: Re: [lldb-dev] Call python script on stop?
> >
> > You would use two python threads.
> >
> > Info on python threads:
> >
> > http://www.tutorialspoint.com/python/python_multithreading.htm
> >
> > You would make one thread run your command prompt code, and one thread
> just consuming events. You would make a function in python:
> >
> >
> > def lldb_event_thread():
> >    ....
> >
> >
> > And the code inside lldb_event_thread would be consuming the events
> (copy code from process_events.py).
> >
> > You actually might want 3 thread:
> > 1 - main thread that waits for anything from the two other threads
> > 2 - command prompt thread
> > 3 - event thread
> >
> >
> >
> >> On Sep 9, 2014, at 4:43 PM, Ted Woodward <ted.woodward at codeaurora.org>
> wrote:
> >>
> >> Can I do that from inside lldb, or are we talking another python
> process? If inside lldb, how do I do that?
> >>
> >> -----Original Message-----
> >> From: Greg Clayton [mailto:gclayton at apple.com]
> >> Sent: Tuesday, September 09, 2014 6:35 PM
> >> To: Ted Woodward
> >> Cc: Jim Ingham; lldb-dev at cs.uiuc.edu
> >> Subject: Re: [lldb-dev] Call python script on stop?
> >>
> >> You will need to launch another python thread, and in that thread,
> handle all events just like the process_events.py script.
> >>
> >>
> >>> On Sep 9, 2014, at 4:31 PM, Ted Woodward <ted.woodward at codeaurora.org>
> wrote:
> >>>
> >>> Is there a way to launch another lldb thread, so I have the command
> prompt and a python script running at the same time?
> >>>
> >>> -----Original Message-----
> >>> From: jingham at apple.com [mailto:jingham at apple.com]
> >>> Sent: Tuesday, September 09, 2014 5:38 PM
> >>> To: Greg Clayton
> >>> Cc: Ted Woodward; lldb-dev at cs.uiuc.edu
> >>> Subject: Re: [lldb-dev] Call python script on stop?
> >>>
> >>> Yes, you definitely want to handle events yourself.  The target stop
> hooks are fine for printing some variables and threads, etc, but I wouldn't
> try to update your GUI, etc, from there.
> >>>
> >>> Jim
> >>>
> >>>> On Sep 9, 2014, at 3:22 PM, Greg Clayton <gclayton at apple.com> wrote:
> >>>>
> >>>>
> >>>>> On Sep 9, 2014, at 1:36 PM, Ted Woodward <
> ted.woodward at codeaurora.org> wrote:
> >>>>>
> >>>>> I’m working on a simple python gui proof-of-concept. I’m going to
> use the Tkinter module to open a Tk window that displays registers. I’d
> like to have it auto-update when the target stops.
> >>>>>
> >>>>> Is there a way to automatically call a python script when a target
> stops, and to call another (to clean up) when the target is killed?
> >>>>
> >>>> Why not just consume the events yourself?
> >>>>
> >>>> See the following sample python code:
> >>>>
> >>>> svn cat
> http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py
> >>>>
> >>>> There is a "target stop-hook" command you could use:
> >>>>
> >>>> (lldb) help target stop-hook
> >>>>
> >>>> But I would suggest consuming the events on another thread from
> python, or just making a polling loop where you want for events for a
> specified amount of time.
> >>>>
> >>>> Greg
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> lldb-dev mailing list
> >>>> lldb-dev at cs.uiuc.edu
> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >>>
> >>>
> >>
> >>
> >
> >
>
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140911/48ecce92/attachment.html>

More information about the lldb-dev mailing list