SB API questions


I’ve recently been working on and with my Rust bindings to the public LLDB API after a break of a couple of years.

A couple of things that I’m noticing or re-noticing:

We need more SB API coverage of logging functionality. We can’t list channels, categories via the SB API. We also don’t have a call for disabling log output once it has been enabled. These seem fairly straightforward to add.

While the underlying platform objects support finding processes, this isn’t exposed to the SB API, so there’s no way to get a nice list of the running processes using only the SB API. Has anyone looked at this or thought about the API?

It would be helpful in some cases, especially with the above, to extend SBProcessInfo to include arguments / argv, environment, and architecture. These are already present in the underlying data, just not exposed via SBProcessInfo.

Any thoughts or objections on the above? Would patches be welcome?

Are there others using the SB API a lot that might be willing to discuss this sort of stuff more?

  • Bruce

I think patches are always welcome and I don't see any problems with
the proposed new API (haven't really checked though if they are all
unavailable* through the SB API). The only downside to extending the
SB API is that we have to maintain it forever. So if we add an API
then it should be abstract enough that it doesn't restrict future
development of LLDB too much. Future development = internal
refactoring or porting to new platforms.

And I think the best way to propose a new API is maybe just making a
dummy patch that adds the API + documentation (doesn't need an actual
implementation or tests). And if everyone agrees the new API is fine
you can add the tests and implementation. By making a patch you also
automatically get everyone subscribed to your patch via Herald rules
or people reading the mailing list.

If you don't want to make patches, I think bug reports on could also work. Most of the thing you describe sound
like they don't need a lot of effort to implement/test, so there's a
good chance someone will implement it for you.

- Raphael

*Without falling back to the CommandInterpreter

I’ve just created for one of the pieces. I used to have commit access, but the last time I used it was before the move to GitHub, so I don’t mind doing the work and landing things myself … I don’t want to create much of a burden on others!

Thanks for your feedback!

  • Bruce

Thanks! In the spirit of not letting users fix our bugs, I just made a draft patch for the logging enable/disable:

I don’t think landing code is much of a burden, but I think you can just re-request commit access if you had it before.


  • Raphael