Re: DWARF5 support for dwz

[Jakub Jelinek <jakub@redhat.com>]

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

	Jakub