[testsuite] Fix gcc.dg/debug/dwarf2/inline5.c with Solaris as (PR debug/87451)

Wed Feb 6 17:27:00 GMT 2019

On February 6, 2019 3:47:19 PM GMT+01:00, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote:
>Hi Richard,
>
>> On Fri, 4 Jan 2019, Rainer Orth wrote:
>>
>>> Hi Richard,
>>> 
>>> >> On Thu, 3 Jan 2019, Rainer Orth wrote:
>>> >>
>>> >>> gcc.dg/debug/dwarf2/inline5.c currently FAILs with Solaris as
>(both
>>> >>> sparc and x86):
>>> >>> 
>>> >>> FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not \\\\(DIE
>>> >>> \\\\(0x([0-9a-f]*)\\\\) DW_TAG_lexical_block\\\\)[^#/!]*[#/!]
>>> >>> [^(].*DW_TAG_lexical_block\\\\)[^#/!x]*x\\\\1[^#/!]*[#/!]
>>> >>> DW_AT_abstract_origin
>>> >>> FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times
>>> >>> DW_TAG_lexical_block\\\\)[^#/!]*[#/!] \\\\(DIE
>\\\\(0x[0-9a-f]*\\\\)
>>> >>> DW_TAG_variable 1
>>> >>> 
>>> >>> The first failure seems to be caused because .* performs
>multiline
>>> >>> matches by default in Tcl; tightening it to [^\n]* avoids the
>problem.
>>> >>
>>> >> Hmm, but the matches are supposed to match multiple lines...  how
>>> >> does it fail for you?
>>> >
>>> > it matches all of
>>> >
>>> > (DIE (0x19f) DW_TAG_lexical_block)
>>> >         .byte   0xd     / uleb128 0xd; (DIE (0x1a0)
>DW_TAG_variable)
>>> >         .ascii "j"      / DW_AT_name
>>> >         .byte   0x1     / DW_AT_decl_file
>(/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c)
>>> >         .byte   0x12    / DW_AT_decl_line
>>> >         .byte   0x14    / DW_AT_decl_column
>>> >         .long   0x17f   / DW_AT_type
>>> >         .byte   0       / end of children of DIE 0x19f
>>> >         .byte   0       / end of children of DIE 0x184
>>> >         .byte   0xe     / uleb128 0xe; (DIE (0x1ac)
>DW_TAG_subprogram)
>>> >         .long   0x184   / DW_AT_abstract_origin
>>> >         .long   .LFB0   / DW_AT_low_pc
>>> >         .long   .LFE0-.LFB0     / DW_AT_high_pc
>>> >         .byte   0x1     / uleb128 0x1; DW_AT_frame_base
>>> >         .byte   0x9c    / DW_OP_call_frame_cfa
>>> >                         / DW_AT_GNU_all_call_sites
>>> >         .byte   0xf     / uleb128 0xf; (DIE (0x1bb)
>DW_TAG_formal_parameter)
>>> >         .long   0x195   / DW_AT_abstract_origin
>>> >         .byte   0x2     / uleb128 0x2; DW_AT_location
>>> >         .byte   0x91    / DW_OP_fbreg
>>> >         .byte   0       / sleb128 0
>>> >         .byte   0x6     / uleb128 0x6; (DIE (0x1c3)
>DW_TAG_lexical_block)
>>> >         .long   0x19f   / DW_AT_abstract_origin
>>> >
>>> > while with gas there's instead
>>> >
>>> > 	.uleb128 0xc	/ (DIE (0xad) DW_TAG_lexical_block)
>>> > 	.uleb128 0xd	/ (DIE (0xae) DW_TAG_variable)
>>> > 	.ascii "j\0"	/ DW_AT_name
>>> > 	.byte	0x1	/ DW_AT_decl_file
>(/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c)
>>> >
>>> > i.e. the pattern doesn't match with gas due to the [^(] while with
>as we
>>> > have uleb128 first which does match, producing the failure (which
>shows
>>> > that that part of my patch is wrong).
>>> 
>>> I still have a hard time determining what to do here.  I've now
>reverted
>>> the tree to r264642, i.e. the one before the PR debug/87443 patch. 
>Then
>>> I build on x86_64-pc-linux-gnu and ran the inline5.c testcase
>against
>>> the old compiler.  I'd have expected all the scan-assembler* tests
>to
>>> FAIL here, but instead I get
>>> 
>>> PASS: gcc.dg/debug/dwarf2/inline5.c (test for excess errors)
>>> PASS: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times
>>> DW_TAG_inlined_subrouti
>>> ne 2
>>> FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times
>>> DW_TAG_lexical_block\\)
>>> [^#/!]*[#/!] DW_AT_abstract_origin 2
>>> PASS: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times
>>> DW_TAG_lexical_block\\)
>>> [^#/!]*[#/!] \\(DIE \\(0x[0-9a-f]*\\) DW_TAG_variable 1
>>> PASS: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not \\(DIE
>>> \\(0x([0-9a-f]*)\\
>>> ) DW_TAG_lexical_block\\)[^#/!]*[#/!]
>>> [^(].*DW_TAG_lexical_block\\)[^#/!x]*x\\1[
>>> ^#/!]*[#/!] DW_AT_abstract_origin
>>> FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not
>>> DW_TAG_lexical_block\\)[^
>>> #/!x]*x([0-9a-f]*)[^#/!]*[#/!] DW_AT_abstract_origin.*\\(DIE
>\\(0x\\1\\)
>>> DW_TAG_
>>> lexical_block\\)[^#/!]*[#/!] DW_AT
>>> 
>>> i.e. the problematic scan-assembler-not test PASSes before and after
>>> your patch, making it hard to determine what that test is guarding
>>> against (i.e. what is matched on Linux/x86_64 or Solaris with gas)
>and
>>> adapting it to the Solaris as syntax.
>>
>> Yeah, the issue is I applied patches in another order than I
>developed
>> the testcases...  I think you need to back out the PR87428/87362
>> fix to see this FAIL happening.
>>
>> What we want to not see is a lexical block used as abstract origin
>> that has further attributes.  GCC 8 shows bogus DWARF:
>>
>>  <2><5c>: Abbrev Number: 4 (DW_TAG_inlined_subroutine)
>>     <5d>   DW_AT_abstract_origin: <0xa9>
>>     <61>   DW_AT_low_pc      : 0xf
>>     <69>   DW_AT_high_pc     : 0xf
>>     <71>   DW_AT_call_file   : 1
>>     <72>   DW_AT_call_line   : 10
>>     <73>   DW_AT_call_column : 20
>>  <3><74>: Abbrev Number: 5 (DW_TAG_formal_parameter)
>>     <75>   DW_AT_abstract_origin: <0xba>
>>     <79>   DW_AT_location    : 0x0 (location list)
>>  <3><7d>: Abbrev Number: 6 (DW_TAG_lexical_block)
>>     <7e>   DW_AT_abstract_origin: <0xf1>
>>     <82>   DW_AT_low_pc      : 0xf
>> ...
>>  <1><a9>: Abbrev Number: 10 (DW_TAG_subprogram)
>>     <aa>   DW_AT_external    : 1
>>     <aa>   DW_AT_name        : foo
>>     <ae>   DW_AT_decl_file   : 1
>>     <af>   DW_AT_decl_line   : 1
>> (abstract instance)
>> ...
>>  <2><c4>: Abbrev Number: 12 (DW_TAG_lexical_block)
>>  <3><c5>: Abbrev Number: 13 (DW_TAG_variable)
>>     <c6>   DW_AT_name        : j
>>     <c8>   DW_AT_decl_file   : 1
>> ...
>>  <1><d1>: Abbrev Number: 14 (DW_TAG_subprogram)
>>     <d2>   DW_AT_abstract_origin: <0xa9>
>>     <d6>   DW_AT_low_pc      : 0x0
>>     <de>   DW_AT_high_pc     : 0xf
>> (concrete instance)
>> ...
>>  <2><f1>: Abbrev Number: 15 (DW_TAG_lexical_block)
>>     <f2>   DW_AT_low_pc      : 0x0
>>     <fa>   DW_AT_high_pc     : 0xe
>>
>> so the inline instance DW_TAG_lexical_block at 0x7d should not
>> refer tho this one but to the DW_TAG_lexical_block in the
>> abstract instance.
>>
>> I knew it was very twiddly to come up with a way to test for this
>> and I ultimatively settled with a scan-assembler-not ...
>>
>> That the order of abstract and concrete instance DIEs isn't
>> reliable makes things worse.
>>
>> Ideas welcome but I'd consider XFAILing this for non-gas a valid
>> solution ;)
>
>I'm only now getting back to this.  Reverting the tree back before
>r264594 still doesn't make test test FAIL.  I don't think it's worth
>spending any more time on this, so I'm going for the xfail instead.
>
>With the recent adjustments to allow for all comment chars, I had to
>adjust the first pattern: Solaris/x86 as uses, so ; cannot be in the
>new
>set of comment chars here:
>
>	.byte	0xc	/ uleb128 0xc; (DIE (0x19f) DW_TAG_lexical_block)
>
>Tested on i386-pc-solaris2.11, sparc and x86, as and gas as well as
>x86_64-pc-linux-gnu.
>
>Ok for mainline?

OK. 

Richard. 

>	Rainer