public inbox for
 help / color / mirror / Atom feed
* Read and write DWARF5 units and forms
@ 2020-09-24 16:25 Mark Wielaard
  2020-09-24 16:25 ` [PATCH 1/4] Calculate size and write correct DWARF5 header Mark Wielaard
                   ` (3 more replies)
  0 siblings, 4 replies; 13+ messages in thread
From: Mark Wielaard @ 2020-09-24 16:25 UTC (permalink / raw)
  To: dwz


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

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:



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

end of thread, other threads:[~2020-09-25 16:42 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-24 16:25 Read and write DWARF5 units and forms Mark Wielaard
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

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