Re: [PATCH][1/n] dwarf2out refactoring for early (LTO) debug

On 08/19/2015 02:55 PM, Aldy Hernandez wrote:
> On 08/19/2015 06:45 AM, Richard Biener wrote:
> 
> [copying gdb folks]

Thanks.

> 
>> On Tue, 18 Aug 2015, Aldy Hernandez wrote:
>>
>>> On 08/18/2015 07:20 AM, Richard Biener wrote:
> 
> [snip]
> 
>> The patch below has passed bootstrap & regtest on x86_64-unknown-linux-gnu
>> as well as gdb testing.  Twice unpatched, twice patched - results seem
>> to be somewhat unstable!?  I even refrained from using any -j with
>> make check-gdb...  maybe it's just contrib/test_summary not coping well
>> with gdb?  any hints?  Difference between unpatched run 1 & 2 is
>> for example
>>
>> --- results.unpatched   2015-08-19 15:08:36.152899926 +0200
>> +++ results.unpatched2  2015-08-19 15:29:46.902060797 +0200
>> @@ -209,7 +209,6 @@
>>   WARNING: remote_expect statement without a default case?!
>>   WARNING: remote_expect statement without a default case?!
>>   WARNING: remote_expect statement without a default case?!
>> -FAIL: gdb.base/varargs.exp: print find_max_float_real(4, fc1, fc2, fc3,
>> fc4)


if {![target_info exists gdb,skip_float_tests]} {
    gdb_test_stdio "print find_max_double(5,1.0,17.0,2.0,3.0,4.0)" \
        "find_max\\(.*\\) returns 17\\.000000\[ \r\n\]+" \
        ".\[0-9\]+ = 17" \
        "print find_max_double(5,1.0,17.0,2.0,3.0,4.0)"
}

# Test _Complex type here if supported.
if [support_complex_tests] {
    global gdb_prompt

    set test "print find_max_float_real(4, fc1, fc2, fc3, fc4)"
    gdb_test $test ".*= 4 \\+ 4 \\* I" $test

>>   FAIL: gdb.cp/inherit.exp: print g_vD
>>   FAIL: gdb.cp/inherit.exp: print g_vE
>>   FAIL: gdb.cp/no-dmgl-verbose.exp: setting breakpoint at 'f(std::string)'
>> @@ -238,6 +237,7 @@
>>   UNRESOLVED: gdb.fortran/types.exp: set print sevenbit-strings
>>   FAIL: gdb.fortran/whatis_type.exp: run to MAIN__
>>   WARNING: remote_expect statement without a default case?!
>> +FAIL: gdb.gdb/complaints.exp: print symfile_complaints->root->fmt


    # Prime the system
    gdb_test_stdio "call complaint (&symfile_complaints, \"Register a complaint\")" \
            "During symbol reading, Register a complaint."

    # Check that the complaint was inserted and where
    gdb_test "print symfile_complaints->root->fmt" \
            ".\[0-9\]+ =.*\"Register a complaint\""


So in both cases, there was a "gdb_test_stdio" test just before
the test that failed.  gdb_test_stdio is new, and it expects output
from two different spawn ids simultaneously.  Sounds like it still
needs fixing...  I'll guess that Richard has a much faster machine than
my getting-old laptop, which exposes races that I didn't trip on...

> This is somewhat expected. Well, at least I never found a good 
> explanation. Some tests seemed to be thread related and inconsistent. 
> Others, I have no idea.
> 

Indeed there are still some threading tests that unfortunately still
cause intermittent fails.  We've been fixing them but it's a
slow process.  Judging by the GDB build bots, x86_64 GNU/Linux
testing seems to be mostly stable though.  There's one DejaGNU issue
that is consistently causing trouble  -- see below.

> After running the tests enough times I got a feeling of which tests 
> would always pass, and use those as reference. It was confusing at 
> first. Perhaps the GDB folks could shed some light? I've found them very 
> helpful.
> 
> Also, -j made things worse. I never used it.

It gets much better if you use git master DejaGNU, to pick this up:

  http://lists.gnu.org/archive/html/dejagnu/2015-07/msg00005.html

Thanks,
Pedro Alves