I notice everything uses SB classes only. Is this a hard requirement? 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.
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:
bool
CMICmdCmdExecContinue::Execute()
{
const char *pCmd = "continue";
CMICmnLLDBDebugSessionInfo &rSessionInfo(CMICmnLLDBDebugSessionInfo::Instance());
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:
bool
CMICmdCmdExecContinue::Execute()
{
CMICmnLLDBDebugSessionInfo &rSessionInfo(CMICmnLLDBDebugSessionInfo::Instance());
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.
The driver used to have a bunch of lldb_private stuff in it, mostly to run the event loop, which Greg abstracted into SB API’s a while ago. If it can be avoided, I’d rather not add it back in. Our claim is folks should be able to write their own debugger interfaces (command line or gui) using the SB API’s, so it would be good if we stuck to that discipline as well.
I thought that the lldm-mi was pure SB API’s. That seemed a virtue to me.
Jim
Is it ok to add a public API that isn’t interfaced to Python? In this case the culprit is the signal() function. Windows doesn’t really support signal in the same way that other platforms do, so there’s some code in each driver that basically defines a signal function, and then if you’re unlucky when you build, or accidentally include the wrong header file (even indirectly), you’ll get multiply defined symbol errors.
So what I wanted to do was make a Host::Signal() that on Windows had our custom implementation, and on other platforms just called signal. But it returns and accepts function pointers, and making this work through the python api is going to be a big deal, if not flat out impossible.
The idea is that instead of writing signal() everywhere, we would write lldb_private::Host::Signal() everywhere instead.
Note this would also fix several longstanding warnings when compiling on windows that there’s really no other way to fix.
If I were writing a Pure Python interface to lldb, could I use the Python signal facilities to abstract the functionality you are trying to abstract through Host::Signal? If so, then I’d have no objection to only doing it in the C++ API’s (maybe with a note to that effect in the headers.)
If not, as long as what you are doing didn’t preclude somebody implementing a Python version later if they were sufficiently motivated, I don’t think it would be a requirement on you to do it now.
Jim
Is it ok to add a public API that isn't interfaced to Python? In this case the culprit is the signal() function. Windows doesn't really support signal in the same way that other platforms do, so there's some code in each driver that basically defines a signal function, and then if you're unlucky when you build, or accidentally include the wrong header file (even indirectly), you'll get multiply defined symbol errors.
So what I wanted to do was make a Host::Signal() that on Windows had our custom implementation, and on other platforms just called signal. But it returns and accepts function pointers, and making this work through the python api is going to be a big deal, if not flat out impossible.
Why is this an issue in Python? Doesn't python abstract this for you? Or is it just a NOP on windows??
The idea is that instead of writing signal() everywhere, we would write lldb_private::Host::Signal() everywhere instead.
Is this just to get a callback when a certain signal is sent to a process, like to handle SIGINT?
Why this is hard to hook through SBHostOS if python doesn't provide an abstraction?
Are using we using any other signal that SIGINT on windows currently?
I seem to remember all the fancy signals (SIGTSTP, SIGWINCH,...) being
ifdef-ed out on windows. If the only signal we are interested about if
SIGINT, then I think the API should be more higher-level than a
signal() wrapper (SBHostOS::SetInterruptionHandler ?), since you're
never going to get that to behave portably. If there are other signals
used, then I'd be interesting in what they are and how they work on
windows.
Another thing: our current signal-handling code is pretty far from
being signal-safe. I was actually considering replacing the current
signal triggering mechanism with something makes sure the execution
happens on a separate thread (on POSIX you can do this with pselect or
sigwait, on windows we have this semantics already IIUC). It would be
great if any API added here did not preclude this.
All the signals were being used on Windows, but our custom implementation ignored other signals. I changed it to simply ifdef out the places where we set other signal handlers. I’d be fine with a higher level mechanism as well though