|
On 11/4/2013 5:04 PM, Alex Blewitt
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
|
