[lldb-dev] Is it ok to use lldb_private from the driver?
Greg Clayton via lldb-dev
lldb-dev at lists.llvm.org
Fri Mar 18 10:16:02 PDT 2016
> On Mar 18, 2016, at 9:54 AM, Zachary Turner via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> I notice everything uses SB classes only. Is this a hard requirement?
I would prefer to try and get all of our tools to use the public API if at all possible and avoid pulling in lldb_private stuff for things like "lldb" and "lldb-mi". "lldb-server" isn't included in these as it is designed to not use the public API at all.
> We have a bit of cruft in all of the top-level executables (lldb-server, lldb-mi, lldb) that could be shared if we could move it into Host, but then the 3 drivers would have to #include "lldb/Host/Host.h". Note that lldb-mi and lldb-server already do this, it's only lldb that doesn't. Is this ok?
> If not, I can always add a method to SBHostOS and just not add a corresponding swig interface definition for it (so it wouldn't be accessible from Python), which would achieve basically the same effect.
Do you know what calls lldb-mi is cheating on? I don't believe the driver cheats on anything and it would be great to get "lldb-mi" to be clean as well. Speaking on lldb-mi, there are a bunch of places that the lldb-mi code is running text commands instead of using the public API. I believe "exec-continue" shows this quite nicely:
const char *pCmd = "continue";
const lldb::ReturnStatus rtn = rSessionInfo.GetDebugger().GetCommandInterpreter().HandleCommand(pCmd, m_lldbResult);
So this shows how little lldb-mi is actually using our public API. This should be:
SBError error = rSessionInfo.GetProcess().Continue();
So I would vote to add stuff to the public API via SBHostOS if possible. What kinds of things are you needing?
Let me know what you are missing so we can figure out which way to go.
More information about the lldb-dev