/bin/ld: DWARF error: invalid or unhandled FORM value: 0x25

Hi,
Clang-14.0.6 compilation of user space c files leads to below error at linking phase.
{{
clang/lib/gcc/x86_64-linux-gnu/9.3.0/…/…/…/…/x86_64-linux-gnu/bin/ld:clang/lib/gcc/x86_64linux-gnu/9.3.0/…/…/…/…/x86_64-linux-gnu/bin/ld: DWARF error: invalid or unhandled FORM value: 0x25
}}
noticed below patch as fix in identifying this format.
{{
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2017f38777038db926239b9bbea738d270597b0e
}}
Please confirm if above fix helps or not?

Regards
Koti

0x25 is DWARF_FORM_strx1, new in DWARF v5. Either get a linker that supports DWARF v5 (that commit is the support for the specific construct here), whether GNU binutils or LLVM LLD, or use -gdwarf-4 to make Clang emit DWARF v4 instead of its default.

Dear jrtc27

Thank you for your input. For experimental purpose, in the makefile i am using to compile user space c file code, i passed below option. The macro EXTRA_CFLAGS’ is used by clang for sure during compilation.
{{
EXTRA_CFLAGS += -gdwarf-4
}}
But issue is not resolved. So It seems it’s required to include LLVM LLD with support for DWARF v5. Can you please let me know if you have patch that recognize DWARF v5format by LLD, i will rebuilt the toolchain by including the same.

Meanwhile, i am sharing more detailed error message as given below
{{
/clang/lib/gcc/x86_64–linux-gnu/9.3.0/…/…/…/…/x86_64–linux-gnu/bin/ld: DWARF error: invalid or unhandled FORM value: 0x25
build/connection.o:(.bss+0x4): multiple definition of check_type_e'; //clang/lib/gcc/x86_64--linux-gnu/9.3.0/../../../../x86_64--linux-gnu/bin/ld: DWARF error: invalid or unhandled FORM value: 0x25 build/session_dbginfo.o:(.bss+0x0): first defined here //clang/lib/gcc/x86_64--linux-gnu/9.3.0/../../../../x86_64--linux-gnu/bin/ld: build/connection.o:(.bss+0x8): multiple definition of sp_type_e’; build/session_dbginfo.o:(.bss+0x4): first defined here
//clang/lib/gcc/x86_64–linux-gnu/9.3.0/…/…/…/…/x86_64–linux-gnu/bin/ld: build/connection.o:(.bss+0xc): multiple definition of sp_status_e'; build/session_dbginfo.o:(.bss+0x8): first defined here /clang/lib/gcc/x86_64--linux-gnu/9.3.0/../../../../x86_64--linux-gnu/bin/ld: build/connection.o:(.bss+0x10): multiple definition of match_object_e’; build/session_dbginfo.o:(.bss+0xc): first defined here
/clang/lib/gcc/x86_64–linux-gnu/9.3.0/…/…/…/…/x86_64–linux-gnu/bin/ld: build/connection.o:(.bss+0x14): multiple definition of match_condition_e'; build/session_dbginfo.o:(.bss+0x10): first defined here /clang/lib/gcc/x86_64--linux-gnu/9.3.0/../../../../x86_64--linux-gnu/bin/ld: build/connection.o:(.bss+0x18): multiple definition of x509_subject_e’; build/session_dbginfo.o:(.bss+0x14): first defined here
/clang/lib/gcc/x86_64–linux-gnu/9.3.0/…/…/…/…/x86_64–linux-gnu/bin/ld: build/connection.o:(.bss+0x1c): multiple definition of match_operation_e'; build/session_dbginfo.o:(.bss+0x18): first defined here /clang/lib/gcc/x86_64--linux-gnu/9.3.0/../../../../x86_64--linux-gnu/bin/ld: build/connection.o:(.bss+0x20): multiple definition of pst_type_e’; build/session_dbginfo.o:(.bss+0x1c): first defined here
/clang/lib/gcc/x86_64–linux-gnu/9.3.0/…/…/…/…/x86_64–linux-gnu/bin/ld: /clang/lib/gcc/x86_64–linux-gnu/9.3.0/…/…/…/…/x86_64–linux-gnu/bin/ld: DWARF error: invalid or unhandled FORM value: 0x25

}}
Regards
Koti

If you have object files with DWARF_FORM_strx1 then you did not build with -gdwarf-4, either because you didn’t clean your build first or because your Makefile isn’t passing it properly.

LLD 14.0.6, corresponding to the version of Clang you are using, supports DWARF v5, but if you’re using -gdwarf-4 then GNU binutils’s BFD ld should work.

Dear jrtc27
Yes. I am using clang-14.0.6 and corresponding llvm/lld. If clang-14.0.6 supports DWARF V5, as per error, it seems ld is failing in recognizing DWARF V5 string.
can you please see below patch in llvm that recognize DWARFv5 string format?
https://reviews.llvm.org/rG51b461074385aa8cc141809fa27070544b6ac34c
is above commit useful?

Regards
Koti

You are not using LLD, you are still using GNU ld.

LLVM LLD supports DWARF v5; I wired up DWARF v5 support in the Linux kernel and tested it extensively with LLD.

