Automatic variable initialization: Add an option to initialize automatic variables with either a pattern or with zeroes. The default is still that automatic variables are uninitialized. Also add attributes to request uninitialized on a per-variable basis, mainly to disable initialization of large stack arrays when deemed too expensive.[…]
[…]It is the result of the community’s work over the past six months, including: function multiversioning in Clang with the ‘target’ attribute for ELF-based x86/x86_64 targets, improved PCH support in clang-cl, preliminary DWARF v5 support, basic support for OpenMP 4.5 offloading to NVPTX, OpenCL C++ support, MSan, X-Ray and libFuzzer support for FreeBSD, early UBSan, X-Ray and libFuzzer support for OpenBSD, UBSan checks for implicit conversions, many long-tail compatibility issues fixed in lld which is now production ready for ELF, COFF and MinGW, new tools llvm-exegesis, llvm-mca and diagtool. And as usual, many optimizations, improved diagnostics, and bug fixes.[…]
Early support for UBsan, X-Ray instrumentation and libFuzzer (x86 and x86_64) for OpenBSD. Support for MSan (x86_64), X-Ray instrumentation and libFuzzer (x86 and x86_64) for FreeBSD.
AArch64 target: Assembler and disassembler support for the ARM Scalable Vector Extension has been added.
A new Implicit Conversion Sanitizer (-fsanitize=implicit-conversion) group was added. Please refer to the Undefined Behavior Sanitizer (UBSan) section of the release notes for the details.
An existing tool named diagtool has been added to the release. As the name suggests, it helps with dealing with diagnostics in clang, such as finding out the warning hierarchy, and which of them are enabled by default or for a particular compiler invocation.
clang-tidy: New module zircon for checks related to Fuchsia’s Zircon kernel.
The DEBUG macro has been renamed to LLVM_DEBUG, the interface remains the same.
A new tool named llvm-mca has been added. llvm-mca is a static performance analysis tool that uses information available in LLVM to statically predict the performance of machine code for a specific CPU.
ARM has updated it’s C/C++ compiler toolchains.
C and C++ update for Arm Compiler 6:
As you are hopefully aware, Arm Compiler 6 has been available for 3+ years now, and has grown in maturity, and optimization quality release on release. As I write this, the latest available version is 6.8, and 6.6 has been qualified for use in safety-related development. We offer full support for the latest Arm processors, across the Cortex-A, R, and M, and SecureCore families. Arm Compiler 6 is available within DS-5 and Keil MDK toolchains. Furthermore the qualified version is available for purchase stand-alone. Arm Compiler 6 is based on the LLVM framework, using the modern Clang compiler front-end, and this is reflected in the name of the executable, Armclang. The compiler is then integrated into the full Arm tools suite, enabling use of legacy assembler code built with Armasm, as well as gas format assembler directly with Armclang. Finally the Arm linker (Armlink) brings in the optimized C and C++ libraries, or if desired the size optimized Arm C MicroLib library, as well as (optionally) implementing link-time optimizations across the source code.[…]
EBC, The EFI Byte Code, is a UEFI feature that supports Intel (Itanium, x86, and x64) instructions in a single bytecode. The Intel C Compiler can target EBC, and UEFI drivers can use EBC instead of native drivers, to save space (1 binary, instead of 3).
The other week I gave a firmware security tools talk at BlackLodgeResearch.org, and Vincent Zimmer of Intel showed up. I had a slide complaining that EBC is only supported by Intel C Compiler, a commercial-only product, and that the UEFI Forum should fund a ‘summer-of-code’-style effort to get EBC into GCC or LLVM CLang. After the talk, Vincent mentioned that ICC had to do a bit of unexpected work to generate EBC, and would blog about it. Well, he did blog about it, a few days ago, just catching up to it, and describe the problem.
If you know of someone on the LLVM CLang or GCC project, please try to add a request for EBC support.
Not only would it be nice to have LLVM CLang work with EBC to have an alternative to ICC, and for LLBVM’s Klee fuzzer (to fuzz UEFI via OVMF), but ALSO because the Capstone Framework RE tool uses LLVM’s intermediate form and would then get EBC support!!
Today, radare2, another RE tool, already has EBC support.
If technically possible, it might be nice if ARM added AArch32 and AArch64 support, and EBC support in their compiler, so that EBC could actually target all UEFI platforms with a single blob. ARM/Linaro already has something that appears to overlap in some ways:
Also, there’s a C#/IL to EBC translation project on Github. If you get it to work, let me know!
A few days ago, the ARM Software Dev Tools blog posted their 2015Q2 update on their use of Open Source Toolchains. The post talks about ARM changes in GNU GCC as well as LLVM. It appears they’re getting ready to present at GNU Cauldron in August. Look at their blog for more information. They’ve got some YouTube video and presentation slides, as well.
One thing this blog post clarified to me was what codebase ARM’s C compiler was based on: LLVM Clang:
“The commercial toolchain we offer to our customers, ARM Compiler 6, is in fact based on open source clang.”
According to an article on Phoronix by Michael Larabel, the coreboot project has been updated to support LLVM Clang, in addition to GCC. This is great news, having additional compilers target a project is good for finding errors, and LLVM has the klee fuzzer that might become useful with coreboot when used with a VM like QEMU.