On Fri, 2014-08-15 at 22:58 +0200, Oleg Endo wrote: > On Mon, 2014-08-04 at 08:19 +0200, Oleg Endo wrote: > > > > On Aug 4, 2014, at 6:00 AM, Gerald Pfeifer <ger...@pfeifer.com> wrote: > > > > > On Wed, 23 Jul 2014, Hans-Peter Nilsson wrote: > > >> The page <https://gcc.gnu.org/simtest-howto.html> is > > >> unfortunately out of date (e.g. binutils+sim now lives in the > > >> same git repo) but it gives you the idea. > > > > > > Sooo, any volunteer to update this page? Doesn't have to be > > > perfect, even incremental improvements help. > > > > > > Or is it bad enough that we should rather remove this unless/ > > > until someone steps up? > > > > Since I'm basically doing all the testing in sh-sim, I could try to update > > that page. > > How about the attached .html as a replacement for the current one? > I removed the requirement of setting up a combined tree, as I believe > it makes things much more easy. At least it's been working for me > that way. Is this helpful / OK to commit?
Maybe a patch is better in this case, instead of the whole .html. Cheers, Oleg
? simtest_howto.patch Index: simtest-howto.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/simtest-howto.html,v retrieving revision 1.29 diff -u -r1.29 simtest-howto.html --- simtest-howto.html 27 Jun 2014 11:48:46 -0000 1.29 +++ simtest-howto.html 15 Aug 2014 21:00:31 -0000 @@ -1,9 +1,41 @@ -<html> - <head> - <title>How to test GCC on a simulator</title> - </head> +<?xml version="1.0" encoding="utf-8"?> + <!DOCTYPE html + PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + + + + + + + + + + + + + + + <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> + + <head> + + <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> + <link rev="made" href="mailto:g...@gcc.gnu.org" /> + <link rel="shortcut icon" href="https://gcc.gnu.org/favicon.ico" /> + <link rel="stylesheet" type="text/css" href="https://gcc.gnu.org/gcc.css" /> + + <title> +How to test GCC on a simulator +- GNU Project - Free Software Foundation (FSF)</title> + + </head> + <body> + + + <h1>How to test GCC on a simulator</h1> <p>Several GCC targets can be tested using simulators. These allow @@ -11,270 +43,280 @@ access to hardware, or for targets that have general characteristics you'd like to test, like endianness or word size.</p> - <p>All of the instructions here start out from a directory we'll - call <code>${TOP}</code>, which is initially empty.</p> - - <h2>Set up sources</h2> - - <p>Testing with a simulator requires use of a combined tree; - you can't easily build newlib, required for simulator testing, - outside of a combined tree, and the build of the other components - is easiest in a combined tree.</p> - - <p>The combined tree contains GCC sources plus several modules of - the <code>src</code> tree: <code>binutils</code> and - <code>newlib</code> for the build and <code>sim</code> for the - simulators. If you already build with a combined tree you can use - your current setup; if not, these instructions will get you the - sources you need.</p> - - <h3>Check out initial CVS trees</h3> - - <p>If you don't yet have either tree you'll need to do an initial - check-outs.</p> + <h2>Setup</h2> - <p>Check out mainline GCC:</p> + <p>Testing with a simulator requires an installation of a working + GCC toolchain and a GDB simulator. For a list of supported targets please + refer to the <a href="http://www.sourceware.org/gdb/download/onlinedocs/gdb.html#Embedded-Processors">GDB documentation</a>. + The following describes how to create a Renesas SuperH cross compiler + setup that can be used for simulator testing. + </p> + <p>All of the instructions here start out from a directory we'll + call <code>${TOP}</code>, which contains the following directories with + unpacked sources: + <ul> + <li><code>${TOP}/binutils-src</code></li> + <li><code>${TOP}/gcc-src</code></li> + <li><code>${TOP}/newlib-src</code></li> + <li><code>${TOP}/gdb-src</code></li> + </ul> + and the following corresponding build directories which are initially + empty: + <ul> + <li><code>${TOP}/binutils-build</code></li> + <li><code>${TOP}/gcc-build</code></li> + <li><code>${TOP}/newlib-build</code></li> + <li><code>${TOP}/gdb-build</code></li> + </ul> + To keep things simple, all parts of the cross toolchain will be installed + into <code>/usr/local</code>, which usually requires superuser rights for + writing. If that is inconvenient, you might also install it into another + place. + </p> + + <h3>Build and install Binutils</h3> <pre> -cd ${TOP} -svn checkout svn://gcc.gnu.org/svn/gcc/trunk gcc -# This makes sure that file timestamps are in order initially. -cd ${TOP}/gcc -contrib/gcc_update --touch +cd ${TOP}/binutils-build +../binutils-src/configure --target=sh-elf --prefix=/usr/local --disable-nls --disable-werror +make all +sudo make install </pre> + This should have installed the cross binutils for the target, e.g. + <code>sh-elf-as</code> is the assembler for our SuperH target. - <p>Check out the <code>src</code> tree:</p> + <h3>Build and install GCC (compiler only)</h3> <pre> -cd ${TOP} -cvs -d :pserver:anon...@sourceware.org:/cvs/src login -# You will be prompted for a password; reply with "anoncvs". -cvs -d :pserver:anon...@sourceware.org:/cvs/src co binutils newlib sim +cd ${TOP}/gcc-build +../gcc-src/configure --target=sh-elf --prefix=/usr/local --enable-languages=c,c++ --disable-nls --disable-werror --with-newlib --enable-lto --enable-multilib +make all-gcc +sudo make install-gcc </pre> + This should have installed the cross compiler for the target, e.g. + <code>sh-elf-gcc</code> is the compiler for our SuperH target. - <h3>Update CVS trees</h3> - - <p>You can update existing CVS trees rather than starting from - scratch each time. Update the GCC tree using the - <code>gcc_update</code> script, which touches generated files and - handles directory changes in the tree. Be sure to do this from - the directory in which you did the original check-out, NOT in the - combined tree:</p> - + <h3>Build and install C target runtime library</h3> <pre> -cd ${TOP}/gcc -contrib/gcc_update +cd ${TOP}/newlib-build +../newlib-src/configure --target=sh-elf --prefix=/usr/local --enable-lto --enable-multilib +make all +sudo make install </pre> - <p>Update the <code>src</code> tree with the same sequence of - commands that you used to check out that tree initially, invoked from - the <code>src</code> directory (NOT from within the combined tree).</p> - - <h3>Create a combined tree</h3> - - <p>Create a tree that consists of all of the files from the GCC and - binutils/sim/newlib source trees (including several simulators in - <code>src/sim</code>), with the GCC files overriding the - binutils/sim/newlib files when there's a conflict. It's done this - way because the GCC files are the master copy. To save on disk - space, these commands actually make a tree of hard links rather - than duplicating all the files:</p> + <h3>Build and install GCC (full)</h3> +<pre> +cd ${TOP}/gcc-build +rm -rf * +../gcc-src/configure --target=sh-elf --prefix=/usr/local --enable-languages=c,c++ --disable-nls --disable-werror --with-newlib --enable-lto --enable-multilib +make all +sudo make install +</pre> + This should have installed the cross compiler along with the cross compiled + runtime libraries such as <code>libgcc</code> and <code>libstdc++</code> + for our SuperH target. + <h3>Build and install GDB</h3> +<pre> +cd ${TOP}/gdb-build +../gdb-src/configure --target=sh-elf --prefix=/usr/local +make all +sudo make install +</pre> + This should have installed the cross GDB for the target along with the + simulator, e.g. <code>sh-elf-run</code> invokes the simulator for our + SuperH target. + <p> + Depending on the simulated target and its implementation in GDB, there + might be host system related issues. E.g. at the time of this writing, + the SuperH GDB simulator does not work properly on 64 bit hosts. + There might also be differences in simulated floating point calculations + which may cause some of the GCC tests to fail. + To build a 32 bit GDB on a x86_64 host do the following: <pre> -cd ${TOP} -rm -rf combined -mkdir combined -cd src && find . -print | cpio -pdlm ../combined && cd .. -cd gcc && find . -print | cpio -pdlmu ../combined && cd .. +cd ${TOP}/gdb-build +export CFLAGS="-O2 -m32 -msse -mfpmath=sse" +export CXXFLAGS="-O2 -m32 -msse -mfpmath=sse" +../gdb-src/configure --target=sh-elf --prefix=/usr/local --enable-interwork --enable-multilib +make all +sudo make install </pre> + Notice that the configure script will try to look for the required + libraries as 32 bit versions, which you might have to install separately in + addition to the 64 bit libraries. + </p> - <h2>Build it</h2> - <p>Use a recent version of GCC as the build compiler, no earlier - than 2.95.</p> + <h2>Test it</h2> - <p>The target name suitable for the simulator is usually `*-elf' for a - target `*'. There are some exceptions, for instance on powerpc - it's powerpc-eabi or powerpc-eabisim. Here we build - <code>arm-elf</code>.</p> + Your cross toolchain should now be ready. You might want to briefly test + this by compiling the following C++ program: +<pre> +#include <iostream> +int main (void) +{ + std::cout << "Alice calling Bob." << std::endl; + return 0; +} +</pre> + as follows: <pre> -cd ${TOP} -mkdir build install -cd build -../combined/configure \ - --target=arm-elf --prefix=${TOP}/install -make +sh-elf-g++ main.cpp +sh-elf-run a.out </pre> - <h2>Test it</h2> + + <h2>Run the GCC Testsuite</h2> <p>The only trick here is that you want DejaGNU to use the simulator rather than trying to run the output on the build system. For example:</p> <pre> -cd ${TOP}/build -make check-gcc check-target-libstdc++-v3 RUNTESTFLAGS=--target_board=arm-sim +cd ${TOP}/gcc-build +make check-gcc check-target-libstdc++-v3 RUNTESTFLAGS=--target_board=sh-sim </pre> or just <pre> -cd ${TOP}/build -make check RUNTESTFLAGS=--target_board=arm-sim +cd ${TOP}/gcc-build +make check RUNTESTFLAGS=--target_board=sh-sim </pre> to exercise the just-built gcc on every test-suite in the tree. <p>The only reliable way (apart from guessing that it's probably `*-sim') to find out the name of the target board is to look in the DejaGNU sources, in <code>/usr/share/dejagnu/baseboards</code>, for - something that looks right. Or you can use this table of combinations - that at one time compiled, usable as test-targets with the - instructions above.</p> - - <p>You can compare your test results against the archived results - linked below to detect major problems. As always, if you're testing - a patch you should compare your results with and without the patch.</p> - - <p>The target characteristic can help you determine which targets to - use to broaden the scope of your testing. A cc0 target uses a - single condition code register, cc0, which is set as a side effect - of most instructions. The compiler cannot insert other instructions - between the instruction that sets cc0 and the one that uses it. - Because of this, a cc0 target causes - significantly different code to be generated and can matter more - than word size and endianness in terms of detecting new breakage.</p> - + something that looks right. As a starting point you can also use the + following table: + <table border="0" cellspacing="5" cellpadding="5"> <tr valign="top" align="left"> - <th>Target</th><th>Simulator</th><th>Comments</th><th>Test Results</th> + <th>Target</th><th>Simulator</th> </tr> <tr valign="top"> <td>arm-elf</td> <td>arm-sim</td> - <td>32-bit word, little endian</td> - <td> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00592.html">3.3 20030509 (prerelease)</a> - <br /> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00949.html">3.2.3 20030415 (prerelease)</a> - </td> </tr> <tr valign="top"> <td>fr30-elf</td> <td>fr30-sim</td> - <td>32-bit word, big endian</td> - <td> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00766.html">3.3 20030509 (prerelease)</a> - </td> </tr> <tr valign="top"> <td>h8300-coff</td> <td>h8300-sim</td> - <td>cc0 target, big endian</td> - <td> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00624.html">3.3 20030509 (prerelease)</a> - <br /> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00967.html">3.2.3 20030415 (prerelease)</a> - </td> </tr> <tr valign="top"> <td>m32r-elf</td> <td>m32r-sim</td> - <td>32-bit word, big endian</td> - <td> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-05/msg01478.html">3.3</a> - </td> </tr> <tr valign="top"> <td>mips-elf</td> <td>mips-sim</td> - <td>big endian</td> - <td> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00636.html">4.1.0 20051112 (experimental)</a> - <br /> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00619.html">3.3 20030509 (prerelease)</a> - </td> </tr> <tr valign="top"> <td>mipsisa64-elf</td> <td>mips-sim-idt64</td> - <td> </td> - <td> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-06/msg00335.html">3.4 20030605 (experimental)</a> - </td> </tr> <tr valign="top"> <td>mn10300-elf</td> <td>mn10300-sim</td> - <td>cc0 target, little endian</td> - <td> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00632.html">3.3 20030509 (prerelease)</a> - <br /> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00972.html">3.2.3 20030415 (prerelease)</a> - </td> </tr> <tr valign="top"> <td>powerpc-eabisim</td> <td>powerpc-sim</td> - <td>32-bit word, big endian</td> - <td> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-03/msg00033.html">3.4 20030301 (experimental)</a> - </td> </tr> <tr valign="top"> <td>sh-coff</td> <td>sh-hms</td> - <td> </td> - <td> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00622.html">3.3 20030509 (prerelease)</a> - <br /> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00964.html">3.2.3 20030415 (prerelease)</a> - </td> </tr> <tr valign="top"> <td>sh-elf</td> <td>sh-sim</td> - <td>big endian</td> - <td> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01441.html">4.2.0 20060226 (experimental)</a> - <br /> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-06/msg00315.html">3.4 20030605 (experimental)</a> - <br /> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00631.html">3.3 20030509 (prerelease)</a> - <br /> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00970.html">3.2.3 20030415 (prerelease)</a> - </td> </tr> <tr valign="top"> <td>sparc-elf</td> <td>sparc-sim</td> - <td> </td> - <td> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00587.html">3.3 20030507 (prerelease)</a> - <br /> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00942.html">3.2.3 20030415 (prerelease)</a> - </td> </tr> <tr valign="top"> <td>v850-elf</td> <td>v850-sim</td> - <td>cc0 target, 32-bit word, little endian</td> - <td> - <a href="https://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00978.html">3.2.3 20030415 (prerelease)</a> - </td> </tr> </table> + </p> + + <p>You can compare your test results against the <a href="https://gcc.gnu.org/ml/gcc-testresults/">archived results</a>. + Notice that running tests on simulators will often show more failures than + usual due to restrained memory capacity of the simulator and lack of other + features such as threads. As always, if you're testing a patch you should + compare your results with and without the patch.</p> + + <p>The target characteristic can help you determine which targets to + use to broaden the scope of your testing. A cc0 target uses a + single condition code register, cc0, which is set as a side effect + of most instructions. The compiler cannot insert other instructions + between the instruction that sets cc0 and the one that uses it. + Because of this, a cc0 target causes significantly different code to be + generated and can matter more than word size and endianness in terms of + detecting new breakage.</p> + + <p>In order to run the tests with various combinations of compiler flags + that control the target's architecture settings e.g. the following can be + used: +<pre> +make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,-m2a/-mb,-m2a-single/-mb,-m4/-ml,-m4/-mb,-m4-single/-ml,-m4-single/-mb,-m4a-single/-ml,-m4a-single/-mb}" +</pre> + which will run the GCC testsuite ten times for different combinations of + processor and endianness configurations of the SuperH target. Depending on + how the cross GCC was configured, specifying additional compiler options + might be necessary to get meaningful results. E.g. the SuperH compiler as + configured above will by default generate code for big endian SH-1 if no + further options are specified, which covers only a subset of the SuperH ISA. + </p> + +<!-- ==================================================================== --> + +<div class="copyright"> + +<address style="margin-top:0;">For questions related to the use of GCC, +please consult these web pages and the +<a href="https://gcc.gnu.org/onlinedocs/">GCC manuals</a>. If that fails, +the <a href="mailto:gcc-h...@gcc.gnu.org">gcc-h...@gcc.gnu.org</a> +mailing list might help. +Comments on these web pages and the development of GCC are welcome on our +developer list at <a href="mailto:g...@gcc.gnu.org">g...@gcc.gnu.org</a>. +All of <a href="https://gcc.gnu.org/lists.html">our lists</a> +have public archives. +</address> + +<p>Copyright (C) +<a href="http://www.fsf.org">Free Software Foundation, Inc.</a> +Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved.</p> + +<p style="margin-bottom:0;">These pages are +<a href="https://gcc.gnu.org/about.html">maintained by the GCC team</a>. +Last modified 2014-06-27<!-- IGNORE DIFF +--><a href="http://validator.w3.org/check/referer">.</a></p> + +</div> + +<!-- ==================================================================== --> + </body> -</html> + </html> + +