Re: [lldb-dev] [Release-testers] [9.0.0 Release] Release Candidate 6 is here
On Thu, 2019-09-19 at 16:51 +0200, Hans Wennborg via Release-testers wrote: > On Tue, Sep 17, 2019 at 4:05 PM Hans Wennborg wrote: > > Hello everyone, > > > > 9.0.0-rc6 was just tagged from the release_90 branch at r372100. In > > the Git monorepo, it's tagged as llvmorg-9.0.0-rc6. > > This has now been tagged as the final 9.0.0 release. In the Git > monorepo, it's tagged as llvmorg-9.0.0. > > The official release announcement will follow as soon as the source > tarballs and docs are ready on the web page. > > Testers: please start building the final binaries, and I'll add them > as they become ready. > I know it's too late to report problems but I'm wondering if anybody else sees additional test failures after switching from git checkout to source tarballs. I'm currently investigating as to why. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part ___ 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, > My model for this sort of tracing activity is that you are writing a fancy kind > of “step” operation. You would write a fancy step & record plan that would > proceed along however you wanted and log at each stop. Then your breakpoint > callback would just queue up this step-and-trace plan as its last act. That’s > what the Scripted ThreadPlans are for: > > https://lldb.llvm.org/use/python-reference.html#using-the-python-api-to-create-custom-stepping-logic How do I queue up the thread plan in the callback? Here's my attempt: https://gist.github.com/nkaretnikov/6ee00afabf73332c5a89eacb610369c2#file-scripted_step-py This is based on: https://github.com/llvm/llvm-project/blob/master/lldb/examples/python/scripted_step.py The original 'SimpleStep' class implementation works when run as: thread step-scripted -C scripted_step.SimpleStep Not sure if my current version of 'SimpleStep' is correct (I've made a few changes since testing via 'thread step-scripted'), but nothing happens (no prints on '__init__') when I add the class via 'StepUsingScriptedThreadPlan' in the callback. What's the proper way to do this? Or do I need to mimic one of the classes with a 'thread_plan.QueueThreadPlan*' method call? I couldn't figure out how to trace with anything besides the 'SimpleStep' class when running via 'thread step-scripted', so I stuck with it. > I’m not quite sure what you are describing with the process events approach. > Are you trying to do this while also running in the lldb driver, or can you > write a stand-alone tool to do this? If the latter, then it should be enough > to program everything at the event loop level. You will know when your > breakpoint is hit, then you can issue the steps one by one and do whatever > logging you want each time you stop. I’m not sure why this would need events > sent from the breakpoint callback. Nevermind the events thing, then. I just run the lldb command and then do: command script import $FILE Ideally, I want to keep it this way so I could debug manually if needed. Thanks, Nikita ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
