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 > On Mar 18, 2016, at 10:20 AM, Zachary Turner <ztur...@google.com> 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. > > The idea is that instead of writing signal() everywhere, we would write > lldb_private::Host::Signal() everywhere instead. > > On Fri, Mar 18, 2016 at 10:16 AM Jim Ingham <jing...@apple.com > <mailto: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 <mailto: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 <mailto:lldb-dev@lists.llvm.org> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > <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
