public inbox for dwz@sourceware.org
 help / color / mirror / Atom feed
* DWARF5 support for dwz
@ 2020-09-14 10:23 Mark Wielaard
  2020-09-14 10:23 ` [PATCH 1/4] Recognize some new DWARF5 .debug sections Mark Wielaard
                   ` (4 more replies)
  0 siblings, 5 replies; 11+ messages in thread
From: Mark Wielaard @ 2020-09-14 10:23 UTC (permalink / raw)
  To: dwz

Hi,

At the virtual GNU tools cauldron we had a little session about making
DWARF5 the default for GCC. GCC, binutils and gdb seem ready now, so
next up is DWZ. https://gcc.gnu.org/wiki/LPC2020NotesDWARF

Since nobody volunteered to add DWARF5 support I started
on some simple patches. The following 4 patches handle the easy parts.
Recognize some new DWARF5 .debug sections. Handle DWARF5 headers for
compile and partial units. Handle new DWARF5 attributes. And handle
some new DWARF5 operations as their GNU extension.

Next up is the harder part, parsing the new FORMs. DW_FORM_data16
should be easy. DW_FORM_line_strp is easy in principle, but might need
some thought to see how/if DIEs that reference the new .debug_line_str
can be moved (.debug_line_str itself cannot be moved to the supplemental
file so the string itself, and possibly .debug_line, should be rewritten
to point to the shared supplemental .debug_str section). The hard part
is DW_FORM_implicit_const which has its value in the abbrev, so just
having form plus .debug_info ptr isn't enough to read it. I think I have
a solution to that issue, but have to check how it interacts with the
hashing and writing out the new from.

There are a couple of forms that GCC only emits when generating split-DWARF
that I don't intend to implement righ now, DW_FORM_strx, DW_FORM_addrx,
DW_FORM_loclistx and DW_FORM_rnglistx.

Also there are standardized forms for GNU_ref_alt and GNU_strp_alt
(DW_FORM_ref_sup4, DW_FORM_ref_sup8 and DW_FORM_strp_sup) which I don't
want to use for now since they would require updates to consumers
(just like switching from .gnu_debugaltlink to .debug_sup). So I hold
those to the end (maybe we will introduce a new --dwarf5 flag for that?)

After the new FORMs patches are needed to read the new .debug_loclists
and .debug_rnglists sections. Then parse the .debug_line version 5 variant
(which gcc currently doesn't emit yet, but I have patches to make it
do so through binutils gas).

Finally we need to write out all the new data formats and possibly
optimize for the new forms.

Cheers,

Mark


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2020-09-15 11:38 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-14 10:23 DWARF5 support for dwz Mark Wielaard
2020-09-14 10:23 ` [PATCH 1/4] Recognize some new DWARF5 .debug sections Mark Wielaard
2020-09-14 10:36   ` Jakub Jelinek
2020-09-14 10:23 ` [PATCH 2/4] Handle DWARF5 headers for compile and partial units Mark Wielaard
2020-09-14 10:38   ` Jakub Jelinek
2020-09-15 11:38     ` Mark Wielaard
2020-09-14 10:23 ` [PATCH 3/4] Handle new DWARF5 attributes Mark Wielaard
2020-09-14 10:38   ` Jakub Jelinek
2020-09-14 10:23 ` [PATCH 4/4] Handle new DWARF5 operations as their GNU extension variants Mark Wielaard
2020-09-14 10:39   ` Jakub Jelinek
2020-09-14 10:48 ` DWARF5 support for dwz Jakub Jelinek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).