Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] LLDB/Clang
LLDB uses SWiG to generate Python bindings. I have no experience with SWiG, but apparently it can generate JNI bindings as well.

One thing I am looking at is having custom protocol between debugger and fronted - e.g. instead of stream-based MI protocol in GDB it is possible to have standalone LLDB process (currently it can be written in C++ or Python) that communicates with the fronted via pipes (e.g. Google protobuf) and memory maps. Controlling both sides of the communication channel (unlike DSF-GDB) decreases number of messages and allows to heavily optimize the exchanges.


On Wed, Nov 6, 2013 at 7:53 AM, Doug Schaefer <dschaefer@xxxxxxx> wrote:
Looks like this confirms that:


Feel free to poke around. Looks like a pretty good API, although a little lacking in text in their docs.

D.

From: <Abid>, Hafiz <Hafiz_Abid@xxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Wednesday, November 6, 2013 at 9:49 AM
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] LLDB/Clang

>Hi Alex, could you expand on that? I thought the way it worked is that you loaded the lldb dylib and using its APIs you could create and run any number of targets, even remotely.

 

I think this is how it works. Using C++ API, you can create multiple instance of the debugger and then multiple instances of target in any debugger instance.

 

Regards,

Abid

 

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc-Andre Laperle
Sent: 05 November 2013 00:42
To: CDT General developers list.
Subject: Re: [cdt-dev] LLDB/Clang

 

On 11/4/2013 5:04 PM, Alex Blewitt wrote:

On 4 Nov 2013, at 19:53, Doug Schaefer <dschaefer@xxxxxxx> wrote:

 

Hey gang,

 

As pointed out in https://bugs.eclipse.org/bugs/show_bug.cgi?id=405670, Apple has dropped gdb from the latest Mavericks OS release. I also noticed that gcc in the latest Xcode command-line tools actually runs clang (although I imagine the gcc driver respects gcc arguments).

 

At any rate, in order to properly support Mac as a target for CDT in the future, we’ll need proper support for these tools. And to be honest, that’s a good thing since these tools are pretty good and cross platform to Linux at least, and something we should get to know anyway.

 

Any thoughts on how we’d kickstart this activity?

 

lldb has a native C++ API as well as a python based one which could be used to script interaction instead. 

 



Depending on which level is chosen it might make sense to have a generic lldb wrapper and then have the debug CDT code work against that intermediary layer. 



One disadvantage of having the native code is that it might be difficult to spawn multiple executions of lldb or require a restart of Eclipse between runs. 




Hi Alex, could you expand on that? I thought the way it worked is that you loaded the lldb dylib and using its APIs you could create and run any number of targets, even remotely. I was thinking it would be nice (maybe too optimistic) to do it similarly to SWT and have a thin JNI layer (Swig?) that would map everything to Java and hopefully this would be faster too. To me, the disadvantage of this approach is possibly crashing the whole Eclipse process because of a crash in LLDB.


On the other hand since Python is supported in lldb you could have a python remote debugger serving on a TCP port and then drive everything through the network. That might make remote debugging easier too.


Do you know if Xcode does use the Python bindings? I thought maybe it would be slower, especially when doing "lower level" operations like retrieving memory. But if Xcode does it that way with satisfactory results, perhaps this would be the safest approach.

Thanks,

Marc-Andre




Alex 




_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top