Recent simulator patches broke many sims

Recent simulator patches broke many sims

[Hans-Peter Nilsson]

My autotester alerts me to build breakages for some
configurations, including frv-elf, iq2000-elf, m32r-elf,
mn10300-elf; author in ChangeLog CC:ed.

...
checking whether byte ordering is bigendian... no
Setting hardware to -DWITH_HW=1, cfi core pal glue , $(SIM_COMMON_HW_OBJS) dv-cfi.o dv-core.o dv-pal.o dv-glue.o
checking for log2 in -lm... yes
configure: error: Sorry, but hardware support in this simulator
unconditionally relies on dv-sockser.o which is unavailable for your host.
Please fix this simulator.
configure: error: /tmp/hpautotest-sim/src/sim/frv/configure failed for frv
make[1]: *** [configure-sim] Error 1
make[1]: Leaving directory `/tmp/hpautotest-sim/frv-elf'
...
checking whether byte ordering is bigendian... no
Setting hardware to -DWITH_HW=1, cfi core pal glue , $(SIM_COMMON_HW_OBJS) dv-cfi.o dv-core.o dv-pal.o dv-glue.o
checking for log2 in -lm... yes
configure: error: Sorry, but hardware support in this simulator
unconditionally relies on dv-sockser.o which is unavailable for your host.
Please fix this simulator.
configure: error: /tmp/hpautotest-sim/src/sim/iq2000/configure failed for iq2000
make[1]: Leaving directory `/tmp/hpautotest-sim/iq2000-elf'
...
checking whether byte ordering is bigendian... no
Setting hardware to -DWITH_HW=1, cfi core pal glue , $(SIM_COMMON_HW_OBJS) dv-cfi.o dv-core.o dv-pal.o dv-glue.o
checking for log2 in -lm... yes
configure: error: Sorry, but hardware support in this simulator unconditionally
relies on dv-sockser.o which is unavailable for your host. Please fix this
simulator.
configure: error: /tmp/hpautotest-sim/src/sim/m32r/configure failed for m32r
make[1]: Leaving directory `/tmp/hpautotest-sim/m32r-elf'
...
checking for time.h... (cached) yes
Setting hardware to -DWITH_HW=1, cfi core pal glue , $(SIM_COMMON_HW_OBJS) dv-cfi.o dv-core.o dv-pal.o dv-glue.o
checking for log2 in -lm... (cached) yes
configure: error: Sorry, but hardware support in this simulator
unconditionally relies on dv-sockser.o which is unavailable for your host.
Please fix this simulator.
configure: error: /tmp/hpautotest-sim/src/sim/mn10300/configure failed for mn10300
make[1]: *** [configure-sim] Error 1
make[1]: Leaving directory `/tmp/hpautotest-sim/mn10300-elf'

brgds, H-P

Re: Recent simulator patches broke many sims

[Joel Sherrill]

On 3/23/2013 5:39 PM, Hans-Peter Nilsson wrote:
> My autotester alerts me to build breakages for some
> configurations, including frv-elf, iq2000-elf, m32r-elf,
> mn10300-elf; author in ChangeLog CC:ed.

OK. Which host? How was it configured?

The intent was that it would fail on *ming* because these
simulators and sh64-elf unconditionally depend on dv-sockser.o
which does not build on mingw. But I don't have mingw to test on.

I just updated my git clone and checked frv-elf. It failed on Centos 6.x
when configured like this:

../gdb/configure --target=frv-elf --prefix=/home/joel/test-gdb/install 
--disable-sim-hardware --enable-sim --enable-sim-trace

And built successfully when configured like this:

../gdb/configure --target=frv-elf --prefix=/home/joel/test-gdb/install 
--enable-sim-hardware --enable-sim --enable-sim-trace

I can hop on IRC if you give me a channel so we can work through
this quickly. Other forms of chat are OK also. I want to run this down
so a release can happen.

--joel
> ...
> checking whether byte ordering is bigendian... no
> Setting hardware to -DWITH_HW=1, cfi core pal glue , $(SIM_COMMON_HW_OBJS) dv-cfi.o dv-core.o dv-pal.o dv-glue.o
> checking for log2 in -lm... yes
> configure: error: Sorry, but hardware support in this simulator
> unconditionally relies on dv-sockser.o which is unavailable for your host.
> Please fix this simulator.
> configure: error: /tmp/hpautotest-sim/src/sim/frv/configure failed for frv
> make[1]: *** [configure-sim] Error 1
> make[1]: Leaving directory `/tmp/hpautotest-sim/frv-elf'
> ...
> checking whether byte ordering is bigendian... no
> Setting hardware to -DWITH_HW=1, cfi core pal glue , $(SIM_COMMON_HW_OBJS) dv-cfi.o dv-core.o dv-pal.o dv-glue.o
> checking for log2 in -lm... yes
> configure: error: Sorry, but hardware support in this simulator
> unconditionally relies on dv-sockser.o which is unavailable for your host.
> Please fix this simulator.
> configure: error: /tmp/hpautotest-sim/src/sim/iq2000/configure failed for iq2000
> make[1]: Leaving directory `/tmp/hpautotest-sim/iq2000-elf'
> ...
> checking whether byte ordering is bigendian... no
> Setting hardware to -DWITH_HW=1, cfi core pal glue , $(SIM_COMMON_HW_OBJS) dv-cfi.o dv-core.o dv-pal.o dv-glue.o
> checking for log2 in -lm... yes
> configure: error: Sorry, but hardware support in this simulator unconditionally
> relies on dv-sockser.o which is unavailable for your host. Please fix this
> simulator.
> configure: error: /tmp/hpautotest-sim/src/sim/m32r/configure failed for m32r
> make[1]: Leaving directory `/tmp/hpautotest-sim/m32r-elf'
> ...
> checking for time.h... (cached) yes
> Setting hardware to -DWITH_HW=1, cfi core pal glue , $(SIM_COMMON_HW_OBJS) dv-cfi.o dv-core.o dv-pal.o dv-glue.o
> checking for log2 in -lm... (cached) yes
> configure: error: Sorry, but hardware support in this simulator
> unconditionally relies on dv-sockser.o which is unavailable for your host.
> Please fix this simulator.
> configure: error: /tmp/hpautotest-sim/src/sim/mn10300/configure failed for mn10300
> make[1]: *** [configure-sim] Error 1
> make[1]: Leaving directory `/tmp/hpautotest-sim/mn10300-elf'
>
> brgds, H-P


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Recent simulator patches broke many sims

