Re: review request: implementing DW_AT_endianity

[Simon Marchi <simark at simark dot 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