clang DebugInfo regression for -fdebug-types-section [Re: [llvm] r359122 - DebugInfo: Emit only declarations (not whole definitions) of non-unit user defined types into type units]

[Jan Kratochvil via llvm-commits]

Hello David,

if you compile some binary with -fdebug-types-section some required types are
missing in the DWARF.

As an example I have provided LLVM's existing test case source:
	lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-smart-array/main.cpp

You can compare GDB output before/after your change with command
(tested on Fedora 29 x86_64):
	../llvm-monorepo-clangassert/bin/clang++ -o 1 -g -fdebug-types-section lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-smart-array/main.cpp;gdb -batch ./1 -ex 'b 59' -ex r -ex 'p other'

Currently LLDB cannot read .debug_types (produced by -fdebug-types-section) so
one cannot see it as a regression in LLDB testsuite.  But when you use GDB
(which can read .debug_types fine - both produced by GCC and clang) you can
see after your change some member of the structure no longer have their type.
Such as 'strarr' before your change:
	strarr = "Nested Hello world!\000\377\377\377\377`\\\305\367\377\177\000"
And 'strarr' after your change:
	strarr = 0x7fffffffcba0

That is because DWARF contained for 'strarr' before your change
definition DW_TAG_array_type and its DW_TAG_base_type for the array while
after your change DWARF now contains only empty
DW_TAG_array_type(DW_AT_declaration).

I am preparing LLDB support for .debug_types (based on off-trunk
implementation by Greg Clayton) which is why I found this regression.
	06/06: Implement .debug_types
	https://reviews.llvm.org/D61505
But LLDB is in fact unrelated to this regression, one can test the clang
regression just by GDB.

I have provided DWARF dump from GNU binutils readelf as I am more used to it,
you can get the same output from 'llvm-dwarfdump -debug-types'.


Regards,
Jan


On Thu, 09 May 2019 23:20:15 +0200, David Blaikie wrote:
> Hey Jan - sorry, I don't really understand what's being described in this
> failure/email.
> 
> Could you explain it to me/help me understand it?
> 
> On Thu, May 9, 2019 at 1:26 PM Jan Kratochvil <jan.kratochvil at redhat.com>
> wrote:
> 
> > On Wed, 24 Apr 2019 20:09:44 +0200, David Blaikie via llvm-commits wrote:
> > > Author: dblaikie
> > > Date: Wed Apr 24 11:09:44 2019
> > > New Revision: 359122
> > >
> > > URL: http://llvm.org/viewvc/llvm-project?rev=359122&view=rev
> > > Log:
> > > DebugInfo: Emit only declarations (not whole definitions) of non-unit
> > user defined types into type units
> >
> > 832c7d9f36bcb7a99113999439c82390b31919bd is the first bad commit
> > commit 832c7d9f36bcb7a99113999439c82390b31919bd
> > Author: David Blaikie <dblaikie at gmail.com>
> > Date:   Wed Apr 24 18:09:44 2019 +0000
> >     DebugInfo: Emit only declarations (not whole definitions) of non-unit
> > user defined types into type units
> >
> > -fdebug-types-section no longer produces needed type definitions.
> >
> > -fdebug-types-section support for LLDB I am going to submit/update
> > hopefully
> > tomorrow:
> >         06/06: Implement .debug_types
> >         https://reviews.llvm.org/D61505
> >
> > ../llvm-monorepo-clangassert/bin/clang++ -o 1 -g -fdebug-types-section
> > lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-smart-array/main.cpp;gdb
> > -batch ./1 -ex 'b 59' -ex r -ex 'p other'
> >
> > FAIL = 832c7d9f36bcb7a99113999439c82390b31919bd
> > PASS = 832c7d9f36bcb7a99113999439c82390b31919bd^
> >
> > FAIL: $1 = {strarr = 0x7fffffffcba0, strptr = 0x416e70 "Nested Hello
> > world!", intarr = 0x7fffffffcbc8, flarr = 0x7fffffffcbdc}
> > PASS: $1 = {strarr = "Nested Hello
> > world!\000\377\377\377\377`\\\305\367\377\177\000", strptr = 0x416e70
> > "Nested Hello world!", intarr = {9, 8, 7, 6, 5}, flarr = {25.5, 25.25,
> > 25.125, 26.75, 27.375, 27.5, 26.125}}
> >
> > FAIL:
> > Contents of the .debug_types section:
> >  <2><af>: Abbrev Number: 3 (DW_TAG_member)
> >     <b0>   DW_AT_name        : (indirect string, offset: 0x245): strarr
> >     <b4>   DW_AT_type        : <0xed>
> >     <b8>   DW_AT_decl_file   : 6
> >     <b9>   DW_AT_decl_line   : 21
> >     <ba>   DW_AT_data_member_location: 0
> >  <1><ed>: Abbrev Number: 8 (DW_TAG_array_type)
> >     <ee>   DW_AT_declaration : 1
> >
> > PASS:
> > Contents of the .debug_types section:
> >  <2><af>: Abbrev Number: 3 (DW_TAG_member)
> >     <b0>   DW_AT_name        : (indirect string, offset: 0x245): strarr
> >     <b4>   DW_AT_type        : <0xed>
> >     <b8>   DW_AT_decl_file   : 6
> >     <b9>   DW_AT_decl_line   : 21
> >     <ba>   DW_AT_data_member_location: 0
> >  <1><ed>: Abbrev Number: 8 (DW_TAG_array_type)
> >     <ee>   DW_AT_type        : <0xf9>
> >  <2><f2>: Abbrev Number: 9 (DW_TAG_subrange_type)
> >     <f3>   DW_AT_type        : <0x100>
> >     <f7>   DW_AT_count       : 32
> >  <2><f8>: Abbrev Number: 0
> >  <1><f9>: Abbrev Number: 4 (DW_TAG_base_type)
> >     <fa>   DW_AT_name        : (indirect string, offset: 0xf5): char
> >     <fe>   DW_AT_encoding    : 6        (signed char)
> >     <ff>   DW_AT_byte_size   : 1
> >  <1><100>: Abbrev Number: 10 (DW_TAG_base_type)
> >     <101>   DW_AT_name        : (indirect string, offset: 0x24c):
> > __ARRAY_SIZE_TYPE__
> >     <105>   DW_AT_byte_size   : 8
> >     <106>   DW_AT_encoding    : 7       (unsigned)
> >
> >
> > Regards,
> > Jan
> >