On Aug 22, 2012, at 10:30 AM, [email protected] wrote:
>
> Michael Seydl wrote:
>> I'd like to take it on
>
> That would be nice.
>
>> because the gdb helpers often go bonkers when inspecting more complex data
>> structures.
>> Guess that's more due to limitation on the aged gdb and it's gdb/mi.
>
> Partially. The problem is only so prominent on Mac/gdb because it still uses
> the
> "compiled" dumpers, and there's nobody around keeping them up-to-date after
> changes to the container implementations. While we had a few breakages on the
> Linux/Windows sides (using gdb with Python) they usually get fixed rather
> quickly.
> Just having a recent GDB with Python working properly on Mac would already
> solve most of the problems, as would a cross-platform LLDB.
Yeah thought of that too. I gave the recent gdb source a shot but wasn't able
to execute any fat binaries properly as multi-architectural debugging seemed to
be one of the major patches the applied to the gdb.
>
>> As there are two ways to integrate lldb my question to you is which one you
>> prefer.
>>
>> 1. Integrating the lldb api (LLDB.frame). (Which is obviously an IPC engine
>> and code for that already exists.
>> Unfortunately the host/guest ipc code is quite outdated. At least in the
>> master branch)
>> 2. Integrating the python interface. (just like the current gdbengine does
>> right now). Hey, maybe I could even
>> reuse some of the scripts there.
>>
>> Whaddaya say?
>
> It's hard to tell from here, as it's unclear what kind of exact impact either
> solution has.
> Some points to consider:
> - it's not an advantage to depend on a quickly changing binary interface (is
> that "pro 2."?)
> - too much Python doesn't help performance (is that "pro 1."?)
> - we have a couple of users already extensively using the python dumpers for
> their own things ("pro 2.")
> - fixing a Python script is easier than recompiling Creator ("pro 2.")
>
> So all in all I'd lean towards the Python interface. There are also already
> two layers of
> abstraction (bridge.py / dumper.py ) shielding the actual dumpers from "too
> much gdb",
> but since there was no real other use case, that might need some polishing.
+1 here for python. Best example for how quickly the lldb api changes is that
even now the current snapshot from the lldb svn isn't anywhere near the
interface the deploy with the current Xcode.
>
>> I already got the 2. version as far as launching the executable and halting
>> at a break point :)
>
> On Mac, I suppose? But anyway, that's definitely a good start ;-)
\o/
>
> Andre'
Mike
_______________________________________________
Qt-creator mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/qt-creator
