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