I agree with folks who think this is a bit confusing.
This blog post is announcing:
1. Using clang as a frontend.
2. Using C2 (MS compiler) as a backend.
What the LLVM community (IE not MS so far, but participation is of course, welcome)) has been building:
1. Using clang as a frontend
2. Using llvm as a backend
and even more specifically
1. Using MS Headers + MS Libraries
2. Using clang as a frontend
3. Using llvm as a backend.
(see blog.llvm.org/2014/07/clangllvm-on-windows-update.html for a 9 month old view)
Some of the mingw32 folks have been working on replacing #1 with non-ms stuff, but let's put that aside for the sake of this description )
Using clang as a frontend is where almost all of the ABI compatibility happens anyway (and where various developers have been focusing), so you end up with VC++ ABI compatible binaries whether you use C2 or not, if you/they use the pre-existing clang stuff.
Whether they are doing that (and then lowering llvm ir to c2 ir) , or if they've built an alternative IR generation with clang (IE generating c2 ir directly from clang), that they haven't released, is not clear.
If they've built something that generates C2 IR from clang, they would have had to write their own ABI compat, which would mean it may be different than the binaries clang would build.
(exception handling is also codegen'd by llvm, so exception handling could end up different, though of course, compatibility is the goal)
Hi DannyBee, sorry if we didn't get the message out clearly. Jim Radigan gives a deeper technical explanation in the build talk he did yesterday. http://channel9.msdn.com/events/Build/2015/3-610
It's translating LLVM IR to C2 IR. We know that the Clang/LLVM community is hard at work on implementing the MS-ABI and we've reached out to a few developers working on ABI stuff as well as symbols support. We intend to engage with that community more openly now that we've announced but of course shipping the code will be our top priority. One important contribution of the Clang/C2 approach is that we will have full native VS debugger support. This is just the first step in a longer journey. Thanks, Steve, VC Dev Mgr
We went through this at my former employer (not MS) just before i left. In fact the politics surrounding it drove me to seek relative sanity of doing a startup. When I started working on it, there really were two camps: clang emitting house IR instead of LLVM IR, or translating LLVM IR either early (right out of clang) or late (as a target after all optimization). I was working on the prototypes for the latter pair of options before another constraint was added that invalidated all of those paths.
The problem was that clang is quite intertwined with LLVM IR. ABI is spread all over the place, both FE and BE. It was proving hard to get something the house optimizers/code generators would be happy with. So a more radical path was chosen — wiring clang's parser + ASTs to another C++ front-end's AST and then using the old IR generator to get all of the idiosyncrasies right for the target. It was wacky, but seemed to be half-way working when I left, such that major open source code was compiling.
The whole idea of taking just parts of clang/llvm reeks of a half-measure anyway. It's probably better to either keep the existing compiler stack, or cut it right out and put the secret sauce into LLVM as add-in modules.
Can the clang+LLVM toolchain generate a PDB file that can be used by WinDbg? Can it generate .obj and .lib files that can be statically linked with those generated by Visual C++?
No, it can't generate a PDB file itself, at least not today. Maybe in the future the MSVC linker will be able to generate one even though you compiled with Clang/LLVM (it does that already today but the PDB file is almost empty).
You can definitely build obj and lib files and link them with files built by MSVC. That works well.
We also support putting DWARF debug info (the standard format) into the binaries, and the LLVM linker LLD will link them and you can debug the resulting program with the LLVM debugger LLDB (or GDB for that matter).
Hi Chandler! it's probably worth mentioning that we will be also opening up our lldb-mi based debug engine which will allow you to debug any lldb target from Visual Studio. And we'll continue to contribute back improvements to lldb-mi. Thanks, Steve Carroll, VC Dev Mgr
This blog post is announcing:
1. Using clang as a frontend.
2. Using C2 (MS compiler) as a backend.
What the LLVM community (IE not MS so far, but participation is of course, welcome)) has been building:
1. Using clang as a frontend
2. Using llvm as a backend
and even more specifically
1. Using MS Headers + MS Libraries
2. Using clang as a frontend
3. Using llvm as a backend.
(see blog.llvm.org/2014/07/clangllvm-on-windows-update.html for a 9 month old view)
Some of the mingw32 folks have been working on replacing #1 with non-ms stuff, but let's put that aside for the sake of this description )
Using clang as a frontend is where almost all of the ABI compatibility happens anyway (and where various developers have been focusing), so you end up with VC++ ABI compatible binaries whether you use C2 or not, if you/they use the pre-existing clang stuff.
Whether they are doing that (and then lowering llvm ir to c2 ir) , or if they've built an alternative IR generation with clang (IE generating c2 ir directly from clang), that they haven't released, is not clear.
If they've built something that generates C2 IR from clang, they would have had to write their own ABI compat, which would mean it may be different than the binaries clang would build.
(exception handling is also codegen'd by llvm, so exception handling could end up different, though of course, compatibility is the goal)