[lldb-dev] does vFile:Open actually work?

[Larry D';Anna via lldb-dev]

The comments in File.h say:

  // NB this enum is used in the lldb platform gdb-remote packet
  // vFile:open: and existing values cannot be modified.
  enum OpenOptions {
eOpenOptionRead = (1u << 0),  // Open file for reading
eOpenOptionWrite = (1u << 1), // Open file for writing
eOpenOptionAppend =
(1u << 2), // Don't truncate file when opening, append to end of file

And In GDBRemoteCommunicationServerCommon.cpp it says:

  uint32_t flags = packet.GetHexMaxU32(false, 0);
  if (packet.GetChar() == ',') {
mode_t mode = packet.GetHexMaxU32(false, 0600);
FileSpec path_spec(path);
FileSystem::Instance().Resolve(path_spec);
// Do not close fd.
auto file = FileSystem::Instance().Open(path_spec, flags, mode, false);


But in the GDB documentation it says:

@node Open Flags
@unnumberedsubsubsec Open Flags
@cindex open flags, in file-i/o protocol

All values are given in hexadecimal representation.

@smallexample
  O_RDONLY0x0
  O_WRONLY0x1
  O_RDWR  0x2
  O_APPEND0x8
  O_CREAT   0x200
  O_TRUNC   0x400
  O_EXCL0x800
@end smallexample


Does vFile:Open actually work?  Are there any tests that cover it?

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] test setup for windows -- makefiles

[Larry D';Anna via lldb-dev]

Hi lldb-dev.

Most of the tests build binaries to test with using Makefiles, and these 
Makefiles use all sorts of unix commands
like sed and uname.And yet I see the build-bot is running `ninja-check 
lldb` on windows.


I thought maybe if I installed MinGW that would have enough stuff in it to run 
the tests, but that doesn’t seem to be 
true.

Does anyone have instructions for how to set up a windows test host for LLDB?   
Or  a list of dependencies that 
should be installed?

Thanks.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [RFC] Adding a clang-style LLVM.h (or, "Are you tired of typing 'llvm::' everywhere ?")

[Larry D';Anna via lldb-dev]

Pavel Labath said

> some llvm classes, are so well-known and widely used, that qualifying 
> them with "llvm::" serves no useful purpose and only adds visual noise. 
> I'm thinking here mainly of ADT classes like String/ArrayRef, 
> Optional/Error, etc. I propose we stop explicitly qualifying these classes.
> 
> We can implement this proposal the same way as clang solved the same 
> problem, which is by creating a special LLVM.h 
>  
> header in the Utility library. This header would adopt these classes 
> into the lldb_private namespace via a series of forward and "using" 
> declarations.
> 
> I think clang's LLVM.h is contains a well-balanced collection of adopted 
> classes, and it should cover the most widely-used classes in lldb too, 
> so I propose we use that as a starting point.

I think this is a great idea, particularly for llvm::Expected.   The signatures 
of functions 
using Expected arer kind of noisy already, and adding llvm:: doesn’t help.

Anyone object to this idea?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Larry D';Anna via lldb-dev]

> On Sep 24, 2019, at 4:11 AM, Pavel Labath  wrote:
> 
> On 23/09/2019 20:54, Larry D'Anna wrote:
>>> On Sep 23, 2019, at 7:11 AM, Pavel Labath  wrote:
>>> 
>>> 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?
>> Not really.  I want to be able to embed a full LLDB session inside of 
>> iPython, which means redirecting anything that prints to the debugger's main 
>> output and error streams. Yes, in most cases that will be coming from 
>> HandleCommand(), but I really want to avoid the situation where some output 
>> that would normally be printed to the terminal is missed under iPython.
> 
> Ok, that's fair.
> 
>>> 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*.
>> I saw that.   My strategy for dealing with that was to audit the codebase 
>> for any use of File::GetStream().   I found the only two places I could not 
>> remove the use of GetStream() was libedit and IOHandlerCursesGUI.In my 
>> prototype, I deal with that by checking for NULL from GetStream() before 
>> libedit or IOHandlerCursesGUI are enabled. In other words, If a File can 
>> produce a FILE*, it will.   But you can still  have a valid File that will 
>> return NULL from GetStream.   If you set your debugger streams to Files 
>> that return NULL from GetStream, then libedit and the curses GUI will be 
>> disabled.I think this is a reasonable approach.For my use-case in 
>> particular, there is no need for either libedit or the curses gui, because 
>> the whole point is to use iPython as the gui.  In general, libedit

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

[Larry D';Anna via lldb-dev]

> On Sep 23, 2019, at 7:11 AM, Pavel Labath  wrote:
> 
> 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?

Not really.  I want to be able to embed a full LLDB session inside of iPython, 
which means redirecting anything that prints to the debugger's main output and 
error streams. Yes, in most cases that will be coming from HandleCommand(), 
but I really want to avoid the situation where some output that would normally 
be printed to the terminal is missed under iPython.

> 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*.

I saw that.   My strategy for dealing with that was to audit the codebase for 
any use of File::GetStream().   I found the only two places I could not remove 
the use of GetStream() was libedit and IOHandlerCursesGUI.In my prototype, 
I deal with that by checking for NULL from GetStream() before libedit or 
IOHandlerCursesGUI are enabled. In other words, If a File can produce a 
FILE*, it will.   But you can still  have a valid File that will return NULL 
from GetStream.   If you set your debugger streams to Files that return 
NULL from GetStream, then libedit and the curses GUI will be disabled.I 
think this is a reasonable approach.For my use-case in particular, there is 
no need for either libedit or the curses gui, because the whole point is to use 
iPython as the gui.  In general, libedit and curses only really make sense 
if the IO streams are a terminal anyway, so it’s not a problem to disable these 
features if the IO streams are redirected to python.

> 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

[lldb-dev] help, how to get a debug build on windows (python37_d.lib)

[Larry D';Anna via lldb-dev]

Hi lldb-dev.  

I can’t seem to figure out how to build a debug lldb on windows.   It wants to 
link against a debug version of Python, which isn’t there.

My cmake line looks like this:

cmake -G Ninja `

   
"-DPYTHON_HOME=C:\Program Files (x86)\Microsoft Visual 
Studio\Shared\Python37_64" `

"-DLLVM_ENABLE_PROJECTS=clang;lldb;libcxx;libcxxabi;lld" `  

   
"-DSWIG_EXECUTABLE=C:\ProgramData\chocolatey\bin\swig.exe" `

   
"C:\Users\smoofra\llvm-project\llvm"

   

I also made this change, to tell it to link against the release python.

--- a/lldb/cmake/modules/LLDBConfig.cmake
+++ b/lldb/cmake/modules/LLDBConfig.cmake
@@ -227,7 +227,7 @@ function(find_python_libs_windows)
   else()
 # Lookup for concrete python installation depending on build type
 if (CMAKE_BUILD_TYPE STREQUAL Debug)
-  set(LOOKUP_DEBUG_PYTHON TRUE)
+  set(LOOKUP_DEBUG_PYTHON FALSE)
 else()
   set(LOOKUP_DEBUG_PYTHON FALSE)
 endif()

But somehow at the very end, the link still fails because python37_d.lib isn’t 
there.

Anybody know what I’m doing wrong?  Thank you.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Larry D';Anna via lldb-dev]

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?



___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev