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

[Jim Ingham via lldb-dev]

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 <zturner at 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 <jingham at apple.com <mailto: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 <mailto: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 <mailto:lldb-dev at lists.llvm.org>
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev <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/20160318/a9a5da4c/attachment.html>