[OpenRISC] or1ksim simulator check fails

[Peter Breuer]

Greetings

I've compiled or1ksim from github (using the -or1k-master zip
file download as source and typing "./configure; make; .."), but certain
checks fail in "make check".

The simulator binary says:
OpenRISC 1000 Architectural Simulator, version 2012-04-27

I reckon the simulator compile found the gnu toolchain in
/opt/or1k-toolchain [is it even needed?]. The config.log says it was
run with "./configure" and further down it has

Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --enable-objc-gc
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu

I compiled the gnu toolchain using the instructions at

https://github.com/juliusbaxter/mor1kx-dev-env/wiki/OpenRISC-tool-chain-installat
ion-guide

but it seems to me those are aimed at the mor1kx architectures. The
toolchain configure line was:

../or1k-src/configure --target=or1k-elf --prefix=/opt/or1k-toolchain
--enable-shared --disable-itcl --disable-tk --disable-tcl
--disable-winsup --disable-libgui --disable-rda --disable-sid
--enable-sim --

and further down in config.log:

Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --enable-objc-gc
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu


Here are the or1ksim tests:

=== libsim Summary ===

# of expected passes 252
# of unexpected failures 9
# of unresolved testcases 1
Test Run By ptb on Tue Oct 21 19:04:44 2014
Native configuration is i686-pc-linux-gnu


=== or1ksim Summary ===

# of expected passes 3654
# of unexpected failures 8
# of unresolved testcases 2

I would like to know if those failures are expected for the current
code, or if it's me getting something wrong. I need a stable base to
start doing some work!

Now the or1ksim README says

Or1ksim can be tested with "make check", but this requires the GNU
tool chain to be installed (using the same target specification)

