Bug 24726 - [dwz] Support DWARF5
Summary: [dwz] Support DWARF5
Status: NEW
Alias: None
Product: dwz
Classification: Unclassified
Component: default (show other bugs)
Version: unspecified
: P2 enhancement
Target Milestone: ---
Assignee: Nobody
Depends on: 27373 27374 27375 27376 27434 27572 27440
  Show dependency treegraph
Reported: 2019-06-24 11:37 UTC by Tom de Vries
Modified: 2024-02-03 13:30 UTC (History)
6 users (show)

See Also:
Last reconfirmed:

Support few DWARF-5 DW_AT_*+DW_OP_* (733 bytes, patch)
2020-05-22 21:11 UTC, Jan Kratochvil
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tom de Vries 2019-06-24 11:37:53 UTC
Currently we have:
  value = read_16 (ptr);
  if (value < 2 || value > 4)
      error (0, 0, "%s: DWARF version %d unhandled", dso->filename,
      return 1;
Comment 1 Tom de Vries 2019-06-24 11:46:19 UTC
A first step could be to improve an error message like this:
dwz: /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.dwarf2/nonvar-access/nonvar-access: Unknown DWARF DW_OP_160
to use "DW_OP_implicit_pointer" instead, by updating dwarf2.def and friends.
Comment 2 Jakub Jelinek 2019-06-24 12:00:46 UTC
Yeah.  Next step teaching it to read the DWARF 5 section headers, understand new forms etc., still shouldn't be that hard.
The hardest part is actually optimizing it, switching between DW_FORM_implicit_const and the old forms as needed in order to have smallest possible output.
Comment 3 Jan Kratochvil 2020-05-22 21:11:08 UTC
Created attachment 12564 [details]
Support few DWARF-5 DW_AT_*+DW_OP_*

This patch adds a minimal set of DW_AT_*+DW_OP_* to successfully pass LLVM-11 testsuite with its DWZ support (off-trunk so far).
Comment 4 Mark Wielaard 2020-09-14 12:44:44 UTC
Some initial patches and an outline of some of the work needed: https://sourceware.org/pipermail/dwz/2020q3/000668.html
Comment 5 Mark Wielaard 2021-02-08 14:24:44 UTC
The normal DWARF5 as generated by GCC is supported now.

Some additional improvements to support more variants:

- Handle DW_UT_type (in .debug_info variant of DWARF4 .debug_types)

- Handle DW_FORM_strx[1234]
  (and .debug_str_offsets, DW_AT_str_offsets_base)
- Handle DW_FORM_addrx[1234]
  (and .debug_addr section, DW_OP_addrx, DW_OP_constx, DW_AT_addr_base)
- Handle DW_FORM_rnglistx and DW_FORM_loclistsx
  (DW_AT_rnglists_base, DW_AT_loclists_base)

- Handle .debug_names (standardized variant of .gdb_index)

- Use DW_FORM_ref_sup[48] and DW_FORM_strp_sup instead of
  DW_FORM_GNU_ref_alt and DW_FORM_GNU_strp_alt
  (Probably behind --dwarf5 flag)
- Generate .debug_sup section (standardized variant of .gnu_debugaltlink)
  (Probably behind --dwarf5 flag)
Comment 6 Martin Liska 2021-03-16 19:46:38 UTC
> - Handle DW_FORM_addrx[1234]
>   (and .debug_addr section, DW_OP_addrx, DW_OP_constx, DW_AT_addr_base)

I have a test-case where these are present. It's well known MozillaFirefox package:

It's rejected currently in:
$ dwz libxul.so-86.0.1-1.1.x86_64.debug -L 200000000 -l 40000000
dwz: ./usr/lib/debug/usr/lib64/firefox/libxul.so-86.0.1-1.1.x86_64.debug: Unknown DWARF DW_OP_addrx