[Joel Sherrill]

Reproduced.

(1) --enable-sim --disable-sim-hardware
(2) --enable-sim --enable-sim-hardware
(3) --enable-sim

I tested (1) and (2) above but (3) is a different case with the
addition of "always" as a possible input to SIM_AC_OPTION_HARDWARE,
it is a different path.

FYI sh64-elf should have failed also. Do you not include it in
your testing?

With any luck, I will have this fixed soon.

--joel

On 3/23/2013 5:39 PM, Hans-Peter Nilsson wrote:
> My autotester alerts me to build breakages for some
> configurations, including frv-elf, iq2000-elf, m32r-elf,
> mn10300-elf; author in ChangeLog CC:ed.
>
> ...
> checking whether byte ordering is bigendian... no
> Setting hardware to -DWITH_HW=1, cfi core pal glue , $(SIM_COMMON_HW_OBJS) dv-cfi.o dv-core.o dv-pal.o dv-glue.o
> checking for log2 in -lm... yes
> configure: error: Sorry, but hardware support in this simulator
> unconditionally relies on dv-sockser.o which is unavailable for your host.
> Please fix this simulator.
> configure: error: /tmp/hpautotest-sim/src/sim/frv/configure failed for frv
> make[1]: *** [configure-sim] Error 1
> make[1]: Leaving directory `/tmp/hpautotest-sim/frv-elf'
> ...
> checking whether byte ordering is bigendian... no
> Setting hardware to -DWITH_HW=1, cfi core pal glue , $(SIM_COMMON_HW_OBJS) dv-cfi.o dv-core.o dv-pal.o dv-glue.o
> checking for log2 in -lm... yes
> configure: error: Sorry, but hardware support in this simulator
> unconditionally relies on dv-sockser.o which is unavailable for your host.
> Please fix this simulator.
> configure: error: /tmp/hpautotest-sim/src/sim/iq2000/configure failed for iq2000
> make[1]: Leaving directory `/tmp/hpautotest-sim/iq2000-elf'
> ...
> checking whether byte ordering is bigendian... no
> Setting hardware to -DWITH_HW=1, cfi core pal glue , $(SIM_COMMON_HW_OBJS) dv-cfi.o dv-core.o dv-pal.o dv-glue.o
> checking for log2 in -lm... yes
> configure: error: Sorry, but hardware support in this simulator unconditionally
> relies on dv-sockser.o which is unavailable for your host. Please fix this
> simulator.
> configure: error: /tmp/hpautotest-sim/src/sim/m32r/configure failed for m32r
> make[1]: Leaving directory `/tmp/hpautotest-sim/m32r-elf'
> ...
> checking for time.h... (cached) yes
> Setting hardware to -DWITH_HW=1, cfi core pal glue , $(SIM_COMMON_HW_OBJS) dv-cfi.o dv-core.o dv-pal.o dv-glue.o
> checking for log2 in -lm... (cached) yes
> configure: error: Sorry, but hardware support in this simulator
> unconditionally relies on dv-sockser.o which is unavailable for your host.
> Please fix this simulator.
> configure: error: /tmp/hpautotest-sim/src/sim/mn10300/configure failed for mn10300
> make[1]: *** [configure-sim] Error 1
> make[1]: Leaving directory `/tmp/hpautotest-sim/mn10300-elf'
>
> brgds, H-P


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Recent simulator patches broke many sims

[Joel Sherrill]

