> 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
