public inbox for
 help / color / mirror / Atom feed
From: Jakub Jelinek <>
To: Mark Wielaard <>
Subject: Re: DWARF5 support for dwz
Date: Mon, 14 Sep 2020 12:48:04 +0200	[thread overview]
Message-ID: <20200914104804.GB21814@tucnak> (raw)
In-Reply-To: <>

On Mon, Sep 14, 2020 at 12:23:51PM +0200, Mark Wielaard wrote:
> 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

Thanks for working on this.

> 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.

For DW_FORM_implicit_const, handling it when reading should be similar
to how DW_FORM_flag_present is handled already.

The harded will be the optimization part, figure out when it is worth to
split an abbreviation to two or more in order to introduce more
DW_FORM_implicit_const forms to make it an overall gain.
On the negative side that means growth in .debug_abbrev section and some
growth in the uleb128s referencing the new abbreviations, so it would need
to do it smartly and only when beneficial.

> 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?)

Yeah, some switch at least for the transition period would be worthwhile.
Because the consumers can't be really adjusted to handle it until dwz is
able to emit that, and dwz can't switch to doing it by default until
at least the majority of consumers are adjusted.

My memory is fuzzy, don't we need some adjustments to the expected gain
computations with dwarf5 because the section headers will have now different


      parent reply	other threads:[~2020-09-14 10:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-14 10:23 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 ` Jakub Jelinek [this message]

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:

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

  git send-email \
    --in-reply-to=20200914104804.GB21814@tucnak \ \ \ \

* 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).