[-- Attachment #1: Type: text/plain, Size: 3846 bytes --]

I have a fix. The case for *mingw* and disabling
setting SIM_AC_OPTION_HARDWARE needed to
be outside the AC_ARG_ENABLE() for --enable-sim-hardware
to account for the "always" simulators.

2013-03-23  Joel Sherrill  <joel.sherrill@oarcorp.com>

     * acinclude.m4 (SIM_AC_OPTION_HARDWARE): Move the
      mingw case to outside the AC_ARG_ENABLE() for
      --enable-sim-hardware to account for the simulators with
     "always" enabled simulator hardware.

Please review the attached patch. If it is OK, there is the next
set of questions about regenerating before I commit it.

Nearly every simulator includes common/acinclude.m4
which IMO means they need to be regenerated now.

And when you run autoheader, many end up with
changes to config.in. Which means this should be addressed.

Should I go ahead and run autoconf and autoheader in every
sim directory while committing this? Or just the directories
I previously touched?

I suspect I need to do the right thing and commit a bunch.
I don't mind doing this but ... :-D

Thoughts?

Hans.. I still think your auto-tester must not include sh64-elf or it
hadn't gotten to it yet. And it may need to test with the 3 configure
options I listed earlier for completeness.

--joel

On 3/23/2013 5:39 PM, Hans-Peter Nilsson wrote:
> My autotester alerts me to build breakages for some
> configurations, including frv-elf, iq2000-elf, m32r-elf,
> mn10300-elf; author in ChangeLog CC:ed.
>
> ...
> checking whether byte ordering is bigendian... no
> Setting hardware to -DWITH_HW=1, cfi core pal glue , $(SIM_COMMON_HW_OBJS) dv-cfi.o dv-core.o dv-pal.o dv-glue.o
> checking for log2 in -lm... yes
> configure: error: Sorry, but hardware support in this simulator
> unconditionally relies on dv-sockser.o which is unavailable for your host.
> Please fix this simulator.
> configure: error: /tmp/hpautotest-sim/src/sim/frv/configure failed for frv
> make[1]: *** [configure-sim] Error 1
> make[1]: Leaving directory `/tmp/hpautotest-sim/frv-elf'
> ...
> checking whether byte ordering is bigendian... no
> Setting hardware to -DWITH_HW=1, cfi core pal glue , $(SIM_COMMON_HW_OBJS) dv-cfi.o dv-core.o dv-pal.o dv-glue.o
> checking for log2 in -lm... yes
> configure: error: Sorry, but hardware support in this simulator
> unconditionally relies on dv-sockser.o which is unavailable for your host.
> Please fix this simulator.
> configure: error: /tmp/hpautotest-sim/src/sim/iq2000/configure failed for iq2000
> make[1]: Leaving directory `/tmp/hpautotest-sim/iq2000-elf'
> ...
> checking whether byte ordering is bigendian... no
> Setting hardware to -DWITH_HW=1, cfi core pal glue , $(SIM_COMMON_HW_OBJS) dv-cfi.o dv-core.o dv-pal.o dv-glue.o
> checking for log2 in -lm... yes
> configure: error: Sorry, but hardware support in this simulator unconditionally
> relies on dv-sockser.o which is unavailable for your host. Please fix this
> simulator.
> configure: error: /tmp/hpautotest-sim/src/sim/m32r/configure failed for m32r
> make[1]: Leaving directory `/tmp/hpautotest-sim/m32r-elf'
> ...
> checking for time.h... (cached) yes
> Setting hardware to -DWITH_HW=1, cfi core pal glue , $(SIM_COMMON_HW_OBJS) dv-cfi.o dv-core.o dv-pal.o dv-glue.o
> checking for log2 in -lm... (cached) yes
> configure: error: Sorry, but hardware support in this simulator
> unconditionally relies on dv-sockser.o which is unavailable for your host.
> Please fix this simulator.
> configure: error: /tmp/hpautotest-sim/src/sim/mn10300/configure failed for mn10300
> make[1]: *** [configure-sim] Error 1
> make[1]: Leaving directory `/tmp/hpautotest-sim/mn10300-elf'
>
> brgds, H-P


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985


[-- Attachment #2: acinclude_diff.txt --]
[-- Type: text/plain, Size: 1379 bytes --]

diff --git a/sim/common/acinclude.m4 b/sim/common/acinclude.m4
index 7f98903..c716a3a 100644
--- a/sim/common/acinclude.m4
+++ b/sim/common/acinclude.m4
@@ -622,6 +622,18 @@ hardware="$hardware [$3]"
 sim_hw_cflags="-DWITH_HW=1"
 sim_hw="$hardware"
 sim_hw_objs="\$(SIM_COMMON_HW_OBJS) `echo $sim_hw | sed -e 's/\([[^ ]][[^ ]]*\)/dv-\1.o/g'`"
+# mingw does not support sockser
+# Check this independent of --enable-sim-hardware because SIM_DV_SOCKSER_O
+# may be used by simulators which "always" are enabled.
+SIM_DV_SOCKSER_O=""
+case ${host} in
+  *mingw*) ;;
+  *) SIM_DV_SOCKSER_O="dv-sockser.o"
+     AC_DEFINE_UNQUOTED(
+       [HAVE_DV_SOCKSER], 1, [Define if dv-sockser is usable.])
+     ;;
+esac
+AC_SUBST(SIM_DV_SOCKSER_O)
 AC_ARG_ENABLE(sim-hardware,
 [  --enable-sim-hardware=LIST		Specify the hardware to be included in the build.],
 [
@@ -647,16 +659,6 @@ else
       *) sim_hw="$sim_hw $i" ; sim_hw_objs="$sim_hw_objs dv-$i.o";;
     esac
   done
-  # mingw does not support sockser
-  SIM_DV_SOCKSER_O=""
-  case ${host} in
-    *mingw*) ;;
-    *) SIM_DV_SOCKSER_O="dv-sockser.o"
-       AC_DEFINE_UNQUOTED(
-         [HAVE_DV_SOCKSER], 1, [Define if dv-sockser is usable.])
-       ;;
-  esac
-  AC_SUBST(SIM_DV_SOCKSER_O)
 fi
 if test x"$silent" != x"yes" && test "$sim_hw_p" = "yes"; then
   echo "Setting hardware to $sim_hw_cflags, $sim_hw, $sim_hw_objs"

Re: Recent simulator patches broke many sims

[Hans-Peter Nilsson]

Host is some Debian; x86_64-linux.

> From: Joel Sherrill <joel.sherrill@oarcorp.com>
> Date: Sun, 24 Mar 2013 00:38:34 +0100

> I have a fix.

Great.  Thanks for attending to this so quickly.

But the patch seems mingw-specific and a host with x64_64-linux
probably still fails.  Or is "host" actually the target here?

> I suspect I need to do the right thing and commit a bunch.

Just please test-build and *really* preferably regression-test
each affected simulator.  (Build and install binutils for it.)
When they're broken I guess expediting a fix might require
less...

> Hans.. I still think your auto-tester must not include sh64-elf or it
> hadn't gotten to it yet.

That's right, I'm not testing all simulators, that's why I wrote
*some* simulators and *including*.  The set of simulators was
what built and was error free some-long-time-ago.

> And it may need to test with the 3 configure
> options I listed earlier for completeness.

No, I'm not aiming for completeness, the autotester is there
only to check that people do the bare essentials as to test
before checking in. 1/2 ;)

brgds, H-P

Re: Recent simulator patches broke many sims

[Hans-Peter Nilsson]

> From: Joel Sherrill <joel.sherrill@oarcorp.com>
> Date: Sun, 24 Mar 2013 00:38:34 +0100

> Should I go ahead and run autoconf and autoheader in every
> sim directory while committing this?

Effectively yes; testing that they still build for some common host.

brgds, H-P

Re: Recent simulator patches broke many sims

[Hans-Peter Nilsson]

> From: Hans-Peter Nilsson <hp@axis.com>
> Date: Sun, 24 Mar 2013 01:00:59 +0100

> But the patch seems mingw-specific and a host with x64_64-linux
> probably still fails.  Or is "host" actually the target here?

