[lldb-dev] Is it ok to use lldb_private from the driver?
Zachary Turner via lldb-dev
lldb-dev at lists.llvm.org
Sun Mar 20 08:25:26 PDT 2016
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
On Sun, Mar 20, 2016 at 7:02 AM Pavel Labath <labath at google.com> wrote:
> 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
> 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.
> On 18 March 2016 at 17:44, Greg Clayton via lldb-dev
> <lldb-dev at lists.llvm.org> wrote:
> >> On Mar 18, 2016, at 10:20 AM, Zachary Turner via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> >> 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
> >> On Fri, Mar 18, 2016 at 10:16 AM Jim Ingham <jingham at apple.com> wrote:
> >> 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
> >> Jim
> >> > 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? 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.
> >> > _______________________________________________
> >> > lldb-dev mailing list
> >> > lldb-dev at lists.llvm.org
> >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >> _______________________________________________
> >> lldb-dev mailing list
> >> lldb-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev