Re: review request: implementing DW_AT_endianity

[Simon Marchi <simark@simark.ca>]

On 2017-10-10 14:16, Peeter Joot wrote:
>> I suggest naming this function type_byte_order.  Functions named 
>> "gdbarch_*" are usually
> 
>> those part of the gdbarch interface (defined in gdbarch.sh/.h/.c).
> 
> 
> done.
> 
>> Nice.  Assginment of fields by GDB would be a good thing to check in 
>> the test.
> 
> done.
> 
>> Ah indeed.  Do you report the gcc bugs you find to them?
> 
> I will verify first on the dev version of gcc8 that this is still an
> issue before submitting a report.
> 
>> testsuite.
> 
> It is normal to see the number of tests vary when running the test
> suite (make check -j8)?  My before and after runs had an unexpected
> difference in the numbers of tests:
> 
>                 === gdb Summary ===
> 
> 
> 
> -# of expected passes           40087
> 
> -# of unexpected failures       96
> 
> +# of expected passes           40082
> 
> +# of unexpected failures       98
> 
>  # of unexpected successes      1
> 
>  # of expected failures         67
> 
>  # of unknown successes         3
> 
> 
> My test added 4 additional expected passes (and I verified that my new
> tests ran in gdb/testsuite/gdb.log), so the number of expected
> successes should have grown by 4, not decreased by 5?  Some of the
> failures differences look like buggy tests (outputting pids and so
> forth).
> 
> I clearly didn't regress anything significant, but didn't expect the
> baseline to vary run to run.
> 
> Peeter

Yeah, it's possible for the total number of test to vary when tests 
start failing.  For example, you can have:

if [something] {
   fail "couldn't fetch variable"
   return
}

gdb_test "..."
gdb_test "..."

If it succeeds, you'll have 2 pass, 0 fail.  If [something] fails, 
you'll have 0 pass, 1 fail.  If your case you have 2 more unexpected 
failures, I would look into these, see if they are related.  Which tests 
are they from?

Simon