sim: d10v: link in missing testsuite
Commit Message
Looks like historical restructuring in this dir lost the d10v-elf subdir
and no one noticed in the meantime. Re-add it to the testsuite.
There are some failures, but better some tests get run than none at all.
Committed.
---
sim/testsuite/ChangeLog | 5 +++++
sim/testsuite/configure | 11 ++++++++---
sim/testsuite/configure.ac | 3 +++
3 files changed, 16 insertions(+), 3 deletions(-)
Comments
On Mon, 30 Mar 2015, Mike Frysinger wrote:
> Looks like historical restructuring in this dir lost the d10v-elf subdir
> and no one noticed in the meantime.
Wow... And no port maintainer to frown at.
> Re-add it to the testsuite.
>
> There are some failures, but better some tests get run than none at all.
Meh... I agree it should be enabled, but as this particular
harness doesn't summarize the results, the value of a passing
subset is much lessened...
(I have to disable d10v sim testing -i.e. just building it-
in my sim autotester, which is all-must-pass-or-nothing anyway.)
Is the attached sim d10v-elf testsuite run log consistent with
your results? A "grep -c Error log" yields 25, FWIW.
brgds, H-P
On 02 Apr 2015 12:53, Hans-Peter Nilsson wrote:
> On Mon, 30 Mar 2015, Mike Frysinger wrote:
> > Looks like historical restructuring in this dir lost the d10v-elf subdir
> > and no one noticed in the meantime.
>
> Wow... And no port maintainer to frown at.
bisecting down, it was a general refactor that broke it ... 10 years ago ;)
> > Re-add it to the testsuite.
> >
> > There are some failures, but better some tests get run than none at all.
>
> Meh... I agree it should be enabled, but as this particular
> harness doesn't summarize the results, the value of a passing
> subset is much lessened...
it helped me verify my nrun refactor didn't screw things up. i was missing some
parts which would lead to a segfault early on.
> (I have to disable d10v sim testing -i.e. just building it-
> in my sim autotester, which is all-must-pass-or-nothing anyway.)
see the patch i posted & pushed
> Is the attached sim d10v-elf testsuite run log consistent with
> your results? A "grep -c Error log" yields 25, FWIW.
all the *-elf subdirs of sim/testsuite/ are like this and suck horribly. i
think i'll pull all the sim/ subdirs out into the higher level and rewrite these
to use the same dejagnu framework.
obnoxiously, this crappy framework supports parallel test running while dejagnu
does not. i'm not sure if there's any way to make the dejagnu do parallel ...
it's really really painful for some targets like frv & bfin which have hundreds
of tests.
-mike
On Thu, Apr 2, 2015 at 5:39 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> obnoxiously, this crappy framework supports parallel test running while dejagnu
> does not. i'm not sure if there's any way to make the dejagnu do parallel ...
> it's really really painful for some targets like frv & bfin which have hundreds
> of tests.
> -mike
Maybe mimic what gdb does for parallel testing?
On 02 Apr 2015 23:16, Doug Evans wrote:
> On Thu, Apr 2, 2015 at 5:39 PM, Mike Frysinger wrote:
> > obnoxiously, this crappy framework supports parallel test running while dejagnu
> > does not. i'm not sure if there's any way to make the dejagnu do parallel ...
> > it's really really painful for some targets like frv & bfin which have hundreds
> > of tests.
>
> Maybe mimic what gdb does for parallel testing?
my vague recollection is that gdb has sharded the exp files into arbitrary sets
so as to get some level of parallelism -- it's still at the exp level, and the
individual tests in a single exp are run in serial. is that accurate ?
-mike
On Fri, Apr 3, 2015 at 12:11 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On 02 Apr 2015 23:16, Doug Evans wrote:
>> On Thu, Apr 2, 2015 at 5:39 PM, Mike Frysinger wrote:
>> > obnoxiously, this crappy framework supports parallel test running while dejagnu
>> > does not. i'm not sure if there's any way to make the dejagnu do parallel ...
>> > it's really really painful for some targets like frv & bfin which have hundreds
>> > of tests.
>>
>> Maybe mimic what gdb does for parallel testing?
>
> my vague recollection is that gdb has sharded the exp files into arbitrary sets
> so as to get some level of parallelism -- it's still at the exp level, and the
> individual tests in a single exp are run in serial. is that accurate ?
> -mike
Yes.
If there is otherwise only one .exp, one thing one could do is
generate the .exp's for each shard.
@@ -1,3 +1,8 @@
+2015-03-30 Mike Frysinger <vapier@gentoo.org>
+
+ * configure.ac: Add d10v-*-elf.
+ * configure: Regenerate.
+
2015-03-29 Mike Frysinger <vapier@gentoo.org>
* lib/sim-defs.exp (run_sim_test): Declare seen_output as 0. When
@@ -614,7 +614,8 @@ enable_option_checking
ac_precious_vars='build_alias
host_alias
target_alias'
-ac_subdirs_all='frv-elf
+ac_subdirs_all='d10v-elf
+frv-elf
m32r-elf
mips64el-elf'
@@ -1792,10 +1793,14 @@ test -n "$target_alias" &&
# Configure sub-directory for appropriate targets
case ${target} in
- frv-*-elf )
+ d10v-*-elf )
+
+subdirs="$subdirs d10v-elf"
-subdirs="$subdirs frv-elf"
+ ;;
+ frv-*-elf )
+ subdirs="$subdirs frv-elf"
;;
m32r-*-elf )
@@ -14,6 +14,9 @@ AC_CANONICAL_SYSTEM
# Configure sub-directory for appropriate targets
case ${target} in
+ d10v-*-elf )
+ AC_CONFIG_SUBDIRS(d10v-elf)
+ ;;
frv-*-elf )
AC_CONFIG_SUBDIRS(frv-elf)
;;