Fix libafl_libfuzzer's compatibility with LLVM 14

[maxammann]

TL;DR: The LLVM 14 bfd gold linker plugin, which is used by nm is not compatible with libraries compiled with LLVM 18 (default since a few days in Rust)

I was confused by this issue and wanted to dig deeper why with LLVM 14 installed, compilation fails.

It turned out that the package llvm-14-linker-tools installs a bfd plugin at /usr/lib/bfd-plugins/LLVMgold-14.so which is used by the system nm tool.

The nm tool is used to relocate the symbols under a namespace. If the LLVM 14 bfd plugin is installed then the relocations miss the following relocations:

_ZN101_$LT$std..os..unix..net..addr..SocketAddr$u20$as$u20$std..os..net..linux_ext..addr..SocketAddrExt$GT$16as_abstract_name17hc452dbc34e1bfe57E _ZN8__libafl101_$LT$std..os..unix..net..addr..SocketAddr$u20$as$u20$std..os..net..linux_ext..addr..SocketAddrExt$GT$16as_abstract_name17hc452dbc34e1bfe57E
_ZN101_$LT$std..sys..pal..unix..args..Args$u20$as$u20$core..iter..traits..exact_size..ExactSizeIterator$GT$3len17h9ca930e01064494dE 
_ZN102_$LT$std..panicking..begin_panic_handler..FormatStringPayload$u20$as$u20$core..panic..PanicPayload$GT$8take_box17h53fb99eebdacb271E _ZN8__libafl102_$LT$std..panicking..begin_panic_handler..FormatStringPayload$u20$as$u20$core..panic..PanicPayload$GT$8take_box17h53fb99eebdacb271E
_ZN104_$LT$std..io..error..Error$u20$as$u20$core..convert..From$LT$alloc..collections..TryRes...
_ZN8__libafl3std5panic12always_abort17h4cc7dd61c889ce9dE
_ZN3std5panic13resume_unwind17he12c900ad05f6f99E _ZN8__libafl3std5panic13resume_unwind17he12c900ad05f6f99E
_ZN3std5panic14SHOULD_CAPTURE17h2c119f305541c440E.0 
...
...
_ZN8__libafl94_$LT$object..xcoff..SectionHeader32$u20$as$u20$object..read..xcoff..section..SectionHeader$GT$7s_paddr17h23cb1d58e67ebc72E
_ZN94_$LT$object..xcoff..SectionHeader32$u20$as$u20$object..read..xcoff..section..SectionHeader$GT$7s_vaddr17hb4d7110b54122240E _ZN8__libafl94_$LT$object..xcoff..SectionHeader32$u20$as$u20$object..read..xcoff..section..SectionHeader$GT$7s_vaddr17hb4d7110b54122240E
...
_ZN17compiler_builtins3int19specialized_div_rem11u32_div_rem17h62b27ed2b12fda33E _ZN8__libafl17compiler_builtins3int19specialized_div_rem11u32_div_rem17h62b27ed2b12fda33E
_ZN17compiler_builtins3int19specialized_div_rem12u128_div_rem17h2b7242287a3771ebE _ZN8__libafl17compiler_builtins3int19specialized_div_rem12u128_div_rem17h2b7242287a3771ebE

I also noticed now this output of nm:

bfd plugin: LLVM gold plugin has failed to create LTO module: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM18.1.4-rust-1.80.0-nightly' Reader: 'LLVM 14.0.0')

Is there a reason why we are not using the Rust supplied nm version?

[maxammann]

We should also really make sure what when we parse the output of nm that there are no warnings or errors printed. e.g.

nm: compiler_builtins-ae0728f1e6d5b4f0.compiler_builtins.90dbfb76425ca58d-cgu.124.rcgu.o: no symbols

[addisoncrump]

I'll get this rebased once #2154 lands.

[addisoncrump]

Can you enable maintainers to edit your PR? This way I don't have to open another PR to get it fixed 🙂

[addisoncrump]

Nevermind, realised that it doesn't matter because I know none of the checks are relevant :^)