Created attachment 135171 [details] Implement DWARF5 in readdwarf and readdwarf3 Since gcc11 will default to DWARF5 by default it is time for valgrind to support it. The attached patch handles everything gcc11 produces. There is some duplication in the patch since we actually have two DWARF readers which use slightly different abstractions (Slices vs Cursors). It would be nice if we could merge these somehow. And the handling of DW_FORM_implicit_const is tricky with the current design. An abbrev which contains an attribute encoded with DW_FORM_implicit_const has its value also in the abbrev. The code in readdwarf3.c assumed it always could simply get the data from the .debug_info/current Cursor. For now I added a value field to the name_form field that holds the associated value. This is slightly wasteful since the extra field is not necessary for other forms. Tested against GCC10 and GCC11 on x86_64. No regressions in the regtests.
Julian looked at it briefly on irc and gave me a star. Pushed as: commit a1fa6696f5f3714983438647285ce85262d101b3 Author: Mark Wielaard <mark@klomp.org> Date: Mon Jan 25 15:33:34 2021 +0100 Add support for DWARF5 as produced by GCC11 Implement DWARF5 in readdwarf.c and readdwarf3.c Since gcc11 will default to DWARF5 by default it is time for valgrind to support it. The patch handles everything gcc11 produces (except for the new DWARF expressions). There is some duplication in the patch since we actually have two DWARF readers which use slightly different abstractions (Slices vs Cursors). It would be nice if we could merge these somehow. The reader in readdwarf3.c is only used when --read-var-info=yes is used (which drd uses to provide the allocation context). The handling of DW_FORM_implicit_const is tricky with the current design. An abbrev which contains an attribute encoded with DW_FORM_implicit_const has its value also in the abbrev. The code in readdwarf3.c assumed it always could simply get the data from the .debug_info/current Cursor. For now I added a value field to the name_form field that holds the associated value. This is slightly wasteful since the extra field is not necessary for other forms. Tested against GCC10 (defaulting to DWARF4) and GCC11 (defaulting to DWARF5) on x86_64. No regressions in the regtests. https://bugs.kde.org/show_bug.cgi?id=432102