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

[Zachary Turner via lldb-dev]

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.
>>
>> Jim
>>
>> > 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...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160318/ddc6120e/attachment-0001.html>