Re: [PATCH 3/3] gdb/selftest-arch: Make register_test_foreach_arch generate arch tests lazily

[Lancelot SIX <lsix@lancelotsix.com>]

On Tue, Apr 19, 2022 at 02:55:19PM -0400, Simon Marchi wrote:
> On 2022-04-01 09:00, Lancelot SIX via Gdb-patches wrote:
> > The register_test_foreach_arch is used to instantiate a given selftest
> > for all architectures supported by GDB.  It is used in many _initialize_*
> > functions (under initialize_all_files, called by gdb_init).
> > 
> > Because the call is done during GDB's initialization, and because there
> > is no guaranty about the order in which all the _initialize_* functions
> > are executed, when register_test_foreach_arch is called, GDB is not
> > fully initialized.  Specifically, when a particular initialize function
> > is executed, only the architectures registered at that point are listed
> > by gdbarch_printable_names.
> > 
> > As a consequence, the list of selftest effectively executed depends on
> > the order the _initialize_* functions are called.  This can be observed
> > with the following:
> > 
> >     $ ./gdb/gdb \
> >         -data-directory ./gdb/data-directory \
> >         -quiet -batch -ex "maint selftest" 2>&1 \
> >         | grep -E "Ran [0-9]+ unit tests"
> >     Ran 145 unit tests, 0 failed
> >     $ GDB_REVERSE_INIT_FUNCTIONS=1 ./gdb/gdb \
> >         -data-directory ./gdb/data-directory \
> >         -quiet -batch -ex "maint selftest" 2>&1 \
> >         | grep -E "Ran [0-9]+ unit tests"
> >     Ran 82 unit tests, 0 failed
> > 
> > To fix this, make register_test_foreach_arch register a lazy selftest
> > generator.  This way when the test generator is eventually executed, all
> > architectures are registered and we do not have a dependency on the
> > order the initialize functions are executed in.
> > 
> > Tested on x86_64-linux
> 
> Hi Lancelot,
> 
> I see this new failure, when testing with the native-extended-gdbserver
> board:
> 
>     FAIL: gdb.gdb/unittest.exp: reversed initialization: maintenance selftest, failed none
> 
> Note that these two failures were already present before your patch,
> with the same board:
> 
>     FAIL: gdb.gdb/unittest.exp: no executable loaded: maintenance selftest, failed none
>     FAIL: gdb.gdb/unittest.exp: executable loaded: maintenance selftest, failed none
> 
> Simon

Hi,

Thanks for letting me know.  From the errors you show I am tempted to
think that the new failure is just the same as the previous ones.
Given that I run the selftests one more time (with gdb launched with
GDB_REVERSE_INIT_FUNCTIONS=1), if the testsuite was unable to launch
selftests before, it makes sence that this new execution produces a new
erroer.

I’ll still try to have a look to check if we can have a good condition
to skip those tests, or at least fail only once and skip the next
similar tests.

Best,
Lancelot.