On Fri, 2012-03-16 at 14:29 +0000, R. Diez wrote:
> Hi all:
>
> I have written a set of scripts to build many OpenRISC components from
> scratch, and I came across some issues with or1ksim. I read here that
> I need to build or1ksim before building the toolchain:
>
> http://lists.openrisc.net/pipermail/openrisc/2011-August/000098.html
>
> and indeed argument --with-or1ksim=<path> is passed to GCC's configure
> script.
>
> However I searched for "or1ksim" under directory gcc-4.5.1 to no
> avail, so I wonder whether this flag is actually needed.
>
> The trouble is, if you build or1ksim before building the toolchain,
> then or1ksim's configure script cannot find the cross-compiler. The
> problem in this file:
>
> <or1ksim repository>/testsuite/test-code-or1k/configure.ac
>
> at this line:
>
> AC_CHECK_PROGS(CC, [$target_alias-gcc])
>
> If the cross-compiler is not found, variable CC remains empty, but the
> configuration step will succeed and or1ksim will build without
> problems. However, later on, if you do a "make check" you'll get weird
> compilation errors, and it took me a while to figure out why.
> The work-around I'm using at the moment is to reconfigure or1ksim
> after building the toolchain, just before running "make check".
Hi R Diez,
I remember this original email. Thanks for all your work on this.
This is a known circular dependency problem with Or1ksim.
Or1ksim is currently used as the simulator for GDB, so is needed to
build the GNU tool chain. However Or1ksim regression testing needs the
GNU tool chain. You have hit on the correct solution.
1. Configure, build and install (but don't test Or1ksim)
2. Configure, build, install and test the GNU tool chain
3. Add the new GNU tool chain to the path
4. Reconfigure, test Or1ksim
In fact once you have a first version of the tool chain, then you won't
need to reconfigure Or1ksim (so long as your new tool chain uses the
same path as the old).
Personally, I always install by tool chains in a timestamped
directory /opt/epiphany-`date -u +%F-%H%M` and then symbolically
link /opt/epiphany-new to that directory at the end of a successful tool
chain build. That way I can have my path always pointing to the latest
tool chain, while retaining previous versions if I wish to.
The real answer is not to use Or1ksim as the built-in GNU simulator. It
was a stop-gap measure in the absence of a proper CGEN based simulator.
Thanks to Julius Baxter's work, we are pretty close to having a working
CGEN simulator, so we'll be able to let Or1ksim revert to its original
role as a standalone simulator.
> Something needs to change in or1ksim's documentation or in the
> configure script. I think configuring or1ksim's test suite (or at
> least the test-code-or1k subset) should be a separate step that you
> have to trigger manually. At the moment, it's automatically triggered
> when configuring the rest of or1ksim. The above Makefile.am should
> fail with an explicit error message if it cannot find the
> cross-compiler.
As noted, I think this is a transient problem. The effort should be put
into getting the CGEN simulator validated and into the standard
repository. I believe Pete Gavin is working on this.
The Or1ksim automake needs revising. I think having a separate
configure.ac for the testsuite was a mistake. A unified configuration is
more sensible.
The intention is that Or1ksim should be built only after the tool chain
- that was always the case until I tried integrating it into GDB. It
should certainly give a warning if it can't find the target tool chain.
> In another interesting twist, the above Makefile.am tries to find the
> right simulator:
>
> AC_CHECK_PROGS(SIM, [$target_alias-sim])
>
> However, variable SIM does not seem to be used anywhere. The simulator
> filename is actually hard-coded in this file:
>
> <or1ksim repository>/testsuite/lib/or1ksim.exp
>
> proc run_or1ksim { testname match_list config_file progname } {
> ...
> set command_line "$objdir/../sim -f $config_full_file
> $prog_full_name"
>
> If the configuration script tries to find a simulator, the tests
> should use the one found, right?
Quite right. This is a bug that should be fixed! I should like to offer
to help, but currently I am rather snowed under with the day job!
Hope this is useful info.
Best wishes,
Jeremy
--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: [email protected]
Web: www.embecosm.com
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc
