* Re: Recent simulator patches broke many sims
2013-03-24 0:22 Recent simulator patches broke many sims Hans-Peter Nilsson
@ 2013-03-24 0:38 ` Joel Sherrill
2013-03-24 5:39 ` Hans-Peter Nilsson
2013-03-24 2:12 ` Joel Sherrill
2013-03-24 2:35 ` Joel Sherrill
2 siblings, 1 reply; 29+ messages in thread
From: Joel Sherrill @ 2013-03-24 0:38 UTC (permalink / raw)
To: Hans-Peter Nilsson; +Cc: gdb-patches
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-24 0:38 ` Joel Sherrill
@ 2013-03-24 5:39 ` Hans-Peter Nilsson
2013-03-24 5:39 ` Joel Sherrill
0 siblings, 1 reply; 29+ messages in thread
From: Hans-Peter Nilsson @ 2013-03-24 5:39 UTC (permalink / raw)
To: joel.sherrill; +Cc: gdb-patches
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-24 5:39 ` Hans-Peter Nilsson
@ 2013-03-24 5:39 ` Joel Sherrill
2013-03-24 11:04 ` Hans-Peter Nilsson
0 siblings, 1 reply; 29+ messages in thread
From: Joel Sherrill @ 2013-03-24 5:39 UTC (permalink / raw)
To: Hans-Peter Nilsson; +Cc: gdb-patches
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-24 5:39 ` Joel Sherrill
@ 2013-03-24 11:04 ` Hans-Peter Nilsson
0 siblings, 0 replies; 29+ messages in thread
From: Hans-Peter Nilsson @ 2013-03-24 11:04 UTC (permalink / raw)
To: joel.sherrill; +Cc: gdb-patches
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-24 0:22 Recent simulator patches broke many sims Hans-Peter Nilsson
2013-03-24 0:38 ` Joel Sherrill
@ 2013-03-24 2:12 ` Joel Sherrill
2013-03-24 2:35 ` Joel Sherrill
2 siblings, 0 replies; 29+ messages in thread
From: Joel Sherrill @ 2013-03-24 2:12 UTC (permalink / raw)
To: Hans-Peter Nilsson; +Cc: gdb-patches, Mike Frysinger
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-24 0:22 Recent simulator patches broke many sims Hans-Peter Nilsson
2013-03-24 0:38 ` Joel Sherrill
2013-03-24 2:12 ` Joel Sherrill
@ 2013-03-24 2:35 ` Joel Sherrill
2013-03-24 2:53 ` Hans-Peter Nilsson
` (2 more replies)
2 siblings, 3 replies; 29+ messages in thread
From: Joel Sherrill @ 2013-03-24 2:35 UTC (permalink / raw)
To: Hans-Peter Nilsson; +Cc: gdb-patches
[-- 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"
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: Recent simulator patches broke many sims
2013-03-24 2:35 ` Joel Sherrill
@ 2013-03-24 2:53 ` Hans-Peter Nilsson
2013-03-24 5:22 ` Hans-Peter Nilsson
2013-03-24 5:36 ` Hans-Peter Nilsson
2013-03-24 4:51 ` Hans-Peter Nilsson
2013-03-24 11:33 ` Mike Frysinger
2 siblings, 2 replies; 29+ messages in thread
From: Hans-Peter Nilsson @ 2013-03-24 2:53 UTC (permalink / raw)
To: joel.sherrill; +Cc: gdb-patches
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-24 2:53 ` Hans-Peter Nilsson
@ 2013-03-24 5:22 ` Hans-Peter Nilsson
2013-03-24 5:36 ` Hans-Peter Nilsson
1 sibling, 0 replies; 29+ messages in thread
From: Hans-Peter Nilsson @ 2013-03-24 5:22 UTC (permalink / raw)
To: joel.sherrill, gdb-patches
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-24 2:53 ` Hans-Peter Nilsson
2013-03-24 5:22 ` Hans-Peter Nilsson
@ 2013-03-24 5:36 ` Hans-Peter Nilsson
1 sibling, 0 replies; 29+ messages in thread
From: Hans-Peter Nilsson @ 2013-03-24 5:36 UTC (permalink / raw)
To: joel.sherrill; +Cc: gdb-patches
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-24 2:35 ` Joel Sherrill
2013-03-24 2:53 ` Hans-Peter Nilsson
@ 2013-03-24 4:51 ` Hans-Peter Nilsson
2013-03-24 11:33 ` Mike Frysinger
2 siblings, 0 replies; 29+ messages in thread
From: Hans-Peter Nilsson @ 2013-03-24 4:51 UTC (permalink / raw)
To: joel.sherrill; +Cc: gdb-patches
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-24 2:35 ` Joel Sherrill
2013-03-24 2:53 ` Hans-Peter Nilsson
2013-03-24 4:51 ` Hans-Peter Nilsson
@ 2013-03-24 11:33 ` Mike Frysinger
2013-03-25 3:30 ` Joel Sherrill
2013-03-26 18:56 ` Mike Frysinger
2 siblings, 2 replies; 29+ messages in thread
From: Mike Frysinger @ 2013-03-24 11:33 UTC (permalink / raw)
To: gdb-patches; +Cc: Joel Sherrill, Hans-Peter Nilsson
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: Recent simulator patches broke many sims
2013-03-24 11:33 ` Mike Frysinger
@ 2013-03-25 3:30 ` Joel Sherrill
2013-03-25 3:50 ` Hans-Peter Nilsson
2013-03-26 18:56 ` Mike Frysinger
1 sibling, 1 reply; 29+ messages in thread
From: Joel Sherrill @ 2013-03-25 3:30 UTC (permalink / raw)
To: Mike Frysinger; +Cc: gdb-patches, Hans-Peter Nilsson
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
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: Recent simulator patches broke many sims
2013-03-25 3:30 ` Joel Sherrill
@ 2013-03-25 3:50 ` Hans-Peter Nilsson
2013-03-25 7:39 ` Joel Sherrill
2013-03-26 17:49 ` Mike Frysinger
0 siblings, 2 replies; 29+ messages in thread
From: Hans-Peter Nilsson @ 2013-03-25 3:50 UTC (permalink / raw)
To: joel.sherrill; +Cc: vapier, gdb-patches
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-25 3:50 ` Hans-Peter Nilsson
@ 2013-03-25 7:39 ` Joel Sherrill
2013-03-26 17:49 ` Mike Frysinger
1 sibling, 0 replies; 29+ messages in thread
From: Joel Sherrill @ 2013-03-25 7:39 UTC (permalink / raw)
To: Hans-Peter Nilsson; +Cc: vapier, gdb-patches
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-25 3:50 ` Hans-Peter Nilsson
2013-03-25 7:39 ` Joel Sherrill
@ 2013-03-26 17:49 ` Mike Frysinger
2013-03-26 18:41 ` Hans-Peter Nilsson
1 sibling, 1 reply; 29+ messages in thread
From: Mike Frysinger @ 2013-03-26 17:49 UTC (permalink / raw)
To: Hans-Peter Nilsson; +Cc: joel.sherrill, gdb-patches
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-26 17:49 ` Mike Frysinger
@ 2013-03-26 18:41 ` Hans-Peter Nilsson
2013-03-26 18:43 ` Joel Sherrill
2013-03-26 19:49 ` Mike Frysinger
0 siblings, 2 replies; 29+ messages in thread
From: Hans-Peter Nilsson @ 2013-03-26 18:41 UTC (permalink / raw)
To: vapier; +Cc: joel.sherrill, gdb-patches
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-26 18:41 ` Hans-Peter Nilsson
@ 2013-03-26 18:43 ` Joel Sherrill
2013-03-26 19:49 ` Mike Frysinger
1 sibling, 0 replies; 29+ messages in thread
From: Joel Sherrill @ 2013-03-26 18:43 UTC (permalink / raw)
To: Hans-Peter Nilsson; +Cc: vapier, gdb-patches
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-26 18:41 ` Hans-Peter Nilsson
2013-03-26 18:43 ` Joel Sherrill
@ 2013-03-26 19:49 ` Mike Frysinger
2013-03-26 20:50 ` Hans-Peter Nilsson
1 sibling, 1 reply; 29+ messages in thread
From: Mike Frysinger @ 2013-03-26 19:49 UTC (permalink / raw)
To: Hans-Peter Nilsson; +Cc: joel.sherrill, gdb-patches
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-26 19:49 ` Mike Frysinger
@ 2013-03-26 20:50 ` Hans-Peter Nilsson
2013-03-26 21:24 ` Mike Frysinger
0 siblings, 1 reply; 29+ messages in thread
From: Hans-Peter Nilsson @ 2013-03-26 20:50 UTC (permalink / raw)
To: vapier; +Cc: joel.sherrill, gdb-patches
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-26 20:50 ` Hans-Peter Nilsson
@ 2013-03-26 21:24 ` Mike Frysinger
2013-03-27 1:39 ` Hans-Peter Nilsson
0 siblings, 1 reply; 29+ messages in thread
From: Mike Frysinger @ 2013-03-26 21:24 UTC (permalink / raw)
To: Hans-Peter Nilsson; +Cc: joel.sherrill, gdb-patches
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-26 21:24 ` Mike Frysinger
@ 2013-03-27 1:39 ` Hans-Peter Nilsson
2013-03-27 9:13 ` Mike Frysinger
0 siblings, 1 reply; 29+ messages in thread
From: Hans-Peter Nilsson @ 2013-03-27 1:39 UTC (permalink / raw)
To: vapier; +Cc: joel.sherrill, gdb-patches
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-24 11:33 ` Mike Frysinger
2013-03-25 3:30 ` Joel Sherrill
@ 2013-03-26 18:56 ` Mike Frysinger
2013-03-27 8:47 ` Joel Brobecker
1 sibling, 1 reply; 29+ messages in thread
From: Mike Frysinger @ 2013-03-26 18:56 UTC (permalink / raw)
To: gdb-patches; +Cc: Joel Sherrill, Hans-Peter Nilsson
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-26 18:56 ` Mike Frysinger
@ 2013-03-27 8:47 ` Joel Brobecker
2013-03-27 8:50 ` Hans-Peter Nilsson
0 siblings, 1 reply; 29+ messages in thread
From: Joel Brobecker @ 2013-03-27 8:47 UTC (permalink / raw)
To: Mike Frysinger; +Cc: gdb-patches, Joel Sherrill, Hans-Peter Nilsson
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-27 8:47 ` Joel Brobecker
@ 2013-03-27 8:50 ` Hans-Peter Nilsson
2013-03-27 18:38 ` Joel Sherrill
0 siblings, 1 reply; 29+ messages in thread
From: Hans-Peter Nilsson @ 2013-03-27 8:50 UTC (permalink / raw)
To: brobecker; +Cc: vapier, gdb-patches, joel.sherrill
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Recent simulator patches broke many sims
2013-03-27 8:50 ` Hans-Peter Nilsson
@ 2013-03-27 18:38 ` Joel Sherrill
2013-03-27 19:01 ` Joel Brobecker
2013-03-27 19:43 ` Joel Brobecker
0 siblings, 2 replies; 29+ messages in thread
From: Joel Sherrill @ 2013-03-27 18:38 UTC (permalink / raw)
To: Hans-Peter Nilsson; +Cc: brobecker, vapier, gdb-patches
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
^ permalink raw reply [flat|nested] 29+ messages in thread