[lldb-dev] Is it ok to use lldb_private from the driver?

[Zachary Turner via lldb-dev]

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
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
> 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.
>
>
>
>
> 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
> abstraction?
> >
> >>
> >> 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
> me.
> >>
> >> 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...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160320/0518da35/attachment-0001.html>