LLDB debugger is coming to Windows(blog.llvm.org)
blog.llvm.org
LLDB debugger is coming to Windows
http://blog.llvm.org/2015/01/lldb-is-coming-to-windows.html
36 comments
I am looking forward to the day when I can have a full Clang/LLVM environment on my Windows machines without relying on MinGW. Hopefully this year!
..and integrated in VS so you can just select Toolset = Clang :P
Especially with the Community Edition of VS making it really easy for pretty much anyone to get access to VS.
I like GCC and everything but I will be happy to leave it behind if I am honest. The politics are just too damn much for me these days. GCC should be about building a great compiler collection for the world but politics plays too big a part in it as seen with the whole AST debate going on again because of RMS. I just want a good compiler and standard library implementation. Between Clang/LLVM and VS Community I don't know if GCC will really have a huge place in the future for me.
I like GCC and everything but I will be happy to leave it behind if I am honest. The politics are just too damn much for me these days. GCC should be about building a great compiler collection for the world but politics plays too big a part in it as seen with the whole AST debate going on again because of RMS. I just want a good compiler and standard library implementation. Between Clang/LLVM and VS Community I don't know if GCC will really have a huge place in the future for me.
for you and people like you of course . people whos care about software freedom of course choosing GCC.
Except the ones who want to do things that are 'forbidden' by RMS. Those people have no choice but to use LLVM. For example, a lot of academic work on compilers and languages can't easily use GCC, neither can people wanting to make more sophisticated tooling.
The point of GCC is having a good compiler available to everyone, for any use. Not to be embedded everywhere in the look-but-don't-touch fashion.
See also Linux kernels in most Android phones. That's exactly what GCC authors do not want.
See also Linux kernels in most Android phones. That's exactly what GCC authors do not want.
Clang currently supports my freedoms more than GCC with its political limitations holding it back.
Well it's coming to VS2015, just not for desktop apps. I assume that having the integration for any one platform greatly lowers the barrier for other platforms, though.
> In Visual Studio 2015, that cross-platform reach is going to include C++, too. Microsoft's development environment will include support for the Clang compiler and LLVM infrastructure for targeting Android and, in a later iteration, iOS.
http://arstechnica.com/information-technology/2014/11/visual...
> In Visual Studio 2015, that cross-platform reach is going to include C++, too. Microsoft's development environment will include support for the Clang compiler and LLVM infrastructure for targeting Android and, in a later iteration, iOS.
http://arstechnica.com/information-technology/2014/11/visual...
Already exists to a degree for some time.
http://llvm.org/builds/
Under Windows Snapshot Builds.
LLVM video on it from last year. https://www.youtube.com/watch?v=PX3UOXAlk0A
Slides from said talk http://llvm.org/devmtg/2014-04/PDFs/Talks/clang-cl.pdf
http://llvm.org/builds/
Under Windows Snapshot Builds.
LLVM video on it from last year. https://www.youtube.com/watch?v=PX3UOXAlk0A
Slides from said talk http://llvm.org/devmtg/2014-04/PDFs/Talks/clang-cl.pdf
I think this is awesome. Looking forward to libc++ being made to work on Windows. Then I will have a fully conformant c++ compiler and standard library across all the major platforms.
Isn't Linux support in libc++ still not 100%? I'm using libc++/c++14 on a new project and I love it! Much better than my last experience with c++ (c++98).
I was worried about using libc++, but I recently found a great VPS provider which lets you install from an ISO so I can run FreeBSD in production. I no longer have any need for Linux. Develop on OSX, deploy on FreeBSD.
I was worried about using libc++, but I recently found a great VPS provider which lets you install from an ISO so I can run FreeBSD in production. I no longer have any need for Linux. Develop on OSX, deploy on FreeBSD.
It's not quite 100%. There are still a few outstanding faults, mostly due to different localization assumptions made by the underlying libc. http://libcxx.llvm.org/results.Linux.html
Thanks for the link!
For the curious, this will eventually integrate with Visual Studio.
I realize this is difficult, but if you're working with Microsoft to make this happen, having a version of LLVM that generated PDBs would be amazing for interoperability, there's a lot of stuff in WinDbg (open the help file, it's actually a giant book of Windows-specific knowledge) and redoing it is definitely non-trivial (and in many cases only can be done by Microsoft because it relies on internal data structures)
ossreality: you are shadowbanned. DannyBee knows because he works on LLVM.
As a MinGW user, I'm pretty excited for this. Using GDB on Windows isn't even a perfect solution for MinGW programs, since they depend on Windows DLLs that use Microsoft format debug information. If LLDB supported both DWARF and PDB files, I'd finally be able to get a full stack trace with proper symbols for all frames.
By the way, radare2 (from git) currently can be built for/under Windows and supports both PDB and WinDbg, as well as DWARF.
It faces tough competition from the excellent Visual Studio debugger, but I hope they succeed. A compiler monoculture is bad.
Does this have any implications for Rust on windows?
Minor implications, perhaps. Much of what was done to reach this point was just making LLDB not fall over miserably on Windows. Like, to compile.. Or to not crash on startup for example :)
Anyone who decides they're interested in making Rust programs debuggable with LLDB will be able to benefit from this work by not having to do it. Also a core debug loop is going to be the same on Windows no matter what programming language is being debugged. I don't know what Rust's generated code looks like, but presumably it will be able to reuse the core debug loop and symbol reading code to some extent, although it will need to deal with ABI specific differences, put in its own expression evaluator, and things like that.
TL;DR - Someone from the Rust community will still have their work cut out for them, but if they're so motivated then they at least some of the work done here will benefit them.
Anyone who decides they're interested in making Rust programs debuggable with LLDB will be able to benefit from this work by not having to do it. Also a core debug loop is going to be the same on Windows no matter what programming language is being debugged. I don't know what Rust's generated code looks like, but presumably it will be able to reuse the core debug loop and symbol reading code to some extent, although it will need to deal with ABI specific differences, put in its own expression evaluator, and things like that.
TL;DR - Someone from the Rust community will still have their work cut out for them, but if they're so motivated then they at least some of the work done here will benefit them.
While mingw is the king in windows, it is beneficial if other c-compiler projects provide alternatives. One day, clang will come as a complete alternative (modulo winapi headers) combined with libc++ eventual implementation. Personally I would like to see other dbg projects like mago materialize for dlang native debugging. From what I see, LLDB could be useful for LDC2.
But I do not know if LLDB debugs only MSVC debugger format or also Dwarf on windows? Is it only specific to clang-cl?
But I do not know if LLDB debugs only MSVC debugger format or also Dwarf on windows? Is it only specific to clang-cl?
PDB support is very sweet to have.
Not to be cynical, but what's in it for Apple?
Obviously someone at Apple decided this makes business sense. What's the thinking?
Obviously someone at Apple decided this makes business sense. What's the thinking?
I believe it's mostly people at Google pushing this feature. I don't think Apple had much of a say in it.
Oh sorry. I was under the impression that Apple was in charge of the LLVM project
No. The LLVM foundation is.
By numbers, Apple probably isn't even the largest contributor anymore (but this is just a guess based on mailing list traffic)
They probably would be if swift was open-source.
Probably not, actually.
But it also depends on what you count. Google definitely has more people working directly on LLVM itself than Apple (At Google, they almost all work for me, and I know the numbers for Apple).
If you start to include related open source projects (like clang, etc), the numbers get closer, but then you have things like all of the Android related open source stuff that gets worked on (Renderscript), etc.
In any case, i'm not sure what the goal of any corporate measuring contest would be here. We are all friendly and working on the same open source projects. It's not about what "Google is doing" or "Apple is doing" but "what is getting done in the LLVM project".
But it also depends on what you count. Google definitely has more people working directly on LLVM itself than Apple (At Google, they almost all work for me, and I know the numbers for Apple).
If you start to include related open source projects (like clang, etc), the numbers get closer, but then you have things like all of the Android related open source stuff that gets worked on (Renderscript), etc.
In any case, i'm not sure what the goal of any corporate measuring contest would be here. We are all friendly and working on the same open source projects. It's not about what "Google is doing" or "Apple is doing" but "what is getting done in the LLVM project".
Google and Apple used to be friendly and working on the same open source project named WebKit. Looking at the precedent, it is not unreasonable to consider such things, even if everything is okay in LLVM at the moment.
These projects have very different means and goals.
They also have very different governance, etc.
In any case, i'm still not sure what we are "considering" here.
In any case, i'm still not sure what we are "considering" here.
The LLVM project as a whole has many contributors from many different companies working on things they care about and contributing it back to the community.