Bug 28728 - Unknown DWARF DW_FORM_0x25 (DW_FORM_strx)
Summary: Unknown DWARF DW_FORM_0x25 (DW_FORM_strx)
Status: RESOLVED FIXED
Alias: None
Product: debugedit
Classification: Unclassified
Component: debugedit (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 29773 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-12-27 07:23 UTC by Vitaly Chikunov
Modified: 2024-05-15 11:29 UTC (History)
9 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2021-12-27 00:00:00


Attachments
Example of compiled module (319.81 KB, application/x-object)
2021-12-27 07:23 UTC, Vitaly Chikunov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vitaly Chikunov 2021-12-27 07:23:56 UTC
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
Comment 1 Vitaly Chikunov 2021-12-27 07:30:24 UTC
Also, it seems, debugedit is unable to extract source list from such binary.
Comment 2 Mark Wielaard 2021-12-27 10:40:42 UTC
(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).
Comment 3 James Beddek 2022-02-18 07:41:05 UTC
(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
Comment 4 James Beddek 2022-02-18 07:47:25 UTC
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.
Comment 5 Sam James 2022-11-09 06:58:38 UTC
(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.
Comment 6 Sam James 2022-11-11 05:06:07 UTC
*** Bug 29773 has been marked as a duplicate of this bug. ***
Comment 7 Seppo Yli-Olli 2023-09-24 18:10:54 UTC
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.
Comment 9 Mark Wielaard 2023-12-11 14:02:14 UTC
commit 3e7aeeab4f744ad15108775685db68d3a35b0735
Author: Mark Wielaard <mark@klomp.org>
Date:   Thu Mar 23 18:07:40 2023 +0100

    debugedit: Add support for .debug_str_offsets (DW_FORM_strx)
    
    In theory supporting strx .debug_str_offsets is easy, the strings in
    .debug_str are just read through an indirection table. When the
    strings are updated in .debug_str we just need to rewrite the
    indirection table.
    
    The tricky part is the ET_REL (object files or kernel modules)
    support. Relocation reading is "global" per section and we expect to
    read a relocation only once. But we need to read the
    DW_AT_str_offsets_base before reading any strx form attributes. So we
    read that first, then reset the relptr. And when we read from the
    .debug_str_offsets section we need to save and restore the .debug_info
    relptr.
    
            * tools/debugedit.c (do_read_24): New function.
            (str_offsets_base): New static variable.
            (buf_read_ule24): New function.
            (buf_read_ube24): Likewise.
            (setup_relbuf): Handle .debug_str_offsets.
            (do_read_uleb128): New function.
            (do_read_str_form_relocated): Likewise.
            (read_abbrev): Handle DW_FORM_strx[1234].
            (edit_strp): Take the actual string form as argument.
            Use do_read_str_form_relocated.
            (read_dwarf5_line_entries): Pass form to edit_strp.
            (edit_attributes_str_comp_dir): Take the actual string
            form as argument. Use do_read_str_form_relocated.
            (edit_attributes): Handle DW_FORM_strx[1234].
            (edit_info): Read DW_AT_str_offsets_base first.
            (update_str_offsets): New function.
            (edit_dwarf2): Setup do_read_24. Call update_str_offsets.
    
    https://sourceware.org/bugzilla/show_bug.cgi?id=28728
    
    Signed-off-by: Mark Wielaard <mark@klomp.org>
Comment 10 Vitaly Chikunov 2024-04-27 11:50:31 UTC
Mark,

Thanks the fix! But, since LLVM 18 is started to produce DWARF 5 by default, maybe you can draft a release with it?
Comment 11 Mark Wielaard 2024-05-15 11:29:28 UTC
(In reply to Vitaly Chikunov from comment #10)
> Thanks the fix! But, since LLVM 18 is started to produce DWARF 5 by default,
> maybe you can draft a release with it?

I found some other bugs that cause issues with strx. Will post them soon.
Current work in progress here:
https://code.wildebeest.org/git/user/mjw/debugedit/log/?h=strx
Then do a new release after those get integrated.