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 <lab...@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@lists.llvm.org> wrote: > > > >> On Mar 18, 2016, at 10:20 AM, Zachary Turner via lldb-dev < > lldb-dev@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 <jing...@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@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@lists.llvm.org > >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > >> > >> _______________________________________________ > >> lldb-dev mailing list > >> lldb-dev@lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > > _______________________________________________ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