You're taking steps to empty SIM_DV_SOCKSER_O so I guess you
didn't read this piece common to all
sim/<breaking>/configure.ac:

 if test -z "$SIM_DV_SOCKSER_O"; then
	AC_MSG_ERROR([Sorry, but hardware support in this simulator...

At this time I'd just suggest reverting your previous commits
and come back with something tested.

brgds, H-P

Re: Recent simulator patches broke many sims

[Hans-Peter Nilsson]

> From: Hans-Peter Nilsson <hp@axis.com>
> Date: Sun, 24 Mar 2013 01:00:59 +0100

> Host is some Debian; x86_64-linux.

Forgot to mention in case it wasn't obvious: I'm just
configuring with "--target ..."; nothing else option-wise.

brgds, H-P

Re: Recent simulator patches broke many sims

[Hans-Peter Nilsson]

> From: Joel Sherrill <joel.sherrill@oarcorp.com>
> Date: Sat, 23 Mar 2013 23:49:18 +0100

> And built successfully when configured like this:
> 
> ../gdb/configure --target=frv-elf --prefix=/home/joel/test-gdb/install 
> --enable-sim-hardware --enable-sim --enable-sim-trace

"gdb" as in toplevel from a gdb checkout, I presume.
(If from the gdb subdir I guess you wouldn't get very far.)
Is that why you have to add those options?

One major difference is that I use the toplevel configure after
a checkout of *the "sim" CVS module*, so not much of gdb there,
actually just MAINTAINERS and version.in.

> I can hop on IRC if you give me a channel so we can work through
> this quickly. Other forms of chat are OK also. I want to run this down
> so a release can happen.

Sometimes I'm at irc.oftc.net#gcc

brgds, H-P

Re: Recent simulator patches broke many sims

[Joel Sherrill]

On 3/23/2013 7:38 PM, Hans-Peter Nilsson wrote:
>> From: Joel Sherrill <joel.sherrill@oarcorp.com>
>> Date: Sat, 23 Mar 2013 23:49:18 +0100
>> And built successfully when configured like this:
>>
>> ../gdb/configure --target=frv-elf --prefix=/home/joel/test-gdb/install
>> --enable-sim-hardware --enable-sim --enable-sim-trace
> "gdb" as in toplevel from a gdb checkout, I presume.
> (If from the gdb subdir I guess you wouldn't get very far.)
> Is that why you have to add those options?
I added those options because that is the combination that initially
tripped the failure months ago. Then last week someone spotted
that mingw failed to build. Mike Frysinger and I have been trying to
come up with a configure solution that handles mingw not supporting
dv-sockser.o and some simulators always requiring it.
> One major difference is that I use the toplevel configure after
> a checkout of *the "sim" CVS module*, so not much of gdb there,
> actually just MAINTAINERS and version.in.
I don't think that's really much of an issue. Except to increase my 
build time.

I have a fix in my local tree and posted it to the list. Here is my test 
plan.

I regenerated all of the sim directories where configure.ac includes 
acinclude.m4.
That resulted in the following set of modified files on my working git 
branch:

#    modified:   bfin/configure
#    modified:   common/acinclude.m4
#    modified:   cris/configure
#    modified:   frv/configure
#    modified:   iq2000/configure
#    modified:   lm32/configure
#    modified:   m32r/configure
#    modified:   m68hc11/configure
#    modified:   mips/configure
#    modified:   mn10300/configure
#    modified:   sh64/configure

Based on that, I put together the following list of targets:

bfin-elf
cris-elf
frv-elf
iq2000-elf
lm32-elf
m32r-elfle
m68hc11-elf
mips-elf
mipstx93-elf
mn10300-elf
sh64-elf

For each of those targets, I will build with no sim-hardware argument,
--enable-sim-hardware, and --disable-sim-hardware. If the configure
and make complete successfully, I will run make check.

Any other suggestions on how to test this?

>> I can hop on IRC if you give me a channel so we can work through
>> this quickly. Other forms of chat are OK also. I want to run this down
>> so a release can happen.
> Sometimes I'm at irc.oftc.net#gcc
>
> brgds, H-P


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Recent simulator patches broke many sims

[Hans-Peter Nilsson]

> From: Joel Sherrill <joel.sherrill@oarcorp.com>
> Date: Sun, 24 Mar 2013 03:12:00 +0100

> Any other suggestions on how to test this?

No, that sounds fine to me.  There may be FAILing sim tests in
the baseline for a configuration, but comparing the log files
before and after should cover that.  And thanks for sticking
with it.

brgds, H-P

Re: Recent simulator patches broke many sims

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 3004 bytes --]

On Saturday 23 March 2013 19:38:34 Joel Sherrill wrote:
> I have a fix. The case for *mingw* and disabling
> setting SIM_AC_OPTION_HARDWARE needed to
> be outside the AC_ARG_ENABLE() for --enable-sim-hardware
> to account for the "always" simulators.

the way this code is written, the lack of indentation just gets in the way.
also doing all this processing in the 3rd arg to AC_ARG_ENABLE() is largely
pointless.

this should do it i think
-mike

--- a/sim/common/acinclude.m4
+++ b/sim/common/acinclude.m4
@@ -609,30 +609,38 @@ dnl arg[3] is a space separated list of extra target specific devices.
 AC_DEFUN([SIM_AC_OPTION_HARDWARE],
 [
 if test x"[$1]" != x"no"; then
-  sim_hw_p=yes
+  enable_sim_hardware=yes
 else
-  sim_hw_p=no
+  enable_sim_hardware=no
 fi
+
 if test "[$2]"; then
   hardware="[$2]"
 else
   hardware="cfi core pal glue"
 fi
 hardware="$hardware [$3]"
+
 sim_hw_cflags="-DWITH_HW=1"
 sim_hw="$hardware"
 sim_hw_objs="\$(SIM_COMMON_HW_OBJS) `echo $sim_hw | sed -e 's/\([[^ ]][[^ ]]*\)/dv-\1.o/g'`"
+
 AC_ARG_ENABLE(sim-hardware,
-[  --enable-sim-hardware=LIST		Specify the hardware to be included in the build.],
-[
-case "${enableval}" in
-  yes)	sim_hw_p=yes;;
-  no)	sim_hw_p=no;;
+  [AS_HELP_STRING([--enable-sim-hardware=LIST],
+                  [Specify the hardware to be included in the build.])])
+case ${enable_sim_hardware} in
+  yes)  sim_hw_p=yes;;
+  no)   sim_hw_p=no;;
   ,*)   sim_hw_p=yes; hardware="${hardware} `echo ${enableval} | sed -e 's/,/ /'`";;
   *,)   sim_hw_p=yes; hardware="`echo ${enableval} | sed -e 's/,/ /'` ${hardware}";;
-  *)	sim_hw_p=yes; hardware="`echo ${enableval} | sed -e 's/,/ /'`"'';;
+  *)    sim_hw_p=yes; hardware="`echo ${enableval} | sed -e 's/,/ /'`"'';;
 esac
+
 if test "$sim_hw_p" != yes; then
+  if test "[$1]" = "always"; then
+    AC_MSG_ERROR([Sorry, but this simulator requires that hardware support
+be enabled. Please configure without --disable-hw-support.])
+  fi
   sim_hw_objs=
   sim_hw_cflags="-DWITH_HW=0"
   sim_hw=
@@ -657,26 +665,14 @@ else
        ;;
   esac
   AC_SUBST(SIM_DV_SOCKSER_O)
