July 27th, 2024

Better Firmware with LLVM/Clang

LLVM and Clang are gaining traction in embedded software development, particularly for ARM Cortex-M devices. The article advocates integrating Clang for better static analysis, error detection, and dual compiler usage.

Read original articleLink Icon
Better Firmware with LLVM/Clang

LLVM and Clang are increasingly recognized in the embedded software development community, despite their popularity in other domains like Apple products and WebAssembly. This article advocates for integrating a Clang build target into existing projects, particularly those using ARM Cortex-M devices. The benefits include enhanced static analysis capabilities, reduced dependency on a single compiler, and improved error detection through dual compiler usage. The article outlines a step-by-step process for transitioning from GCC to Clang, including installation instructions and configuration tips.

Static analysis tools like scan-build, part of the LLVM toolchain, can identify potential issues in code that may go unnoticed by traditional compilers. The article details how to utilize scan-build to analyze projects, highlighting its ability to catch logical errors, null pointer dereferences, and division by zero. Additionally, it discusses enabling dynamic memory checkers for custom memory management functions, which is crucial for embedded systems that often implement their own memory allocation strategies.

The article emphasizes that adopting LLVM/Clang does not necessitate abandoning existing compilers, allowing developers to leverage the strengths of both toolchains. By following the provided guidelines, developers can enhance their firmware quality and maintainability, ultimately leading to more robust embedded applications. The example project used throughout the article is available on GitHub for those interested in practical implementation.

Related

Mix-testing: revealing a new class of compiler bugs

Mix-testing: revealing a new class of compiler bugs

A new "mix testing" approach uncovers compiler bugs by compiling test fragments with different compilers. Examples show issues in x86 and Arm architectures, emphasizing the importance of maintaining instruction ordering. Luke Geeson developed a tool to explore compiler combinations, identifying bugs and highlighting the need for clearer guidelines.

Integrated assembler improvements in LLVM 19

Integrated assembler improvements in LLVM 19

LLVM 19 brings significant enhancements to the integrated assembler, focusing on the MC library for assembly, disassembly, and object file formats. Performance improvements include optimized fragment sizes, streamlined symbol handling, and simplified expression evaluation. These changes aim to boost performance, reduce memory usage, and lay the groundwork for future enhancements.

Building Chromium at a distro? Here's your copium

Building Chromium at a distro? Here's your copium

Building Chromium on Linux faced challenges with M120 changes, leading to distros like Alpine, Arch, Gentoo, and Fedora using LLVM's libc++. Despite efforts, issues persist with GCC and libstdc++, emphasizing ongoing compatibility struggles.

Boosting Compiler Testing by Injecting Real-World Code

Boosting Compiler Testing by Injecting Real-World Code

The research introduces a method to enhance compiler testing by using real-world code snippets to create diverse test programs. The approach, implemented in the Creal tool, identified and reported 132 bugs in GCC and LLVM, contributing to compiler testing practices.

Driving Compilers

Driving Compilers

The article outlines the author's journey learning C and C++, focusing on the compilation process often overlooked in programming literature. It introduces a series to clarify executable creation in a Linux environment.

Link Icon 1 comments
By @Joel_Mckay - 4 months
"Better" is subjective, as an LLVM is not always appropriate for most firmware.

Indeed, note gcc is sometimes intentionally Nerf'ed to suppress optimizations in favor of more repeatable code-motion behavior in real-time systems. Yes this can compile terribly inefficient binaries when inspected, but they are predictable and repeatable builds.

There is sometimes extremely good reasons to be able to inspect exactly what the assembly dump does, and know for sure it won't get randomly permuted in the compilation optimization/abstraction LLVM builds.

This concept is difficult for people who don't understand the subtle difference between guaranteed-latency schedulers, and real-time systems.

Clang is great for a lot of application level things performance wise, but firmware is often not one of those use-cases for really good reasons.

I guess it is true what they say, one day you must become a historian if you are around long enough. lol =3