Re: [lldb-dev] Prebuilt binary for Windows

On Wed, Jan 11, 2017 at 3:54 PM, Zachary Turner wrote: > Ahh, that would make sense as well, since LLDB links against liblldb as a > dll. Don't see a good solution to this short of forcing dynamic linking. > liblldb has to be a dll because it needs to be visible to python as an > extension modu

Re: [lldb-dev] Prebuilt binary for Windows

Ahh, that would make sense as well, since LLDB links against liblldb as a dll. Don't see a good solution to this short of forcing dynamic linking. liblldb has to be a dll because it needs to be visible to python as an extension module. And if it's a dll and uses static linking, then we would hav

Re: [lldb-dev] Prebuilt binary for Windows

Okay, as far as I can see, the issue is not with Python, but that lldb.exe and liblldb.dll have their own private copies of the CRT. When startup script is given on the command line, lldb.exe creates a pipe, writes the script into the write end, wraps a stdio file around the read end, and gives th

Re: [lldb-dev] Prebuilt binary for Windows

On Wed, Jan 11, 2017 at 1:47 PM Vadim Chugunov wrote: > > Definitely seems CRT / Python related. The call to fgets indicates that > it's doing something involving a FILE*. It's probably a FILE* that refers > to a file created from within Python's copy of the CRT. > > Any idea where in the code

[lldb-dev] [Bug 31612] New: Cannot eval function which returns empty struct. Error [IRForTarget]: Size of result type 'struct foo { }' couldn't be determined

https://llvm.org/bugs/show_bug.cgi?id=31612 Bug ID: 31612 Summary: Cannot eval function which returns empty struct. Error [IRForTarget]: Size of result type 'struct foo { }' couldn't be determined Product: lldb Ve

[lldb-dev] [Bug 31611] New: error: calling 'f' with incomplete return type 'string' (aka 'std::__cxx11::basic_string, std::allocator >')

https://llvm.org/bugs/show_bug.cgi?id=31611 Bug ID: 31611 Summary: error: calling 'f' with incomplete return type 'string' (aka 'std::__cxx11::basic_string, std::allocator >') Product: lldb Version: 3.9 Hardware: PC

Re: [lldb-dev] Prebuilt binary for Windows

Definitely seems CRT / Python related. The call to fgets indicates that it's doing something involving a FILE*. It's probably a FILE* that refers to a file created from within Python's copy of the CRT. Another problem that dynamic linking would solve. Can you confirm that the problem does not o

Re: [lldb-dev] Prebuilt binary for Windows

BTW, here's the call stack at the point of failure. I don't see anything Python-related in it, so maybe it's some other CRT interaction. liblldb!_invoke_watson(wchar_t * expression = 0x "", wchar_t * function_name = 0x "", wchar_t * file_name = 0x "", unsigned int line_nu

Re: [lldb-dev] Prebuilt binary for Windows

I agree that linking to them dynamically is safer, but then you get into the deployment problem. You do have to redistribute the DLLs for users using anything less than Windows 10. There are several options for doing that: VCRedist, MSMs, MSUs, and app-local deployment. They each have drawbacks

Re: [lldb-dev] Prebuilt binary for Windows

If we do that though, we still get 2 copies of the CRT. One for python and one for LLDB. While I *think* there is a strong enough API boundary in how the application and Python access each others' data structures that it doesn't matter, I'm not 100% sure without further research. It seems safer

Re: [lldb-dev] Prebuilt binary for Windows

I was just reading up on this the other day. Statically linking to the Universal CRT (and related libraries) *is* supported though it's not Microsoft's top recommendation. Initially, they said they weren't going to support app-local deployment, but they backed off on that, and it, too, is now sup

Re: [lldb-dev] logging in lldb

On Wed, Jan 11, 2017 at 10:38 AM, Zachary Turner wrote: > > > On Wed, Jan 11, 2017 at 6:59 AM Pavel Labath wrote: > >> Happy new year everyone. :) >> >> I have refreshed the implementation at >> with something more polished. I >> consider this almost-ready, I ju

Re: [lldb-dev] Prebuilt binary for Windows

The purpose of linking the CRT statically was to ensure that clang can run on systems that don't have the CRT already installed from some other app or by VS itself. As long as that is preserved, feel free to do whatever you need. I think we still want to link vcruntime140 statically and the C++ ru

Re: [lldb-dev] Prebuilt binary for Windows

Is static CRT even still supported / recommended when using the new Universal CRT? My understanding is the new UCRT is considered a core windows component, so we don't ahve to distribute redistributables anymore. Maybe I'm wrong about this. That said, I think we want dynamic regardless, otherwis

Re: [lldb-dev] Prebuilt binary for Windows

Sorry, just found another problem: the installed lldb crashes when given a script via the command line. For example, `lldb -O "p 42"` dies with exception 0xC409. It didn't happen with the one I've build locally, so I started digging... The difference seems to be that build_llvm_build_package.

Re: [lldb-dev] logging in lldb

On Wed, Jan 11, 2017 at 6:59 AM Pavel Labath wrote: > Happy new year everyone. :) > > I have refreshed the implementation at > with something more polished. I > consider this almost-ready, I just need feedback on a couple of > details: > > - log->Warning/Debug/Er

Re: [lldb-dev] Prebuilt binary for Windows

Great! Thanks for pushing this. On Tue, Jan 10, 2017 at 7:00 PM, Vadim Chugunov wrote: > Yes, the new build works! > > On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg wrote: >> >> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454). >> Please let me know if that works. >> >> On Tu

Re: [lldb-dev] logging in lldb

Happy new year everyone. :) I have refreshed the implementation at with something more polished. I consider this almost-ready, I just need feedback on a couple of details: - log->Warning/Debug/Error/Verbose: Currently we have a large number of printf-style loggin