This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[RFA:] Moving simtest-howto.html to gcc.gnu.org
- To: <gcc-patches at gcc dot gnu dot org>, Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>
- Subject: [RFA:] Moving simtest-howto.html to gcc.gnu.org
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- Date: Wed, 25 Jul 2001 21:33:40 -0400 (EDT)
Phase 1. These patches add Geoff's recommendable
simtest-howto.html page locally and link to it in a couple of
hopefully strategic pages. It seems this was the direction
agreed on.
Ok to commit?
Index: develop.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v
retrieving revision 1.4
diff -p -c -r1.4 develop.html
*** develop.html 2001/07/23 16:25:16 1.4
--- develop.html 2001/07/26 01:18:24
*************** command-line options, should be document
*** 72,78 ****
targeting a different microprocessor family. Validation should
consist of bootstrapping the compiler (unless that is impossible for
the microprocessor selected) and checking that there are no new
! regression test failures. It is acceptable to use a simulator for
validation; the use of real hardware is not required.</p>
</ul>
--- 72,79 ----
targeting a different microprocessor family. Validation should
consist of bootstrapping the compiler (unless that is impossible for
the microprocessor selected) and checking that there are no new
! regression test failures. It is acceptable to <a
! href="simtest-howto.html">use a simulator</a> for
validation; the use of real hardware is not required.</p>
</ul>
Index: cvswrite.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/cvswrite.html,v
retrieving revision 1.40
diff -p -c -r1.40 cvswrite.html
*** cvswrite.html 2001/06/29 19:08:54 1.40
--- cvswrite.html 2001/07/26 01:24:17
*************** following:
*** 144,150 ****
good enough to have bootstrapped with an earlier variant. (Unless
the only changes from the earlier variant are formatting and
comment changes; if there are <strong>any</strong> changes to the code
! itself you should re-bootstrap.)</li>
<li>If your change is to code that is not in a front-end, or is to
the C front-end, verify that the all of the GCC regression tests
--- 144,152 ----
good enough to have bootstrapped with an earlier variant. (Unless
the only changes from the earlier variant are formatting and
comment changes; if there are <strong>any</strong> changes to the code
! itself you should re-bootstrap.) It is recommended that you also <a
! href="simtest-howto.html">use a simulator</a> to increase your test
! coverage.</li>
<li>If your change is to code that is not in a front-end, or is to
the C front-end, verify that the all of the GCC regression tests
*** /dev/null Tue Jan 1 05:00:00 1980
--- simtest-howto.html Thu Jul 26 02:13:39 2001
***************
*** 0 ****
--- 1,66 ----
+ <html>
+ <head>
+ <title>How to test GCC on a simulator</title>
+ </head>
+
+ <body>
+ <h1>How to test GCC on a simulator</h1>
+
+ Suppose you want to test GCC on some strange target, for which you
+ don't have hardware. Let's pick d30v as an example. You can do it
+ like this:
+
+ <h2>1. Create a combined tree.</h2>
+
+ I'm assuming you're starting from scratch, so you don't have an
+ installed binutils or newlib for the strange target. So you'll need
+ to build these. You can't easily build newlib outside a combined
+ tree. Start in an empty directory, then do this:
+ <pre>
+ mkdir gcc src combined
+ cd gcc
+ cvs -d :pserver:anoncvs@gcc.gnu.org:/cvs/gcc co gcc-full
+ cd ../src
+ cvs -d :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src co \
+ binutils newlib dejagnu gdb
+ cd src
+ find . -print | cpio -pdlm ../../combined
+ cd ../../gcc/gcc
+ find . -print | cpio -pdlmu ../../combined
+ cd ../..
+ </pre>
+
+ <p>This will create, in `combined', a tree which consists of all the
+ files from the gcc and binutils/gdb/newlib source trees, with the gcc
+ files overriding the binutils/gdb/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, the commands above actually make a tree
+ of hard links, rather than duplicating all the files.
+
+ <h2>2. Build it.</h2>
+
+ 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, and for i960 there isn't an elf
+ target yet so i960-coff is probably your best choice.
+
+ <pre>
+ mkdir build install
+ cd build
+ ../combined/configure --target=d30v-elf --prefix=`pwd`/../install
+ make
+ </pre>
+
+ <h2>3. Test it.</h2>
+
+ The only trick here is that you want dejagnu to use the simulator,
+ not try running the output on the build system. 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 dejagnu/baseboards, for something that looks right.
+
+ <pre>
+ make check-gcc RUNTESTFLAGS=--target_board=d30v-sim
+ </pre>
+ </body>
+ </html>
brgds, H-P