Fixing Assembly Linking Errors with -fno-plt Compiler Flag

by

Summary

During a recent high-performance optimization phase, our team encountered a critical mismatch between hand-optimized assembly modules and the C-compiled object files they were meant to interface with. Specifically, when switching from standard Procedure Linkage Table (PLT) execution to a no-plt optimization model, our manual assembly references failed to resolve. This was caused by a misunderstanding of how modern compilers apply symbol decorations (like @GOTPCREL) to achieve position-independent code.

Root Cause

The issue stems from the fact that symbol decoration is not part of the symbol name itself, but rather an instruction to the linker on how to access that symbol’s address.

  • Standard PIC/PLT: The compiler uses @PLT to tell the linker the reference should go through the Procedure Linkage Table.
  • fno-plt Optimization: When -fno-plt is used, the compiler bypasses the PLT to save a jump instruction, instead using @GOTPCREL(%rip) to access the Global Offset Table directly.
  • Visibility Mismatch: The C compiler automatically detects whether a symbol is hidden or default visibility and applies the appropriate decoration. Manual assembly lacks this “intelligence” and defaults to standard symbol resolution, which breaks when the linker expects a specific relocation type.

Why This Happens in Real Systems

In complex production environments, we rarely use “pure” assembly. We use hybrid codebases where performance-critical hot paths are written in assembly while the rest of the logic resides in C/C++.

  • Compiler Abstraction: C compilers hide the complexity of Position Independent Code (PIC) by managing the heavy lifting of relocations.
  • Optimization Flags: High-level flags like -fno-plt or -fvisibility=hidden change the ABI (Application Binary Interface) behavior globally, often in ways that are not immediately obvious to developers writing low-level instructions.
  • Linker Strictness: Modern linkers (like ld or gold) are highly sensitive to the relocation type requested. If the assembly requests a standard relocation but the C object expects a GOT-relative relocation, the link will fail or, worse, result in a segmentation fault at runtime.

Real-World Impact

  • Build Pipeline Fragility: Introducing a new compiler optimization flag can silently break the assembly layer, leading to linking errors that are difficult to trace back to the assembly files.
  • Performance Regressions: If a developer “fixes” the issue by reverting to standard symbol resolution, they may inadvertently re-introduce the PLT overhead they were trying to avoid.
  • Runtime Instability: In cases where the linker allows a mismatch, the program may attempt to jump to an incorrect memory address, causing non-deterministic crashes in production.

Example or Code

# Standard assembly reference (Fails with -fno-plt)
movq my_global_variable, %rax

# Correct assembly reference for -fno-plt (x86-64)
# This mimics the @GOTPCREL decoration
movq my_global_variable@GOTPCREL(%rip), %rax

How Senior Engineers Fix It

A senior engineer does not simply hardcode @GOTPCREL into every assembly file, as this destroys portability. Instead, we implement abstraction layers in the build system.

  • Feature Detection Macros: We define a set of assembly macros in a header-like .inc file.
  • Build System Integration: We use the build system (CMake/Make) to pass specific definitions to the assembler based on the compiler flags.
  • Unified Interface: We ensure that the assembly module “asks” the build system how to resolve symbols rather than assuming a specific decoration. 
    # Example Makefile logic to bridge C and Assembly
ifeq ($(CFLAGS), -fno-plt)
ASFLAGS += -DDECORATE_GOTPCREL
endif
    # Using the abstraction in assembly
.macro RESOLVE_SYMBOL sym, reg
\reg, \sym@GOTPCREL(%rip)
.endm

Implementation

RESOLVE_SYMBOL my_global_variable, %rax

## Why Juniors Miss It

*   **The "Name" Fallacy**: Juniors often assume that `my_symbol` is just a string. They fail to realize that the **relocation type** (how the computer finds the address) is just as important as the name.
*   **Over-reliance on Magic**: They assume that if a flag is passed to `gcc`, it automatically applies to the entire project, forgetting that **inline assembly and standalone .s files** operate in a different scope than C code.
*   **Lack of Toolchain Depth**: They often treat the compiler and linker as a "black box" and do not use tools like `objdump -r` or `readelf -W` to inspect the actual **relocation entries** of the compiled objects.

Leave a Comment