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

2016-03-20 Thread Zachary Turner via lldb-dev
All the signals were being used on Windows, but our custom implementation ignored other signals. I changed it to simply ifdef out the places where we set other signal handlers. I'd be fine with a higher level mechanism as well though On Sun, Mar 20, 2016 at 7:02 AM Pavel Labath

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

2016-03-19 Thread Zachary Turner via lldb-dev
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

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

2016-03-19 Thread Greg Clayton via lldb-dev
> On Mar 18, 2016, at 10:20 AM, Zachary Turner via lldb-dev > 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

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

2016-03-19 Thread Zachary Turner via lldb-dev
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

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

2016-03-19 Thread Greg Clayton via lldb-dev
> On Mar 18, 2016, at 9:54 AM, Zachary Turner via lldb-dev > wrote: > > I notice everything uses SB classes only. Is this a hard requirement? I would prefer to try and get all of our tools to use the public API if at all possible and avoid pulling in lldb_private

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

2016-03-19 Thread 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 wrote: > Is it ok to add a public API that isn't interfaced to Python? In this > case the culprit is the

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

2016-03-19 Thread 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

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

2016-03-19 Thread Jim Ingham via lldb-dev
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