-fi
-if test x"$silent" != x"yes" && test "$sim_hw_p" = "yes"; then
-  echo "Setting hardware to $sim_hw_cflags, $sim_hw, $sim_hw_objs"
-fi],[
-if test "$sim_hw_p" != yes; then
-  if test "[$1]" = "always"; then
-    AC_MSG_ERROR([Sorry, but this simulator requires that hardware support
-be enabled. Please configure without --disable-hw-support.])
+  if test x"$silent" != x"yes"; then
+    echo "Setting hardware to $sim_hw_cflags, $sim_hw, $sim_hw_objs"
   fi
-  sim_hw_objs=
-  sim_hw_cflags="-DWITH_HW=0"
-  sim_hw=
+  dnl Some devices require extra libraries.
+  case " $hardware " in
+    *" cfi "*) AC_CHECK_LIB(m, log2);;
+  esac
 fi
-if test x"$silent" != x"yes"; then
-  echo "Setting hardware to $sim_hw_cflags, $sim_hw, $sim_hw_objs"
-fi])
-dnl Some devices require extra libraries.
-case " $hardware " in
-  *" cfi "*) AC_CHECK_LIB(m, log2);;
-esac
 ])
 AC_SUBST(sim_hw_cflags)
 AC_SUBST(sim_hw_objs)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Recent simulator patches broke many sims

[Joel Sherrill]

This came in after I was done email last night. My test
run finished overnight with no horribly bad issues. I have no idea
what the make check results should be though and they could be
because I simply ran "make check" with no board specified and
no gcc for the target installed.

There were some unexpected failures but I don't know what "truth"
on that is.  I have saved logs from the test run and will do so with
the run on Mike's patch.

Starting another test run with Mike's patch.

I can put both sets of logs on an ftp server if someone wants to review
them.  Guidance on what is a bad number of "unexpected failures" on
a target is appreciated.

--joel

On 3/23/2013 9:57 PM, Mike Frysinger wrote:
> On Saturday 23 March 2013 19:38:34 Joel Sherrill wrote:
>> I have a fix. The case for *mingw* and disabling
>> setting SIM_AC_OPTION_HARDWARE needed to
>> be outside the AC_ARG_ENABLE() for --enable-sim-hardware
>> to account for the "always" simulators.
> the way this code is written, the lack of indentation just gets in the way.
> also doing all this processing in the 3rd arg to AC_ARG_ENABLE() is largely
> pointless.
>
> this should do it i think
> -mike
>
> --- a/sim/common/acinclude.m4
> +++ b/sim/common/acinclude.m4
> @@ -609,30 +609,38 @@ dnl arg[3] is a space separated list of extra target specific devices.
>   AC_DEFUN([SIM_AC_OPTION_HARDWARE],
>   [
>   if test x"[$1]" != x"no"; then
> -  sim_hw_p=yes
> +  enable_sim_hardware=yes
>   else
> -  sim_hw_p=no
> +  enable_sim_hardware=no
>   fi
> +
>   if test "[$2]"; then
>     hardware="[$2]"
>   else
>     hardware="cfi core pal glue"
>   fi
>   hardware="$hardware [$3]"
> +
>   sim_hw_cflags="-DWITH_HW=1"
>   sim_hw="$hardware"
>   sim_hw_objs="\$(SIM_COMMON_HW_OBJS) `echo $sim_hw | sed -e 's/\([[^ ]][[^ ]]*\)/dv-\1.o/g'`"
> +
>   AC_ARG_ENABLE(sim-hardware,
> -[  --enable-sim-hardware=LIST		Specify the hardware to be included in the build.],
> -[
> -case "${enableval}" in
> -  yes)	sim_hw_p=yes;;
> -  no)	sim_hw_p=no;;
> +  [AS_HELP_STRING([--enable-sim-hardware=LIST],
> +                  [Specify the hardware to be included in the build.])])
> +case ${enable_sim_hardware} in
> +  yes)  sim_hw_p=yes;;
> +  no)   sim_hw_p=no;;
>     ,*)   sim_hw_p=yes; hardware="${hardware} `echo ${enableval} | sed -e 's/,/ /'`";;
>     *,)   sim_hw_p=yes; hardware="`echo ${enableval} | sed -e 's/,/ /'` ${hardware}";;
> -  *)	sim_hw_p=yes; hardware="`echo ${enableval} | sed -e 's/,/ /'`"'';;
> +  *)    sim_hw_p=yes; hardware="`echo ${enableval} | sed -e 's/,/ /'`"'';;
>   esac
> +
>   if test "$sim_hw_p" != yes; then
> +  if test "[$1]" = "always"; then
> +    AC_MSG_ERROR([Sorry, but this simulator requires that hardware support
> +be enabled. Please configure without --disable-hw-support.])
> +  fi
>     sim_hw_objs=
>     sim_hw_cflags="-DWITH_HW=0"
>     sim_hw=
> @@ -657,26 +665,14 @@ else
>          ;;
>     esac
>     AC_SUBST(SIM_DV_SOCKSER_O)
> -fi
> -if test x"$silent" != x"yes" && test "$sim_hw_p" = "yes"; then
> -  echo "Setting hardware to $sim_hw_cflags, $sim_hw, $sim_hw_objs"
> -fi],[
> -if test "$sim_hw_p" != yes; then
> -  if test "[$1]" = "always"; then
> -    AC_MSG_ERROR([Sorry, but this simulator requires that hardware support
> -be enabled. Please configure without --disable-hw-support.])
> +  if test x"$silent" != x"yes"; then
> +    echo "Setting hardware to $sim_hw_cflags, $sim_hw, $sim_hw_objs"
>     fi
> -  sim_hw_objs=
> -  sim_hw_cflags="-DWITH_HW=0"
> -  sim_hw=
> +  dnl Some devices require extra libraries.
> +  case " $hardware " in
> +    *" cfi "*) AC_CHECK_LIB(m, log2);;
> +  esac
>   fi
> -if test x"$silent" != x"yes"; then
> -  echo "Setting hardware to $sim_hw_cflags, $sim_hw, $sim_hw_objs"
> -fi])
> -dnl Some devices require extra libraries.
> -case " $hardware " in
> -  *" cfi "*) AC_CHECK_LIB(m, log2);;
> -esac
>   ])
>   AC_SUBST(sim_hw_cflags)
>   AC_SUBST(sim_hw_objs)


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Recent simulator patches broke many sims

