On February 6, 2019 3:47:19 PM GMT+01:00, Rainer Orth <r...@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