As @jrtc27 , you need to triple check that you passed -gdwarf-4 correctly to the compiler. You are likely using a very old version of GNU BFD which doesn’t yet know about DWARF v5. If you cannot pass -gdwarf-4 to the compiler for whatever reason, perhaps you could update your system’s linker (or use LLD; -fuse-ld=lld is the flag to clang when using clang to drive the link)?

Dear Nick

Thank you for your input.
Mine user space c code compilation is triggered with below command.
{{
$(CLANG) $(CFLAGS) -c $< -o $@ -MD -MF $(@:.o=.d)
}}
To pass -fuse-ld=lld option to above ‘clang’ compilation command, do i need to insert right after ‘$(CLANG)’ string in above command?

Regards
Koti

  1. I see only CFLAGS in that command, whereas before you said you added -gdwarf-4 to EXTRA_CFLAGS
  2. -fuse-ld is only needed at link time, not at compile time. What you’ve shown is the .c → .o compile step, not the .o → executable/library link step.

Dear jrtc27

Thank you for information. meanwhile, i am able to pass ld.lld as part of linking c source code compiled using clang but noticed below error at the end of linking stage.
{{
clang/bin/ld.lld -shared -soname libhealth_chk.so -o libhealth_chk.so health_chk.o health_chk_proto.o health_chk_proto_icmp.o health_chk_proto_tcp.o health_chk_proto_http.o health_chk_proto_tcphalf.o health_chk_ssl.o health_chk_ex.o -L…/…/…/build/lib -L…/…/…//lib -L…/…/…/build/lib -L/clang//lib -R…/…/…/build/lib -R…/…/…/lib -R/clang//lib -lc -lssl -lupdatedb -lnghttp2
ld.lld: error: unable to find library -lc
}}
seems clang specific ‘ld.ldd’ is not able to identify ‘-lc’ passed which is specific to gcc ?
is there any equivalent linker option for clang?

Regards
koti

You should not be using ld.lld directly, you should be using clang -fuse-ld=lld, which will handle all the library search paths for you. If you still insist on invoking ld.lld directly, which is not recommended, then you need to make sure any additional library search paths are added via -L (e.g. if on a Debian/Ubuntu system you will need /usr/lib/$triple). But please, use clang -fuse-ld=lld and let it do the right thing for you rather than passing the mess of arguments yourself.

Dear jrtc27,

I understood your input but bit confused in implementing it. let me give clang compilation and link steps for c file as given below.

  1. object file is generated with below step, i set ‘CC= clang’ for clang compilation.
    {{
    $(CC) $(CFLAGS) -c $< -o $@ -MD -MP -MF $(@:.o=.d)
    }}
  2. Now to generate shared object file from object file, below step is executed.
    {{
    $(LD) -shared -soname $(TARGET_SO) -o $@ $(OBJECTS_SO) $(LDDFLAGS) $(TARGET_SO_LIBS)
    }}
    Expansion of above commands during compilation process are given below.
    {{
    /clang/bin/clang -I…/include -I…/…/…/include -I…/…/…/include/glib-2.0 -I…/…/…/include/lasso -I…/…/…/build/include -I…/…/…/include -I…/…/…/migbase/include -I…/…/…/cmf/include -I…/…/…/migbase/include/libutil/ -mtune=generic -Wall -Werror -fPIC -fno-strict-aliasing -fms-extensions -Wno-unused-but-set-variable -Wno-unused-local-typedefs -Wno-unused-const-variable -Wno-unused-variable -Wno-deprecated-declarations -Wno-misleading-indentation -Wno-parentheses -Wno-tautological-compare -Wno-sizeof-pointer-memaccess -Wno-address-of-packed-member -Wno-microsoft-anon-tag -Wno-incompatible-library-redeclaration -Wno-enum-conversion -Wno-format-security -Wno-unused-function -Wno-pointer-bool-conversion -Wno-strlcpy-strlcat-size -Wno-absolute-value -Wno-self-assign -Wno-implicit-function-declaration -ggdb -O0 -c health_chk_ex.c -o health_chk_ex.o -MD -MP -MF health_chk_ex.d
    /clang/bin/ld.lld -shared -soname libhealth_chk.so -o libhealth_chk.so health_chk.o health_chk_proto.o health_chk_proto_icmp.o health_chk_proto_tcp.o health_chk_proto_http.o health_chk_proto_tcphalf.o health_chk_ssl.o health_chk_ex.o -L…/…/…/build/lib -L…/…/…/lib -L…/…/…/build/lib -L/-clang//lib -R…/…/…/build/lib -R…/…/…/lib -R/-clang//lib -lc -lssl -lupdatedb -lnghttp2
    ld.lld: error: unable to find library -lc
    …/…/…/rules.Make:438: recipe for target ‘libhealth_chk.so’ failed

}}
With above information, -fuse-ld=lld should be passed during generation of .so file (i.e 2nd step)?

Regards
Koti

This should be

$(CC) $(CFLAGS) -shared -Wl,-soname,$(TARGET_SO) -o $@ $(OBJECTS_SO) $(LDFLAGS) $(TARGET_SO_LIBS)

where LDFLAGS (note I’ve renamed it from LDDFLAGS, which is not a sensible name) uses -Wl,-R instead of -R and also contains -fuse-ld=lld. Invoking ld directly is bad practice.