[Hans-Peter Nilsson]

> From: Joel Sherrill <joel.sherrill@oarcorp.com>
> Date: Sun, 24 Mar 2013 15:45:27 +0100

> This came in after I was done email last night. My test
> run finished overnight with no horribly bad issues. I have no idea
> what the make check results should be though and they could be
> because I simply ran "make check" with no board specified and
> no gcc for the target installed.

This would be no news to *you*, but for the record:

You need a board (make check RUNTESTFLAGS=--target_board=$board
with e.g. board=cris-sim).  All boards are in "recent"
dejagnu-1.5 IIRC and most in ancient dejagnu-1.4.4.  You need
installed binutils (e.g. in some temp location added to PATH for
the duration of the test-run) for each sim configuration as
mentioned.  I don't run with target gcc; not needed for the
level of smoke test I'm after and I guess not for this change
either.

> There were some unexpected failures but I don't know what "truth"
> on that is.

The truth is in the baseline.

>  I have saved logs from the test run and will do so with
> the run on Mike's patch.
> 
> Starting another test run with Mike's patch.
> 
> I can put both sets of logs on an ftp server if someone wants to review
> them.  Guidance on what is a bad number of "unexpected failures" on
> a target is appreciated.

You compare against a baseline you create without your patches;
comparing old/new build logs should be sufficient.

Having said all that, I think just a successful *build* of each
sim would be sufficient here, if your grep can find no
sockser-specific tests in the target sim test-suites.

brgds, H-P

Re: Recent simulator patches broke many sims

[Joel Sherrill]

On 3/24/2013 6:23 PM, Hans-Peter Nilsson wrote:
>> From: Joel Sherrill <joel.sherrill@oarcorp.com>
>> Date: Sun, 24 Mar 2013 15:45:27 +0100
>> This came in after I was done email last night. My test
>> run finished overnight with no horribly bad issues. I have no idea
>> what the make check results should be though and they could be
>> because I simply ran "make check" with no board specified and
>> no gcc for the target installed.
> This would be no news to *you*, but for the record:
It's not a surprise. I fairly regularly run the gcc tests for RTEMS
and they need a baseboard specified.  I knew binutils didn't. And
assumed (incorrectly) that applied to the simulator and gdb
as well.
> You need a board (make check RUNTESTFLAGS=--target_board=$board
> with e.g. board=cris-sim).  All boards are in "recent"
> dejagnu-1.5 IIRC and most in ancient dejagnu-1.4.4.  You need
> installed binutils (e.g. in some temp location added to PATH for
> the duration of the test-run) for each sim configuration as
> mentioned.  I don't run with target gcc; not needed for the
> level of smoke test I'm after and I guess not for this change
> either.
I will add this to my testing script for RTEMS targets. Is there somewhere
to email these results like gcc?
>> There were some unexpected failures but I don't know what "truth"
>> on that is.
> The truth is in the baseline.
Using 7.5.91 for that.  Just got home and the build for that is done.
>>   I have saved logs from the test run and will do so with
>> the run on Mike's patch.
>>
>> Starting another test run with Mike's patch.
>>
>> I can put both sets of logs on an ftp server if someone wants to review
>> them.  Guidance on what is a bad number of "unexpected failures" on
>> a target is appreciated.
> You compare against a baseline you create without your patches;
> comparing old/new build logs should be sufficient.
>
> Having said all that, I think just a successful *build* of each
> sim would be sufficient here, if your grep can find no
> sockser-specific tests in the target sim test-suites.
OK. I will follow up with a test results email.
> brgds, H-P


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Recent simulator patches broke many sims

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1429 bytes --]

On Sunday 24 March 2013 19:23:28 Hans-Peter Nilsson wrote:
> > From: Joel Sherrill <joel.sherrill@oarcorp.com>
> > Date: Sun, 24 Mar 2013 15:45:27 +0100
> > 
> > This came in after I was done email last night. My test
> > run finished overnight with no horribly bad issues. I have no idea
> > what the make check results should be though and they could be
> > because I simply ran "make check" with no board specified and
> > no gcc for the target installed.
> 
> This would be no news to *you*, but for the record:
> 
> You need a board (make check RUNTESTFLAGS=--target_board=$board
> with e.g. board=cris-sim).  All boards are in "recent"
> dejagnu-1.5 IIRC and most in ancient dejagnu-1.4.4.  You need
> installed binutils (e.g. in some temp location added to PATH for
> the duration of the test-run) for each sim configuration as
> mentioned.  I don't run with target gcc; not needed for the
> level of smoke test I'm after and I guess not for this change
> either.

that's not entirely true.  many (all but cris?) sims run & pass just fine 
without needing to explicitly pass magic flags.  i know the Blackfin and frv 
sims can build & run pretty much all their tests w/out requiring board flags.

imo, requiring manual board selection like this is archaic for no good reason.  
i never test sims with specific flags, nor do i plan on starting.  `make check-
sim` is my limit of testing.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Recent simulator patches broke many sims

[Hans-Peter Nilsson]

> From: Mike Frysinger <vapier@gentoo.org>
> Date: Tue, 26 Mar 2013 17:25:39 +0100

On Sunday 24 March 2013 19:23:28 Hans-Peter Nilsson wrote:
> > From: Joel Sherrill <joel.sherrill@oarcorp.com>
> > Date: Sun, 24 Mar 2013 15:45:27 +0100
> > 
> > This came in after I was done email last night. My test
> > run finished overnight with no horribly bad issues. I have no idea
> > what the make check results should be though and they could be
> > because I simply ran "make check" with no board specified and
> > no gcc for the target installed.
> 
> This would be no news to *you*, but for the record:
> 
> You need a board (make check RUNTESTFLAGS=--target_board=$board
> with e.g. board=cris-sim).  All boards are in "recent"
> dejagnu-1.5 IIRC and most in ancient dejagnu-1.4.4.  You need
> installed binutils (e.g. in some temp location added to PATH for
> the duration of the test-run) for each sim configuration as
> mentioned.  I don't run with target gcc; not needed for the
> level of smoke test I'm after and I guess not for this change
> either.

> that's not entirely true.  many (all but cris?)

I don't think it's different but I don't plan to test without...

> sims run &
> pass just fine without needing to explicitly pass magic flags.

It is entirely true that when a board is specified, all work.

