[Lldb-commits] [lldb] [LLDB] Add SBProgress so Python scripts can also report progress (PR #119052)

Pavel Labath via lldb-commits lldb-commits at lists.llvm.org
Tue Dec 10 06:15:34 PST 2024


labath wrote:

> The counter-argument is that nothing can prevent users from reporting arbitrary data and making it look like it originates from LLDB.

I think we need to distinguish two kinds of users here. The first one are the ones that sit "outside" of lldb and use the SB API to debug something (in a scripted manner). For these, I think I'd agree with you.

It's gets trickier with the other kind -- the ones running "inside" lldb. Here I include all the data formatters, stop hooks and other kinds of (python) callbacks. I can see how one would may want to report progress from inside these and have it go wherever the usual progress reports go (meaning, the console, if you're running  lldb CLI; the dap connection if you happen to be running in lldb-dap; or whatever happens in xcode).

That said, I can also see how the consumer might want to treat these progress events differently from "core" lldb events, so using a different bit for these makes sense as well. For example, the consumer may want/need to be prepared to handle progress objects that never terminate (the complete event is never sent).

At that point, I suppose one can ask the question whether this functionality should be built on top of the Progress class (as opposed to e.g. direct SBListener/SBEvent broadcasts). For me, it's main value lies in its RAII nature (*), but that's something we can't guarantee for python anyway. 

So yeah, I think an RFC would be nice.

(*) https://github.com/llvm/llvm-project/pull/119377 changes that somewhat, but I would hope that no python script is emitting events at such a frequency that this would be needed -- or if it is, I'd hope it could be implemented in a more traditional manner (i.e., with a mutex).

https://github.com/llvm/llvm-project/pull/119052


More information about the lldb-commits mailing list