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.
> 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.
> 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 ;-)
Andre'
_______________________________________________
Qt-creator mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/qt-creator
