Note this would also fix several longstanding warnings when compiling on windows that there's really no other way to fix.
On Fri, Mar 18, 2016 at 10:19 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> 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