Now that you mention it, someone *did* do some changes to allow
simulator tests to run without specifying a board - IIRC in some
situations, assuming no special linker flags or such needed and
no compiler toolchain (or no flags or libraries using simulator
hooks).  Reading ChangeLogs it seems it was you, on 2010-04-26.

> i know the Blackfin and frv sims can build & run pretty much
> all their tests w/out requiring board flags.
> 
> imo, requiring manual board selection like this is archaic for
> no good reason.

One good reason IMO is that when specifying a board, all
toolchain parts test alike, rather than sim (after 2010-04-26)
being a special case (and binutils, mostly for not needing to
run things to avoid FAILs or hanging tests).

> i never test sims with specific flags, nor do i plan on starting.  `make check-
> sim` is my limit of testing.

I guess by "never" you don't refer to the time before
2010-04-26. :)  *Before* the mentioned change, you *had* to, or
all sim runs would hang, which arguably wasn't very graceful...

brgds, H-P

Re: Recent simulator patches broke many sims

[Joel Sherrill]

How about a commit so the other Joel can release?

--joel
RTEMS

On 3/26/2013 12:12 PM, Hans-Peter Nilsson wrote:
>> From: Mike Frysinger <vapier@gentoo.org>
>> Date: Tue, 26 Mar 2013 17:25:39 +0100
> On Sunday 24 March 2013 19:23:28 Hans-Peter Nilsson wrote:
>>> From: Joel Sherrill <joel.sherrill@oarcorp.com>
>>> Date: Sun, 24 Mar 2013 15:45:27 +0100
>>>
>>> This came in after I was done email last night. My test
>>> run finished overnight with no horribly bad issues. I have no idea
>>> what the make check results should be though and they could be
>>> because I simply ran "make check" with no board specified and
>>> no gcc for the target installed.
>> This would be no news to *you*, but for the record:
>>
>> You need a board (make check RUNTESTFLAGS=--target_board=$board
>> with e.g. board=cris-sim).  All boards are in "recent"
>> dejagnu-1.5 IIRC and most in ancient dejagnu-1.4.4.  You need
>> installed binutils (e.g. in some temp location added to PATH for
>> the duration of the test-run) for each sim configuration as
>> mentioned.  I don't run with target gcc; not needed for the
>> level of smoke test I'm after and I guess not for this change
>> either.
>> that's not entirely true.  many (all but cris?)
> I don't think it's different but I don't plan to test without...
>
>> sims run &
>> pass just fine without needing to explicitly pass magic flags.
> It is entirely true that when a board is specified, all work.
>
> Now that you mention it, someone *did* do some changes to allow
> simulator tests to run without specifying a board - IIRC in some
> situations, assuming no special linker flags or such needed and
> no compiler toolchain (or no flags or libraries using simulator
> hooks).  Reading ChangeLogs it seems it was you, on 2010-04-26.
>
>> i know the Blackfin and frv sims can build & run pretty much
>> all their tests w/out requiring board flags.
>>
>> imo, requiring manual board selection like this is archaic for
>> no good reason.
> One good reason IMO is that when specifying a board, all
> toolchain parts test alike, rather than sim (after 2010-04-26)
> being a special case (and binutils, mostly for not needing to
> run things to avoid FAILs or hanging tests).
>
>> i never test sims with specific flags, nor do i plan on starting.  `make check-
>> sim` is my limit of testing.
> I guess by "never" you don't refer to the time before
> 2010-04-26. :)  *Before* the mentioned change, you *had* to, or
> all sim runs would hang, which arguably wasn't very graceful...
>
> brgds, H-P


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Recent simulator patches broke many sims

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 618 bytes --]

On Saturday 23 March 2013 22:57:45 Mike Frysinger wrote:
> On Saturday 23 March 2013 19:38:34 Joel Sherrill wrote:
> > I have a fix. The case for *mingw* and disabling
> > setting SIM_AC_OPTION_HARDWARE needed to
> > be outside the AC_ARG_ENABLE() for --enable-sim-hardware
> > to account for the "always" simulators.
> 
> the way this code is written, the lack of indentation just gets in the way.
> also doing all this processing in the 3rd arg to AC_ARG_ENABLE() is largely
> pointless.
> 
> this should do it i think

i've committed this patch now.  the regen stats looked the same as Joel's.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Recent simulator patches broke many sims

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 2890 bytes --]

On Tuesday 26 March 2013 13:12:38 Hans-Peter Nilsson wrote:
> From: Mike Frysinger <vapier@gentoo.org>
> On Sunday 24 March 2013 19:23:28 Hans-Peter Nilsson wrote:
> > You need a board (make check RUNTESTFLAGS=--target_board=$board
> > with e.g. board=cris-sim).  All boards are in "recent"
> > dejagnu-1.5 IIRC and most in ancient dejagnu-1.4.4.  You need
> > installed binutils (e.g. in some temp location added to PATH for
> > the duration of the test-run) for each sim configuration as
> > mentioned.  I don't run with target gcc; not needed for the
> > level of smoke test I'm after and I guess not for this change
> > either.
> > 
> > that's not entirely true.  many (all but cris?)
> 
> I don't think it's different but I don't plan to test without...
> 
> > sims run &
> > pass just fine without needing to explicitly pass magic flags.
> 
> It is entirely true that when a board is specified, all work.
> 
> Now that you mention it, someone *did* do some changes to allow
> simulator tests to run without specifying a board - IIRC in some
> situations, assuming no special linker flags or such needed and
> no compiler toolchain (or no flags or libraries using simulator
> hooks).  Reading ChangeLogs it seems it was you, on 2010-04-26.

yes, that was the commit date, but i'd been using it longer than that :)

> > i know the Blackfin and frv sims can build & run pretty much
> > all their tests w/out requiring board flags.
> > 
> > imo, requiring manual board selection like this is archaic for
> > no good reason.
> 
> One good reason IMO is that when specifying a board, all
> toolchain parts test alike, rather than sim (after 2010-04-26)
> being a special case (and binutils, mostly for not needing to
> run things to avoid FAILs or hanging tests).

i see it the other way.  doing `make check` for all these packages work w/out 
the user having to dig into esoteric tools (that often times lack 
documentation, or any real semblance of an entry point).

for binutils/gcc/etc..., there are plenty of compile/link/etc... tests that 
can be done without needing to know about a board.  the sim is special in that 
testing it requires running code, so it's entirely reasonable for the default 
`make check` to setup a state where the tests actually work.

