[lldb-dev] Is it ok to use lldb_private from the driver?
Zachary Turner via lldb-dev
lldb-dev at lists.llvm.org
Fri Mar 18 10:21:02 PDT 2016
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 <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> 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.
>> > On Mar 18, 2016, at 9:54 AM, Zachary Turner via lldb-dev <
>> 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
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev