Created attachment 13884 [details] Example of compiled module When building Linux kernel with[1] CC=clang LLVM=1 and CONFIG_DEBUG_INFO_DWARF5=y debugedit reports error when processing compiled kernel modules, such as debugedit: ./lib/modules/5.16.0+rc6.20211223-drm-tip-alt1/kernel/sound/usb/caiaq/snd-usb-caiaq.ko: Unknown DWARF DW_FORM_0x25 [1] https://www.kernel.org/doc/html/latest/kbuild/llvm.html
Also, it seems, debugedit is unable to extract source list from such binary.
(In reply to Vitaly Chikunov from comment #0) > When building Linux kernel with[1] CC=clang LLVM=1 and > CONFIG_DEBUG_INFO_DWARF5=y debugedit reports error when processing compiled > kernel modules, such as > > debugedit: > ./lib/modules/5.16.0+rc6.20211223-drm-tip-alt1/kernel/sound/usb/caiaq/snd- > usb-caiaq.ko: Unknown DWARF DW_FORM_0x25 That is DW_FORM_strx1, which is only partially supported by debugedit. Normally the DW_FORM_strx forms are only used when generating split DWARF (.dwo) files. Best workaround for now is to not use DWARF5 with llvm (which isn't the default for clang/llvm anyway).
(In reply to Mark Wielaard from comment #2) > (In reply to Vitaly Chikunov from comment #0) > > When building Linux kernel with[1] CC=clang LLVM=1 and > > CONFIG_DEBUG_INFO_DWARF5=y debugedit reports error when processing compiled > > kernel modules, such as > > > > debugedit: > > ./lib/modules/5.16.0+rc6.20211223-drm-tip-alt1/kernel/sound/usb/caiaq/snd- > > usb-caiaq.ko: Unknown DWARF DW_FORM_0x25 > > That is DW_FORM_strx1, which is only partially supported by debugedit. > Normally the DW_FORM_strx forms are only used when generating split DWARF > (.dwo) files. Best workaround for now is to not use DWARF5 with llvm (which > isn't the default for clang/llvm anyway). DWARFv5 is now the default with the upcoming Clang 14.0.0 release: https://github.com/llvm/llvm-project/blob/e80c52986e1bb3afa6a92c58b1cb897877923a66/clang/docs/ReleaseNotes.rst#dwarf-support-in-clang At the moment debugedit warns for almost any binary compiled with Clang 14.0.0-rc1
Additionally from what I can tell the flags to re-enable DWARFv4, -gdwarf-4, and -fdebug-default-version=4 do nothing to silence this issue.
(In reply to James Beddek from comment #4) > Additionally from what I can tell the flags to re-enable DWARFv4, -gdwarf-4, > and -fdebug-default-version=4 do nothing to silence this issue. CC=clang CFLAGS="-gdwarf-4 -fdebug-default-version=4" ... doesn't give a warning for me at least. This has been bugging me for a while, glad I found it.
*** Bug 29773 has been marked as a duplicate of this bug. ***
This is now reproducing basically everywhere where LLVM17 clang is used. The workaround to use DWARF4 seems quite unexpected now that DWARF5 is these days the norm for everything.