Also, if you are writing a command, don't forget to restore the old async status on the way out of your command.
Jim > On Aug 13, 2014, at 11:22 AM, [email protected] wrote: > > That's to be expected. After all, SBProcess.Continue() is a scripting > function that continues the process, you wouldn't want that to print stop > information to stdout, that isn't an appropriate thing for a lower level > function to do. > > You can use SBThread::GetStatus to print the stop status of the thread in the > same way the command interpreter does when it stops at a thread, if that is > what you want your command to do. If you are writing a Python based command, > the correct way to do this is to set the status into the result object of > your command. > > Jim > > > >> On Aug 13, 2014, at 10:43 AM, Ted Woodward <[email protected]> >> wrote: >> >> It's hitting the breakpoint: >> >> Process 1 stopped >> * thread #1: tid = 0x0001, 0x00004130 factorial`main(argc=1, >> argv=0x0000b100) + 28 at factorial.c:32, stop reason = breakpoint 1.1 >> frame #0: 0x00004130 factorial`main(argc=1, argv=0x0000b100) + 28 at >> factorial.c:32 >> 29 } >> 30 */ >> 31 >> -> 32 base = 10; >> 33 >> 34 printf("Factorial of %d is %d\n", base, factorial(base)); >> 35 return 0; >> >> But I don't get the prompt. If I do debugger.SetAsync(False), it hits the >> breakpoint and gives me the prompt, but I don't get the source list that I >> expect when I hit a breakpoint. >> >> The process is launched - it's running on a simulator that I'm talking to >> using gdb-remote. >> >> Ted >> >> -----Original Message----- >> From: Greg Clayton [mailto:[email protected]] >> Sent: Tuesday, August 12, 2014 6:14 PM >> To: Ted Woodward >> Cc: Jim Ingham; [email protected] >> Subject: Re: [lldb-dev] python command returns different values in a script >> and interactively >> >> Your debugger is in synchronous mode which means process.Continue() won't >> return until your process stops. If you just want to run your target and not >> wait for it to stop try: >> >> debugger.SetAsync(False) >> >> then do your process.Continue() >> >> This should let your script exit and then catch the event back in the >> debugger when it does stop. Then CTRL+C should work as well. >> >> NOTE: process.Continue() won't work unless your process is already launched. >> Just wanted to make sure you weren't expecting it to launch your process. >> >> Greg >> >>> On Aug 12, 2014, at 3:58 PM, Ted Woodward <[email protected]> >>> wrote: >>> >>> That fixed it, thanks Jim! >>> >>> My next problem - I want to set a breakpoint at main and continue. This >>> works, but I don't get the lldb prompt back, and can't do debugging. My >>> code is: >>> >>> def start (debugger, register, result, dict): >>> run (debugger, register, result, dict) >>> target = debugger.GetSelectedTarget() >>> process = target.GetProcess() >>> target.BreakpointCreateByName("main") >>> process.Continue() >>> >>> ctrl-c doesn't break. I have to hit ctrl-z and kill lldb. >>> >>> Ted >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] >>> Sent: Tuesday, August 12, 2014 5:25 PM >>> To: Ted Woodward >>> Cc: [email protected] >>> Subject: Re: [lldb-dev] python command returns different values in a script >>> and interactively >>> >>> The lldb.{target,process,thread} globals are only set when running the >>> interactive script interpreter in the lldb "script" command. They aren't >>> available in other environments like the breakpoint commands, or Python >>> based user defined commands, etc. They are really just for convenience >>> when prototyping scripts. >>> >>> In some actual Python code you should have some clear way, depending on the >>> environment, what target you mean. For instance, if you are writing a >>> Python based lldb command, you might want to operate on the currently >>> selected target (which you can look up in the debugger passed in to you) or >>> you might want to look up a target by name, etc. In a breakpoint command >>> the relevant target will be the one which owns the process that owns the >>> frame that actually hit the breakpoint, etc... >>> >>> Jim >>> >>>> On Aug 12, 2014, at 3:15 PM, Ted Woodward <[email protected]> >>>> wrote: >>>> >>>> I’m trying to write a python script that will launch a simulator to run >>>> the current target. In my script, I’ve got this code: >>>> foo = lldb.target.GetExecutable().__get_fullpath__() >>>> print foo >>>> print type(foo) >>>> >>>> When I run it, I get this: >>>> None >>>> <type 'NoneType'> >>>> >>>> But if I run the same commands interactively, I get the right values: >>>> (lldb) script foo = lldb.target.GetExecutable().__get_fullpath__() >>>> (lldb) script print foo >>>> /usr2/ted/lldb_test/factorial >>>> (lldb) script print type(foo) >>>> <type 'str'> >>>> >>>> After calling lldb.target.GetExecutable().__get_fullpath__() >>>> interactively, my script starts to work. >>>> >>>> Why doesn’t it work in the script if I don’t call it interactively? How >>>> can I get it to work? >>>> >>>> Thanks, >>>> >>>> Ted >>>> _______________________________________________ >>>> lldb-dev mailing list >>>> [email protected] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> >>> >>> >>> _______________________________________________ >>> lldb-dev mailing list >>> [email protected] >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> >> > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
