On 20/09/2019 17:35, Larry D'Anna via lldb-dev wrote:
Hi lldb-dev.
I want to be able to use LLDB inside of iPython, so I can have mixed
python and LLDB debug session.
To this end, I’d like to update LLDB to have full support for python
file objects, so the outputs of debugger commands can be redirected
into iPython’s own streams.
This however, is difficult to do, because LLDB makes use of FILE*
streams in a number of places. This presents two problems. The first
is that there is no really
correct way to create SWIG typemaps that handle conversion to FILE* and
get the ownership semantics correct. The second problem is that there
is not a portable
way to make a FILE* with arbitrary callbacks for reading and writing.
On Darwin and BSD there’s funopen, and on linux there’s something else,
and I don’t know if
there’s any way on windows.
I made an attempt at this a while ago using funopen a while ago, here:
https://reviews.llvm.org/D38829
Zachary Turner suggested a more thorough approach. where instead of
trying to use funopen to paper over all the use of FILE* streams, we
should make
lldb_private::File capable of doing the dynamic dispatch and excise all
the unnecessary FILE* stuff in favor of lldb_private::File.
That’s what I’ve done here:
https://github.com/smoofra/llvm-project/tree/files
I’ve posted the first few patches to phabricator for review.
https://reviews.llvm.org/D67793
https://reviews.llvm.org/D67792
https://reviews.llvm.org/D67789
What do you think?
Hello Larry,
thanks for starting this thread.
So, judging by your problem description, it sounds to me like you're
primarily interested in the SBCommandInterpreter::HandleCommand family
of functions (and by extension, the SBCommandReturnObject class). Would
that be a fair thing to say?
The reason I am asking this is that I'm wondering what is the scope of
the thing you're proposing to do (and then, whether this is the best way
to accomplish that). For instance, if we were only interested in the
HandleCommand api, then it might be possible to plug the python in at a
higher level (Stream instead of File). I am hoping that doing that might
be easier as the Stream class has a simpler interface, and already
supports multiple backing implementations (StreamFile, StreamString, ...).
Also, doing that would allow to side step some complicated questions.
One of the reasons why getting rid of FILE* is so complicated (you're
not the first person to try that) is that there are some APIs (libedit
mainly), that we just cannot change, and which require a FILE*.
If you do want to go with the more general change, then I'd like to ask
you to give a bit more detail about the your vision of the new role of
the lldb_private::File class and its interaction with other major lldb
components (SBFile, StreamFile, ???). My understanding (it's been a
while since I looked at this in detail) is that the File class can be
constructed from both FILE* and a file descriptor and (crucially) it is
also able to give back these underlying objects, including converting
between the two. Now, I am assuming you're intending to add a third
method of constructing a File object (using some python callbacks), but
I assume that (due the mentioned lack of funopen etc.) you won't be
trying to convert between these types. So, it would be good to spell out
what exactly does the File class promise to do, and what happens when
(e.g) a pythonified File object makes its way to code (libedit) which
requires a FILE*.
regards,
pavel
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