if the default `make check` for cris doesn't, then that should be fixed to 
provide a reasonable default.  if you're telling everyone "in order to test 
the cris sim, you have to use RUNTESTFLAGS=--target_board=cris-sim", then make 
that the default board already.  there's absolutely no reason to force this 
upon people who are trying to hack on the core sim and/or other sims, and want 
to verify they didn't break other sims.

for many sims, it's hard enough as it is just to try and guess the magic tuple 
that'll pass all the deprecated/enable checks.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Recent simulator patches broke many sims

[Hans-Peter Nilsson]

> From: Mike Frysinger <vapier@gentoo.org>
> Date: Tue, 26 Mar 2013 19:15:17 +0100

> On Tuesday 26 March 2013 13:12:38 Hans-Peter Nilsson wrote:
> i see it the other way.  doing `make check` for all these
> packages work w/out the user having to dig into esoteric tools
> (that often times lack documentation, or any real semblance of
> an entry point).
> 
> for binutils/gcc/etc..., there are plenty of
> compile/link/etc... tests that can be done without needing to
> know about a board.  the sim is special in that testing it
> requires running code,

Thinking you're good without running any runnnable tests?
I guess we have to agree to disagree here.

> so it's entirely reasonable for the
> default `make check` to setup a state where the tests actually
> work.

You know, if someone went to do the work to provide a default
(overridable) target-board for all cross *-elf et al targets at
the toplevel, I wouldn't mind.

I'll just add that you're wrong if you think gcc testing without
*running* the runnable tests is to be taken seriously (with very
few exceptions).  I haven't ran gdb tests recently enough to
remember it, but...

brgds, H-P

Re: Recent simulator patches broke many sims

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1609 bytes --]

On Tuesday 26 March 2013 15:35:24 Hans-Peter Nilsson wrote:
> > From: Mike Frysinger <vapier@gentoo.org>
> > Date: Tue, 26 Mar 2013 19:15:17 +0100
> > 
> > On Tuesday 26 March 2013 13:12:38 Hans-Peter Nilsson wrote:
> > i see it the other way.  doing `make check` for all these
> > packages work w/out the user having to dig into esoteric tools
> > (that often times lack documentation, or any real semblance of
> > an entry point).
> > 
> > for binutils/gcc/etc..., there are plenty of
> > compile/link/etc... tests that can be done without needing to
> > know about a board.  the sim is special in that testing it
> > requires running code,
> 
> Thinking you're good without running any runnnable tests?
> I guess we have to agree to disagree here.

i didn't say that.  i did say that quite a significant chunk of functionality 
can be exercised w/out executing code.  requiring people have to a full stack 
setup to do even basic testing is wrong.  no one writes 100% of their changes, 
then compiles it, then runs it.  people are a lot more iterative and having 
graduated level of testing enables that workflow.

> > so it's entirely reasonable for the
> > default `make check` to setup a state where the tests actually
> > work.
> 
> You know, if someone went to do the work to provide a default
> (overridable) target-board for all cross *-elf et al targets at
> the toplevel, I wouldn't mind.

cris is the only target that i see today that is failing to work with sane 
defaults "out of the box".  i don't see a global init being necessary (or even 
useful).
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Recent simulator patches broke many sims

[Hans-Peter Nilsson]

> From: Mike Frysinger <vapier@gentoo.org>
> Date: Tue, 26 Mar 2013 20:53:22 +0100

> > You know, if someone went to do the work to provide a default
> > (overridable) target-board for all cross *-elf et al targets at
> > the toplevel, I wouldn't mind.
> 
> cris is the only target that i see today that is failing to work with sane 
> defaults "out of the box".  i don't see a global init being
> necessary (or even useful).

It fails, how?  That's the first thing I've heard about it.

I see it works for my autotester with the recent commit, using
the same documented way of testing I've done for years.

brgds, H-P

Re: Recent simulator patches broke many sims

[Joel Brobecker]

> i've committed this patch now.  the regen stats looked the same as Joel's.

Can everyone confirm that we can take the sim issues out of the TODO
list for the 7.6 release?

Thank you!
-- 
Joel

Re: Recent simulator patches broke many sims

[Hans-Peter Nilsson]

> From: Joel Brobecker <brobecker@adacore.com>
> Date: Wed, 27 Mar 2013 00:44:58 +0100

> Can everyone confirm that we can take the sim issues out of the TODO
> list for the 7.6 release?

FWIW, a "yes" from me: autotester results are fine here, thanks.

brgds, H-P

Re: Recent simulator patches broke many sims

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 825 bytes --]

On Tuesday 26 March 2013 16:50:21 Hans-Peter Nilsson wrote:
> > From: Mike Frysinger <vapier@gentoo.org>
> > > You know, if someone went to do the work to provide a default
> > > (overridable) target-board for all cross *-elf et al targets at
> > > the toplevel, I wouldn't mind.
> > 
> > cris is the only target that i see today that is failing to work with
> > sane defaults "out of the box".  i don't see a global init being
> > necessary (or even useful).
> 
> It fails, how?  That's the first thing I've heard about it.

i meant "if `make check-sim` for a cris-elf target requires RUNTESTFLAGS=--
target_board=cris-sim to be specified in order to pass tests"

if people can simply do:
	./configure --target=cris-elf
	make all-sim
	make check-sim
and it works, then i don't have any complaints
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Recent simulator patches broke many sims

[Joel Sherrill]

On 3/26/2013 8:38 PM, Hans-Peter Nilsson wrote:
>> From: Joel Brobecker <brobecker@adacore.com>
>> Date: Wed, 27 Mar 2013 00:44:58 +0100
>> Can everyone confirm that we can take the sim issues out of the TODO
>> list for the 7.6 release?
> FWIW, a "yes" from me: autotester results are fine here, thanks.
If H-P and Mike are happy, I am happy.
> brgds, H-P


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Recent simulator patches broke many sims

[Joel Brobecker]

> >>Can everyone confirm that we can take the sim issues out of the TODO
> >>list for the 7.6 release?
> If H-P and Mike are happy, I am happy.

Thanks! I just assumed Mike is happy, and updated the release wiki page
accordingly.

-- 
Joel

Re: Recent simulator patches broke many sims

[Joel Brobecker]

BTW: A big thank you to everyone involved for working together towards
     resolving this issue so quickly.

-- 
Joel