# ODR violation detection

This article describes how to detect C++ One Definition Rule (ODR) violations. There are many good resources on the Internet about how ODR violations can introduce subtle bugs, so I will not repeat that here.

## Debug information based

### gold --detect-odr-violations

In 2007, the gold linker implemented an option --detect-odr-violations to detect ODR violation based on debug information. This option collects symbols starting with _Z and finds two STB_WEAK definitions with different st_size or different st_type values. These symbols are candidates of ODR violation.

gold parses DWARF line tables. For a candidate, if both its definitions have associated line table information (if any definition does not have debug info, no warning) and disjoint file:line sets. If yes, gold issues a warning.

The check uses source locations as a proxy as an ODR violation. The proxy is usually good but not precisely ODR violation. The first line of a function may change among relocatable object files due to different optimization behaviors. And we may see spurious ODR violations. The check does not find differing class/enum definitions and templates.

The option uncovered some Chromium bugs, see https://crbug.com/449754.

The feature is not implemented in other linkers. This idea of using debug information is interesting. See "Future direction" for a non-debug-information alternative, which may possibly be better.

A debug information based approach is potentially slow. As an analogy, constructing .gdb_index is easily the slowest path in the linker.

https://github.com/adobe/orc is a tool for finding violations of C++'s One Definition Rule on the OSX toolchain. It wraps libtool/ld on macOS to collect input object files and parses debugging information entries and verifies that certain attributes match.

As a standalone program, it can focus on user interface.

Finding ODR Violations with ORC was a talk on ACCU 2022.

## LTO based

### GCC -Wlto-type-mismatch and -Wodr

-Wlto-type-mismatch is an enabled-by-default warning for LTO about mismatched types of types (structs, function signatures, etc). See gcc/lto/lto-symtab.cc:warn_type_compatibility_p.

C++ has an additional diagnostic -Wodr about mismatched types of C++ global declarations.

It cannot detect the case when a member function is changed from inline to non-inline.

-Wodr does not detect inline int foo() { return 1; } vs inline int foo() { return 2; }.

See block:618550 ODR for Gentoo's bug list.

Implement -Wlto-type-mismatch? is an llvm-project feature request.

### ThinLTO

ThinLTO computes a module summary for functions, global variables, aliases, and ifuncs. Technically the module summary can be overloaded to record ODR hashes, but coupling this with an optimization-targeted feature seems weird and adds size overhead even when the feature is not used.

## Clang ODR hash

In 2017, Clang implemented an AST-based ODR hash feature. Each definition is given a hash value. When definitions are merged, the hash values are compared and an error is reported if mismatching.

This feature works with both Clang header modules and C++ modules.

-fmodules implies -fimplicit-modules to load module.modulemap. The two #include directives are translated to module loads. When foo in B and C are merged, an error is issued.

Let's see an example of C++ modules.

## Compiler instrumentation based

### AddressSanitizer detect_odr_violation

For an instrumented translation unit, there is a global constructor which calls __asan_register_globals to register some types of global variables (non-thread-local, defined, external/private/internal LLVM linkage, and a few other conditions). This can be used to check whether two global variables of the same name are defined in different modules. In 2014, detect_odr_violation was implemented for this idea. Note: functions and vague linkage symbols are not instrumented, so the interesting case is skipped.

#### Poisoning based detection

The runtime poisons the red zone of a to-be-registered global variable (compiler-rt/lib/asan/asan_globals.cpp). If the variable was poisoned when attempting a registration, it means that the variable has been registered by another linkage unit. The runtime will report an ODR violation error.

The default detect_odr_violation=2 mode additionally disallows symbol interposition on variables. Change long in b.cc to int and we will still see an odr-violation error. detect_odr_violation=1 suppresses errors if the registered variable is of the same size.

This approach has a drawback when a global variable is defined in a non-instrumented TU and an instrumented TU, and the linker selects the non-instrumented TU.

The variable metadata references the interposable variable symbol. If an instrumented global variable is interposed by an uninstrumented one, the runtime may poison bytes not belonging to the global variable. Since poisoning writes to shadow memory, this is usually benign. However, global variable instrumentation increases the alignment of a global variable (to at least 32) and checks that the metadata-referenced variable symbol has an alignment of at least shadow granularity (8). If the referenced variable symbol resolves to a non-instrumented module, the alignment check may fail (if the symbol is less aligned) and in this case the runtime reports a bogus odr-violation error as well.

