public inbox for dwz@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: dwz@sourceware.org
Subject: Read and write DWARF5 units and forms
Date: Thu, 24 Sep 2020 18:25:53 +0200	[thread overview]
Message-ID: <20200924162557.15870-1-mark@klomp.org> (raw)

Hi,

The following patches implement reading and writing of DWARF5
units and forms (excluding the split-dwarf DW_FORM_strx,
DW_FORM_addrx, DW_FORM_loclistx and DW_FORM_rnglistx)

This makes dwz able to process and write out
DWARF5 as generated by GCC for various files (as long as they
don't contain loclists or DWARF5 debug line tables).

[PATCH 1/4] Calculate size and write correct DWARF5 header
[PATCH 2/4] Handle DW_FORM_data16.
[PATCH 3/4] Handle DW_FORM_line_strp by not moving DIE.
[PATCH 4/4] Handle DW_FORM_implicit_const [experiment].

I believe the first two patches are good to go. A DWARF5 unit
header is 1 byte larger and has a different order for some of
the fields. DW_FORM_data16 is simple since it is just 16 bytes
of data that doesn't need to be treated specially for any attribute.

For now DW_FORM_line_strp is also fairly simple. But that is
mainly because I made it so that DIEs cannot be moved to a
multifile. There is no .debug_line_str section in a supplemental
file. I like to push this change for now and then revisit how
to handle line_strp when adding support for DWARF5 .debug_line
tables. It makes sense to merge all dir and line table strings
into the the supplemental .debug_str table (so both the main
file and multifile can refer to them using DW_FORM_strp or
DW_FORM_GNU_strp_alt/DW_FORM_strp_sup).

The last patch is a work in progress. DW_FORM_implicit_const
keeps the actual data value in the abbrev. This makes things tricky
because we have to decide where to keep (a reference to) the value
and when to update the value if necessary. In particular
DW_FORM_implicit_const might be used with a line table index for
the DW_AT_decl_file or DW_AT_call_file attributes which might
need updating in multifile mode. The patch commit message
contains some questions how to handle this better than is
done now. In particular I think the value updates are done at
the wrong point because I see various odr failures which seem
to indicate some DIEs aren't correctly detected as being similar.
I am also not sure things work correctly for --devel-ignore-locus.
Suggestions on how to handle this better would be very welcome.

I want to first work on handling the new .debug_loclists,
.debug_rnglists sections and parsing/writing of version 5 .debugline.
Then come back to properly handling DW_FORM_implicit_const.

Note that to make the testsuite work (there are still some failures
when building with make check CC="gcc -gdwarf-5" CXX="g++ -gdwarf-5")
you need binutils 2.35.1 (released this week) plus at least this patch:
https://sourceware.org/pipermail/binutils/2020-September/113425.html

Cheers,

Mark


             reply	other threads:[~2020-09-24 16:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-24 16:25 Mark Wielaard [this message]
2020-09-24 16:25 ` [PATCH 1/4] Calculate size and write correct DWARF5 header Mark Wielaard
2020-09-24 19:39   ` Jakub Jelinek
2020-09-25 16:35     ` Mark Wielaard
2020-09-25 16:39       ` Jakub Jelinek
2020-09-24 16:25 ` [PATCH 2/4] Handle DW_FORM_data16 Mark Wielaard
2020-09-24 19:43   ` Jakub Jelinek
2020-09-24 21:53     ` Jakub Jelinek
2020-09-25 16:42     ` Mark Wielaard
2020-09-24 16:25 ` [PATCH 3/4] Handle DW_FORM_line_strp by not moving DIE Mark Wielaard
2020-09-24 19:45   ` Jakub Jelinek
2020-09-24 16:25 ` [PATCH 4/4] Handle DW_FORM_implicit_const [experiment] Mark Wielaard
2020-09-24 19:57   ` Jakub Jelinek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200924162557.15870-1-mark@klomp.org \
    --to=mark@klomp.org \
    --cc=dwz@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).