Paths in pieces

Linux distributions and package managers often check binaries for absolute paths that are not relocatable. While a simple grep or strings command can detect these paths, the reality is more complex. When using GCC to compile code targeting x86-64 architecture, the compiler does not necessarily store the string constants directly in the binary.

Instead, it optimizes the code by splitting the string into overlapping pieces that fit into SIMD registers, and then storing these pieces as constants. This results in a shorter binary size but can cause issues when auditing binaries for absolute paths. In some cases, package managers like Conda and Spack install packages with padded prefixes, allowing them to be relocated at installation time.

They add repeating strings to the directory name to ensure the paths are long enough, but even with a long padding, the final binary will only contain a truncated version of the original path. GCC's approach to storing string constants seems to prioritize size optimization over interpretability, as it can lead to larger binaries with duplicated, aligned bytes.

While this may save a small amount of space and potentially improve performance through deduplication, the benefits are often marginal, especially when modern distributions use advanced vector instructions such as AVX2 and AVX-512. Some argue that maintaining string constants in the binary is worth the trade-off for interpretability and ease of debugging, but others suggest that the benefits are outweighed by the potential issues with post-build audits.

An alternative approach, as taken by Debian, is to assert that binaries can be rebuilt in various circumstances, keeping machine-specific details out of the binaries altogether.