Re: [PATCH] Add test that exercises all bfd architecture, osabi, endian, etc. combinations

[Pedro Alves <palves at redhat dot com>]

(long time passed...)

On 03/09/2016 04:36 PM, Pedro Alves wrote:
> This adds a test that exposes several problems fixed by previous patches:
> 
> #1 - Buffer overrun when host/target formats match, but sizes don't.
>      https://sourceware.org/ml/gdb-patches/2016-03/msg00125.html
> 
> #2 - Missing handling for FR-V FR300.
>      https://sourceware.org/ml/gdb-patches/2016-03/msg00117.html
> 
> #3 - BFD architectures with spaces in their names (v850).
>      https://sourceware.org/ml/binutils/2016-03/msg00108.html
> 
> #4 - The OS ABI names with spaces issue.
>      https://sourceware.org/ml/gdb-patches/2016-03/msg00116.html
> 
> #5 - Bogus HP/PA long double format.
>      https://sourceware.org/ml/gdb-patches/2016-03/msg00122.html
> 
> #6 - Cris big endian internal error.
>      https://sourceware.org/ml/gdb-patches/2016-03/msg00126.html
> 
> #7 - Several PowerPC bfd archs/machines not handled by gdb.
>      https://sourceware.org/bugzilla/show_bug.cgi?id=19797
> 
> And hopefully helps catch others in the future.
> 
> This started out as a test that simply did,
> 
>  gdb -ex "print 1.0L"
> 
> to exercise #1 above.
> 
> Then to cover both 32-bit target / 64-bit host and the converse, I
> thought of having the testcase print the floats twice, once with the
> architecture set to "i386" and then to "i386:x86-64".  This way it
> wouldn't matter whether gdb was built as 32-bit or a 64-bit program.
> 
> Then I thought that other archs might have similar host/target
> floatformat conversion issues as well.  Instead of hardcoding some
> architectures in the test file, I thought we could just iterate over
> all bfd architectures and OS ABIs supported by the gdb build being
> tested.  This is what then exposed all the other problems listed
> above...
> 
> With an --enable-targets=all, this exercises over 14 thousand
> combinations.  Fortunately, it still consistenly runs in under a
> minute on my machine (An Intel i7-4810MQ @ 2.8 MHZ running Fedora 23),
> which I think with a parallel run is not that much of a big deal, as
> we have other similarly long tests.

This test would have caught the rl78 and rx problems that Yao
fixed today.  Clearly I should have pushed it in earlier so we would
have caught those regressions earlier.  :-/
The only reason I didn't, was that minute mentioned above.
I'm playing with splitting this test in 4 files, to bring that down
in a parallel run.  I'll repost with that.

Thanks,
Pedro Alves