Let's see an example. I add a dummy variable to make var not aligned by 8 in a.o (no guarantee but working in practice).

#### ODR indicator

http://reviews.llvm.org/D15642 introduced a new mode: for a variable var, a one-byte variable __odr_asan_gen_var is created with the original linkage (essentially only external). If var is defined in two instrumented modules, their __odr_asan_gen_var symbols reference to the same copy due to symbol interposition. When registering var, set the associated __odr_asan_gen_var to 1. The runtime checks whether __odr_asan_gen_var is already 1, and if yes, the variable has an ODR violation.

To prevent the metadata-referenced symbol from interposed to another linkage unit, create a private alias for var to be referenced in the metadata. This ensures that the metadata refers to the self copy.

For Clang 16, I landed https://reviews.llvm.org/D137227 to use -fsanitize-address-use-odr-indicator by default for non-Windows targets.

https://reviews.llvm.org/D127911 changed the ODR indicator symbol name to __odr_asan_gen_\$demangled.

### KCFI

Clang has recently implemented a indirect call control flow integrity instrumentation which does not require link-time optimization: KCFI. One side product of this feature is related to ODR violation detection.

For an address-taken function, a weak absolute symbol __kcfi_typeid_<function> is defined. The symbol is weak. But imagine we use a STB_GLOBAL symbol, a linker can find differing values. GNU ld has a hack that duplicate absolute definitions do not trigger an error and ld.lld has ported the behavior. While such a scheme would work, using magic symbols is not proper usage of a linker and I would object to such an attempt.

### MSVC LNK2022

In MSVC, the /clr switch seems to insert some metadata. The linker is able to report LNK2022: metadata operation failed.

## lld COMDAT resolution

While implementing parallel section initialization for ld.lld, I changed ld.lld symbol resolution to disregard COMDAT resolution (COMDAT resolution was moved to a later pass). This combined with AddressSanitizer -fsanitize-address-globals-dead-stripping -fsanitize-address-use-odr-indicator turns out to catch some violations of classes with vtables. This is an interesting side product I did not anticipate.

With -fsanitize-address-globals-dead-stripping -fsanitize-address-use-odr-indicator, a global variable is placed in a COMDAT group so that the global variable (var) along with the metadata (__asan_gen_var) can be discarded by the linker if unreferenced. The associated ODR indicator is not in a COMDAT.

In a.o, the vtable for A has vague linkage and compiles to a weak symbol _ZTV1A in a COMDAT. In b.o, the vtable for A has regular external linkage and compiles to a STB_GLOBAL symbol _ZTV1A. Normally b.o:_ZTV1A is not in a COMDAT but in -fsanitize-address-globals-dead-stripping -fsanitize-address-use-odr-indicator mode the symbol is in a COMDAT.

During linking, as a.o precedes b.o, the COMDAT group in a.o is prevailing while the COMDAT group in b.o is non-prevailing. With lld's new symbol resolution rule, b.o:_ZTV1A overrides a.o:_ZTV1A but later the definition is discarded (the symbol becomes undefined) because it is in a non-prevailing COMDAT. A relocation referencing the noew undefined _ZTV1A will cause an error.

There are similar errors for typeinfo for A and typeinfo name for A unless -fno-rtti is specified.

If we make the COMDAT with the STB_GLOBAL symbol prevailing, the errors will be suppressed.

Since typeinfo and typeinfo name can trigger this error, we can change a.cc to not have a vtable. Just use typeid.

## Summary

There are several ways we can categorize these tools.

• run-time analysis: AddressSanitizer detect_odr_violation
• static analysis: the others

By scope:

• single translation unit: Clang ODR hash
• cross linkage unit: AddressSanitizer detect_odr_violation

By entity:

• GCC -Wlto-type-mismatch and -Wodr: type
• gold --detect-odr-violations: C++ vague linkage functions
• lld with -fsanitize-address-globals-dead-stripping -fsanitize-address-use-odr-indicator: C++ vague linkage functions and variables: (partial)
See RFC: ODR checker for Clang and LLD for a 2017 RFC. The effort added SHT_LLVM_ODRTAB and was not upstreamed.
I think the section can be a table holding ODR hash values. Each value is associated with a R_*_NONE relocation referencing the associated symbol table entry. For classes which do not produce a symbol (i.e. no vtable), the compiler can generate a symbol solely for ODR violation detection.