[lldb-dev] RFC: full support for python files, and avoid using FILE* internally
Pavel Labath via lldb-dev
lldb-dev at lists.llvm.org
Mon Sep 23 07:11:10 PDT 2019
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:
> 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:
> I’ve posted the first few patches to phabricator for review.
> What do you think?
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*.
More information about the lldb-dev