[lldb-dev] RFC: full support for python files, and avoid using FILE* internally

[Pavel Labath via lldb-dev]

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