OK .. but what IS the target specification? Nobody has unbundled the
jargon "target specification" for me in this readme :-(. And which
toolchain is really meant? The standard one for me and my pc, or the
cross-compile stuff for or1k-elf?

How do I find out what it is for or1ksim and how do I find out what it
is for the toolchain I just compiled, and how do I change it if it needs
changing?

[is the target supposed to be the or1ksim architecture itself? Or the
architecture that or1ksim simulates (which is?)? What are these called?
Or is the "target" supposed to be my own native achitecture
i686-pc-linux-gnu, or one of its aliases?]

What is messed up here? The docs or my compile?


Peter Breuer

[Julius Baxter]

Post by Peter Breuer
Greetings
I've compiled or1ksim from github (using the -or1k-master zip
file download as source and typing "./configure; make; .."), but certain
checks fail in "make check".
OpenRISC 1000 Architectural Simulator, version 2012-04-27
I reckon the simulator compile found the gnu toolchain in
/opt/or1k-toolchain [is it even needed?]. The config.log says it was
run with "./configure" and further down it has
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --enable-objc-gc
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
I compiled the gnu toolchain using the instructions at
https://github.com/juliusbaxter/mor1kx-dev-env/wiki/OpenRISC-tool-chain-installat
ion-guide
but it seems to me those are aimed at the mor1kx architectures. The
../or1k-src/configure --target=or1k-elf --prefix=/opt/or1k-toolchain
--enable-shared --disable-itcl --disable-tk --disable-tcl
--disable-winsup --disable-libgui --disable-rda --disable-sid
--enable-sim --
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --enable-objc-gc
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
=== libsim Summary ===
# of expected passes 252
# of unexpected failures 9
# of unresolved testcases 1
Test Run By ptb on Tue Oct 21 19:04:44 2014
Native configuration is i686-pc-linux-gnu
=== or1ksim Summary ===
# of expected passes 3654
# of unexpected failures 8
# of unresolved testcases 2
I would like to know if those failures are expected for the current
code, or if it's me getting something wrong. I need a stable base to
start doing some work!
Now the or1ksim README says
Or1ksim can be tested with "make check", but this requires the GNU
tool chain to be installed (using the same target specification)
OK .. but what IS the target specification? Nobody has unbundled the
jargon "target specification" for me in this readme :-(. And which
toolchain is really meant? The standard one for me and my pc, or the
cross-compile stuff for or1k-elf?

Hi,

The "tool chain" referred to here is the cross compiler, that's ambiguous I
know, so fair enough for asking.

Not exactly sure what "target specification" means, but I will guess that's
a hangover from when or1ksim could target different architectures (I
believe it supported DLX at some point, and various developmental versions
of the OpenRISC architecture back in the early days). These days or1k-elf
is the correct target.

As for the test failures, I'd be interested to see what they are. I'd be
inclined to ignore them (or maybe at least have a quick peek at the test
failure log and see if it's anything major, but considering the vast
majority of the tests are passing, it's probably in good health). Any
chance you could pastebin the test failures?

Post by Peter Breuer
How do I find out what it is for or1ksim and how do I find out what it
is for the toolchain I just compiled, and how do I change it if it needs
changing?
[is the target supposed to be the or1ksim architecture itself? Or the
architecture that or1ksim simulates (which is?)? What are these called?
Or is the "target" supposed to be my own native achitecture
i686-pc-linux-gnu, or one of its aliases?]
What is messed up here? The docs or my compile?

Docs maybe a bit unclear. Compile is probably fine.

Cheers

Julius

[Peter Breuer]

[apologies, I think I didn't reply from the right address, so this
wouldn't have got on the lists first time; plus I forgot to append
the complete log - which I'll do to Julius privately to avoid
spamming the list]

"Also sprach Julius Baxter:"

Post by Julius Baxter
majority of the tests are passing, it's probably in good health). Any
chance you could pastebin the test failures?

=== libsim tests ===

Schedule of variations:
unix

Running target unix
Using ./config/unix.exp as board description file for target.
Running ./libsim.tests/int-edge.exp ...
FAIL: int-edge simple 1: hit EOF seeking match line 2
FAIL: int-edge simple 2: hit EOF seeking match line 2
FAIL: int-edge duplicated 1: hit EOF seeking match line 2
FAIL: int-edge duplicated 2: hit EOF seeking match line 2
FAIL: int-edge all upcall: hit EOF seeking match line 2
Running ./libsim.tests/int-level.exp ...
FAIL: int-level simple 1: hit EOF seeking match line 2
FAIL: int-level simple 2: hit EOF seeking match line 2
Running ./libsim.tests/jtag-basic.exp ...
Running ./libsim.tests/jtag-go-command-read.exp ...
Running ./libsim.tests/jtag-go-command-write.exp ...
Running ./libsim.tests/jtag-read-command.exp ...
Running ./libsim.tests/jtag-read-control.exp ...
Running ./libsim.tests/jtag-select-module.exp ...
Running ./libsim.tests/jtag-write-command.exp ...
Running ./libsim.tests/jtag-write-control.exp ...
Running ./libsim.tests/lib-iftest.exp ...
Running ./libsim.tests/upcalls.exp ...
FAIL: upcalls - basic: hit EOF seeking match line 2
FAIL: upcalls - misaligned: hit EOF seeking match line 2

=== libsim Summary ===

# of expected passes 253
# of unexpected failures 9
Test Run By ptb on Fri Oct 24 16:28:29 2014
Native configuration is i686-pc-linux-gnu

=== or1ksim tests ===

Schedule of variations:
unix

Running target unix
Using ./config/unix.exp as board description file for target.
Running ./or1ksim.tests/atomic.exp ...
Running ./or1ksim.tests/basic.exp ...
Running ./or1ksim.tests/cache.exp ...
Running ./or1ksim.tests/cbasic.exp ...
Running ./or1ksim.tests/cfg.exp ...
FAIL: cfg: hit EOF seeking match line 5
Running ./or1ksim.tests/dhry.exp ...
Running ./or1ksim.tests/dmatest.exp ...
FAIL: dmatest: hit EOF seeking match line 1
Running ./or1ksim.tests/eth.exp ...
FAIL: eth: hit EOF seeking match line 1
Running ./or1ksim.tests/except-test.exp ...
FAIL: except-test: hit EOF seeking match line 1
Running ./or1ksim.tests/exit.exp ...
Running ./or1ksim.tests/ext.exp ...
Running ./or1ksim.tests/fbtest.exp ...
Running ./or1ksim.tests/flag.exp ...
Running ./or1ksim.tests/fp.exp ...
Running ./or1ksim.tests/functest.exp ...
Running ./or1ksim.tests/inst-set-test.exp ...
Running ./or1ksim.tests/int-test.exp ...
FAIL: int-test: hit EOF seeking match line 1
Running ./or1ksim.tests/kbdtest.exp ...
FAIL: kbdtest: hit EOF seeking match line 1
Running ./or1ksim.tests/local-global.exp ...
Running ./or1ksim.tests/mem-test.exp ...
Running ./or1ksim.tests/mmu.exp ...
ERROR: Timeout
Running ./or1ksim.tests/mul.exp ...
FAIL: mul: hit EOF seeking match line 7
Running ./or1ksim.tests/mycompress.exp ...
FAIL: mycompress: hit EOF seeking match line 1005
Running ./or1ksim.tests/pcu.exp ...
Running ./or1ksim.tests/testfloat.exp ...
FAIL: testfloat: hit EOF seeking match line 1
Running ./or1ksim.tests/tick.exp ...

=== or1ksim Summary ===

# of expected passes 3654
# of unexpected failures 9
# of unresolved testcases 1

Post by Julius Baxter
Not exactly sure what "target specification" means, but I will guess
that's a hangover from when or1ksim could target different
architectures (I believe it supported DLX at some point, and various
developmental versions

OK. No problem, then, except that --target seems to be used several
different ways in the configure scripts/docs: both for the native
architecture (my PC) that is the target of build, and the simulated
architecture (or1k-elf ?). That may be the start of a bug.

At any rate, a partial listing in that paragraph of what the values
might be would be a great help to understanding and clarity (you know,
"an example"!)... as would showing how to find them out and set them if
need be.

Post by Julius Baxter

Post by Peter Breuer
What is messed up here? The docs or my compile?

Docs maybe a bit unclear. Compile is probably fine.

OK - that is a bit of a miracle, since I was guessing as to WHY I was
doing what I was doing.

I'm not at all sure how the or1ksim compile found the crosscompile
toolchain, or how I would have told it to if I hadn't had the
executables dir at the front of my PATH with exactly the binary names it
was looking for (or1k-elf-gcc, etc). That was about my 6th compile of
the toolchain.

Making the rationale clear in the docs would have helped, I think, as
well as future-proofing it.

I'm also compiling or1ksim-0.3,4,5. 0.3 didn't come near to compiling
(I forget why, but I'll do it again if somebody wants me to). 0.4
compiled but make check wouldn't run for reasons that again I can go and
look up. I am currently forcing my way slowly through the check
inserting an ="ranlib" in some Makefiles that lack it, and/or doing the
compile by hand and guesswork where it breaks. The makefiles also
thought my gcc has -mhard-div and -mhard-mul, and it doesn't. But they
also thought my gcc needed to be substituted by "compile" and weird
stuff brought in via config.h, apparently because the -Werror in the
configure script CCFLAGS causes gcc 4.7.2 to barf on some of the
compile tests (extra unused variables now are errors).

I did try remaking the makefiles with automake 1.14 (they were made with
1.11) but there are messes with INCLUDES being replaced by AM_CPPFLAGS
or some such. By the time I fought that through (anyone want source
files with correct relative paths in the references headers), the
simulator compiled, but the make check wouldn't run for much the same
reasosn as before, so I gave that up. The configure there does not seem
to have found the cross-compile toolchain binaries, but it does need
them.

Thanks for the input!

Peter

[Stefan Kristiansson]

Post by Peter Breuer
I've compiled or1ksim from github (using the -or1k-master zip
file download as source and typing "./configure; make; .."), but certain
checks fail in "make check".

[...]

Post by Peter Breuer
I compiled the gnu toolchain using the instructions at
https://github.com/juliusbaxter/mor1kx-dev-env/wiki/OpenRISC-tool-chain-installat
ion-guide

These are the instructions we usually point people that want to build
the or1k-elf toolchain:
http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Newlib_toolchain_.28or1k-elf.29
but the ones you followed is pretty much identical, so you're most
probably fine in that regard.

Post by Peter Breuer
=== libsim Summary ===
# of expected passes 252
# of unexpected failures 9
# of unresolved testcases 1
Test Run By ptb on Tue Oct 21 19:04:44 2014
Native configuration is i686-pc-linux-gnu
=== or1ksim Summary ===
# of expected passes 3654
# of unexpected failures 8
# of unresolved testcases 2
I would like to know if those failures are expected for the current
code, or if it's me getting something wrong. I need a stable base to
start doing some work!

This made me recall having similar issues a while back, and searching
around some old IRC I found this:
http://juliusbaxter.net/openrisc-irc/%23openrisc.2014-05-05.log.html#t05:20
(I'm stekern in that conversion).
The conclusion from that was that you currently have to build or1ksim
with --disable-shared.
I also recall Peter Gavin (pgavin) trying to get it to automatically
pick that up, but can't remember if he ran into some problems with
that or was the end result was.
(Yes, it should anyways be documented somewhere that it's currently
necessary to use that flag as a workaround).

Post by Peter Breuer
Now the or1ksim README says
Or1ksim can be tested with "make check", but this requires the GNU
tool chain to be installed (using the same target specification)
OK .. but what IS the target specification? Nobody has unbundled the
jargon "target specification" for me in this readme :-(. And which
toolchain is really meant? The standard one for me and my pc, or the
cross-compile stuff for or1k-elf?
How do I find out what it is for or1ksim and how do I find out what it
is for the toolchain I just compiled, and how do I change it if it needs
changing?

I think 'target' here is used by the same logic 'target' is used for
the toolchain.
I.e. in your case or1k-elf (as opposed to for instance or1k-linux-*).
I don't think or1ksim makes any assumptions about the path where it is
installed, but rather use the first that is found in your PATH.
Jeremy is probably most familiar with this aspect of or1ksim, so I
added him on CC in hope that he can shed some more light on this
question.

Stefan

[Peter Gavin]

On Fri, Oct 24, 2014 at 4:13 PM, Stefan Kristiansson <

Post by Stefan Kristiansson
This made me recall having similar issues a while back, and searching
http://juliusbaxter.net/openrisc-irc/%23openrisc.2014-05-05.log.html#t05:20
(I'm stekern in that conversion).
The conclusion from that was that you currently have to build or1ksim
with --disable-shared.
I also recall Peter Gavin (pgavin) trying to get it to automatically
pick that up, but can't remember if he ran into some problems with
that or was the end result was.

I think the end result was just to use --disable-shared. This prevents
libsim from being built as a .so but unless I'm mistaken, the only other
program that uses it is GDB so it's probably not a huge problem.

FWIW those testsuite errors are exactly the ones I have if on my machine if
I don't use --disable-shared. With --disable-shared, everything passes.
I'm still not 100% sure what's causing the bug, to be honest. I haven't
looked at it in a few months, but IIRC the failing tests don't use
or1k-elf-sim, they use their own native binary to execute the test code.

-Pete

[Peter Breuer]

On Fri, 24 Oct 2014 16:40:35 -0400

Post by Peter Gavin
I think the end result was just to use --disable-shared. This

Thanks all, I'll try that.

I assume it would become default if "enable_shared=no" is put somewhere
up top in the configure.ac file. The generated configure file checks
if it is set, and honours whatever it is set to.

Peter Breuer

[Peter Breuer]

On Fri, 24 Oct 2014 16:40:35 -0400

Post by Peter Gavin
I think the end result was just to use --disable-shared. This

(--disable-shared could probably be made default via putting
"enable_shared=no" high in the configure.ac file - that's tested and used
if set)

It fixes the libsim fails but leaves 2 sim fails.

=== libsim Summary ===

# of expected passes 262

=== or1ksim Summary ===

# of expected passes 3743
# of unexpected failures 2

The sim fails are

...
Running ./or1ksim.tests/cfg.exp ...
FAIL: cfg: hit EOF seeking match line 5
...
Running ./or1ksim.tests/int-test.exp ...
FAIL: int-test: hit EOF seeking match line 1
...


The log file doesn't seem to say more:

...
report(0x00000000);
report(0xf0acfad0);
report(0xdeaddead);
exit(0)
@reset : cycles 0, insn #0
@exit : cycles 112, insn #57
diff : cycles 112, insn #57
PASS: cfg: report(0x12000001);
PASS: cfg: report(0x0000041f);
PASS: cfg: report(0x00000000);
PASS: cfg: report(0x00000005);
FAIL: cfg: hit EOF seeking match line 5
testcase ./or1ksim.tests/cfg.exp completed in 0 seconds

...
report(0x00000038);
report(0xdeaddead);
exit(0)
@reset : cycles 0, insn #0
@exit : cycles 6610, insn #2827
diff : cycles 6610, insn #2827
FAIL: int-test: hit EOF seeking match line 1
testcase ./or1ksim.tests/int-test.exp completed in 0 seconds

Peter

[Peter Gavin]

Hm... I wonder if that's happening because you're compiling for 32-bits.
Is there a way you can try it out on 64-bits to see if that's causing the
test to fail? No need to recompile the whole toolchain if you're doing
this on a 64-bit host, recompiling or1ksim should be enough.

One other thing, I haven't updated my copy of the toolchain in a bit, and
it doesn't include Stefan's atomic instruction patches. I'll have to
recompile it if I'm going to test that properly (my gas version won't
assemble the atomic instructions). Could you perhaps try backing that
patch out of or1ksim to see if that has any effect? You'd basically just
need to do git checkout fdd700a in the or1ksim tree, then recompile it.

-Pete

Post by Peter Breuer
On Fri, 24 Oct 2014 16:40:35 -0400

Post by Peter Gavin
I think the end result was just to use --disable-shared. This

(--disable-shared could probably be made default via putting
"enable_shared=no" high in the configure.ac file - that's tested and used
if set)
It fixes the libsim fails but leaves 2 sim fails.
=== libsim Summary ===
# of expected passes 262
=== or1ksim Summary ===
# of expected passes 3743
# of unexpected failures 2
The sim fails are
...
Running ./or1ksim.tests/cfg.exp ...
FAIL: cfg: hit EOF seeking match line 5
...
Running ./or1ksim.tests/int-test.exp ...
FAIL: int-test: hit EOF seeking match line 1
...
...
report(0x00000000);
report(0xf0acfad0);
report(0xdeaddead);
exit(0)
@reset : cycles 0, insn #0
@exit : cycles 112, insn #57
diff : cycles 112, insn #57
PASS: cfg: report(0x12000001);
PASS: cfg: report(0x0000041f);
PASS: cfg: report(0x00000000);
PASS: cfg: report(0x00000005);
FAIL: cfg: hit EOF seeking match line 5
testcase ./or1ksim.tests/cfg.exp completed in 0 seconds
...
report(0x00000038);
report(0xdeaddead);
exit(0)
@reset : cycles 0, insn #0
@exit : cycles 6610, insn #2827
diff : cycles 6610, insn #2827
FAIL: int-test: hit EOF seeking match line 1
testcase ./or1ksim.tests/int-test.exp completed in 0 seconds
Peter
_______________________________________________
OpenRISC mailing list
http://lists.openrisc.net/listinfo/openrisc

[Peter Breuer]

On Fri, 24 Oct 2014 17:44:09 -0400

Post by Peter Gavin
Hm... I wonder if that's happening because you're compiling for
32-bits. Is there a way you can try it out on 64-bits to see if
that's causing the test to fail? No need to recompile the whole
toolchain if you're doing this on a 64-bit host, recompiling or1ksim
should be enough.

I can try that (AMD machine ...).

Post by Peter Gavin
One other thing, I haven't updated my copy of the toolchain in a bit,
and it doesn't include Stefan's atomic instruction patches. I'll
have to recompile it if I'm going to test that properly (my gas
version won't assemble the atomic instructions). Could you perhaps
try backing that patch out of or1ksim to see if that has any effect?
You'd basically just need to do git checkout fdd700a in the or1ksim
tree, then recompile it.

Also possible. I'll let you know ... no, no difference, but I'm not a
git user and it appeared to me that that git command did nothing
much [but it does, it's just quiet .. see lower down this post]

% git checkout fdd700a
M doc/or1ksim.info
M doc/version.texi
HEAD is now at fdd700a... fix l.div with dividend 0x8000000 and divisor 0xffffffff

I suspect the one before is what git needs.

% git checkout ad80538cdfc06230e263d8e940925a6d4cc1b3d5
M doc/or1ksim.info
M doc/version.texi
Previous HEAD position was fdd700a... fix l.div with dividend 0x8000000 and divisor 0xffffffff
HEAD is now at ad80538... is-div-test.S: remove wrong code introduced in previous patch

I still don't see anything happening from git - just those "M" lines.

And no difference in the tests. I really don't know how to use git! I'm
not convinced from the feel that there are any real changes ... but no,
there are some:

% diff -ur ../or1ksim-or1k-master . | diffstat | grep -v Makefile | grep -v configure
../or1ksim-or1k-master/testsuite/or1ksim.tests/atomic.exp |only
../or1ksim-or1k-master/testsuite/site.bak |only
../or1ksim-or1k-master/testsuite/test-code-or1k/atomic |only
./.git |only
./ChangeLog | 27
./config.log | 17
./config.status | 16
./cpu/common/abstract.c | 14
./cpu/common/execute.h | 3
./cpu/or1k/except.c | 3
./cpu/or32/insnset.c | 43
./cpu/or32/or32.c | 4
./cpu/or32/simpl32-defs.h | 2
./cuc/load.c | 2
./doc/stamp-vti | 4
./doc/version.texi | 4
./testsuite/ChangeLog | 12
./testsuite/libsim.log | 1118 -
./testsuite/libsim.sum | 2
./testsuite/or1ksim.log |10911 +-------------
./testsuite/or1ksim.sum | 84
./testsuite/or1ksim.tests/inst-set-test.exp | 12
./testsuite/site.exp | 2
./testsuite/test-code-or1k/ChangeLog | 18
./testsuite/test-code-or1k/autom4te.cache |only
./testsuite/test-code-or1k/config.log | 155
./testsuite/test-code-or1k/config.status | 19
./testsuite/test-code-or1k/inst-set-test/is-div-test.S | 18
./testsuite/test-code-or1k/libtool | 2
106 files changed, 2978 insertions(+), 11005 deletions(-)

You'll have to look harder for the origin of those two fails for the sim
executable.

Peter

[Peter Gavin]

Post by Peter Breuer
Also possible. I'll let you know ... no, no difference, but I'm not a
git user and it appeared to me that that git command did nothing
much [but it does, it's just quiet .. see lower down this post]
% git checkout fdd700a
M doc/or1ksim.info
M doc/version.texi
HEAD is now at fdd700a... fix l.div with dividend 0x8000000 and divisor 0xffffffff
I suspect the one before is what git needs.

No, you had it right the first time :)

Those "M ..." lines show up because those files have been modified from
what's in the repo. That's normal, the build updates those two files but
no one has bothered to check in the modifications. You should be on the
"fix l.div..." patch, and it should be the first one that shows up when you
run git log.

Post by Peter Breuer
And no difference in the tests. I really don't know how to use git! I'm
not convinced from the feel that there are any real changes ... but no,

So rebuilding the older commit and running the testsuite still fails? Can
you send me a copy of the testsuite/or1ksim.log file that's generated by
running the testsuite?

-Pete

[Ouabache Designworks]

I have wiped my machine and doing a virgin install on Ubuntu 14.10 so I am
now reinstalling the complete openrisc tool chain from hopefully the latest
repos. Instructions say that or32-elf requires or1ksim as a prerequisite
but installing that gives me:

***@ouabache:~/Desktop/socgen/tools/or1ksim/or1ksim/builddir_or1ksim$
../configure --target=or32-elf --prefix=/opt/or1ksim
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... Invalid configuration `or32-elf': machine
`or32' not recognized
configure: error: /bin/bash ../config.sub or32-elf failed
***@ouabache:~/Desktop/socgen/tools/or1ksim/or1ksim/builddir_or1ksim$


There is a known circular dependency in there but do you need to have a
working or32-elf in order to
install or1ksim ?


John Eaton