Re: [lldb-dev] Stepping in a breakpoint callback with Python
So the problem you are having is getting the scripted step started in "trace" with the SBThread::StepUsingScriptedStep? Did you try passing False for "resume_immediately" and then returning False from "trace". The explanation for: # XXX: Doesn't seem to matter with 'thread step-scripted'. # return False # continue return True # stop is that the return value from the breakpoint command only matters if you haven't already started the process running again, which you have with the "thread step-scripted" command. But if you pass resume_immediately -> False to StepUsingScriptedStep, then that will just queue the thread plan but not start the process going again. Then the restart will be in a more orderly place in lldb. All the commands that can resume the process really need to have a "do it now" and a "request to do this" mode. In breakpoint commands and the like, they should use the latter mode (a) so we can do a better job of arbitrating "I hit two breakpoints, A wants to continue but B wants to stop" and (b) so we don't have to deal with the complexities of restarting when we aren't quite done with handling the last stop. But for now you have to be a little careful in breakpoint callbacks. Jim > On Sep 27, 2019, at 8:33 AM, Nikita Karetnikov wrote: > > Jim, > > > Does that simple use of the scripted plan also work for you? > > No, that doesn't work for me. My original script does more stuff, so I need > to > pass the state via global variables. > > However, I think I've figured out a way to do what I want: > https://gist.github.com/nkaretnikov/75c8a0b814246b322d562e7333eb4ba9 > > Let me know if you find a way to do this via the Python API. > > Thanks, > Nikita > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Stepping in a breakpoint callback with Python
Jim, > Does that simple use of the scripted plan also work for you? No, that doesn't work for me. My original script does more stuff, so I need to pass the state via global variables. However, I think I've figured out a way to do what I want: https://gist.github.com/nkaretnikov/75c8a0b814246b322d562e7333eb4ba9 Let me know if you find a way to do this via the Python API. Thanks, Nikita ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb warning or developer options
Hi Pavel, Thanks for sharing this, I'll look into this. -- Sourabh Singh Tomar On Fri, Sep 27, 2019 at 12:18 PM Pavel Labath wrote: > On 27/09/2019 07:52, Sourabh Singh Tomar via lldb-dev wrote: > > Hi Folks, > > > > Is their a developer switch or diagnostic switch, that we can set in > > lldb, to show warnings and other useful stuff when lldb process the > > binary, building table and utilizing DWARF. > > > > I stumble upon, a rather trivial test case. where I deleted the *.dwo > > file. and loaded primary binary in lldb. lldb loaded it silently without > > any error or diagnostic reports for not found *.dwo file. Obviously, > > debug data wasn't loaded, as I entered list command, nothing happened. > > > > Why need this, as new dwarf-5 features are in development, if lldb can > > report some diagnostics like section not found or ill-formed section, > > this would be immensely useful . > > > > Thanks! > > -- Sourabh Singh Tomar > > > > Hi Sourabh, > > there the Module::ReportWarning function, which will print a warning (to > stderr generally). We should probably make use of that functionality to > report missing dwo files. Care to put up a patch? > > pl > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb warning or developer options
On 27/09/2019 07:52, Sourabh Singh Tomar via lldb-dev wrote: Hi Folks, Is their a developer switch or diagnostic switch, that we can set in lldb, to show warnings and other useful stuff when lldb process the binary, building table and utilizing DWARF. I stumble upon, a rather trivial test case. where I deleted the *.dwo file. and loaded primary binary in lldb. lldb loaded it silently without any error or diagnostic reports for not found *.dwo file. Obviously, debug data wasn't loaded, as I entered list command, nothing happened. Why need this, as new dwarf-5 features are in development, if lldb can report some diagnostics like section not found or ill-formed section, this would be immensely useful . Thanks! -- Sourabh Singh Tomar Hi Sourabh, there the Module::ReportWarning function, which will print a warning (to stderr generally). We should probably make use of that functionality to report missing dwo files. Care to put up a patch? pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
