From patchwork Wed Sep 10 19:46:51 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans-Peter Nilsson X-Patchwork-Id: 387958 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id D0AD5140185 for ; Thu, 11 Sep 2014 05:47:07 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:mime-version:content-type; q=dns; s=default; b=DQnHHpPQuJJwPc+kgtER6x+KPCNN47BWlsSDdeFO+p2lGbSqZl oAIoj5lVitddMHbz/u20tovj1g8o9w8M9+dWm2NoyhGiNWrcChoVS/yRelzt8Uur aP3gwOJaLlO/Gzm3iS1LNAObC3RWVp63u8LecQaxpvedxFII/MZcjbvwk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:mime-version:content-type; s= default; bh=16VhUj2HXA4hWYIhMB2ZmaKXyWs=; b=xYJkwI28scaGD1KHPURC Ieghk64Jcc2Wg+Y4NuzS737pWxVea/h0gY5uCThnX212uiaK1Xi0j04lyeLIn94H lnAvmZjIFOrWGeGFfomhFD6jPIo8SsLKpJVKk3fkkbYy1oBrsp5BD5uOhsXXWWAf 3lfNthcw5JP8gvtSiWAChrc= Received: (qmail 17746 invoked by alias); 10 Sep 2014 19:47:00 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 17735 invoked by uid 89); 10 Sep 2014 19:47:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL, BAYES_00, HK_OBFDOM, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=no version=3.3.2 X-HELO: arjuna.pair.com Received: from arjuna.pair.com (HELO arjuna.pair.com) (209.68.5.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 10 Sep 2014 19:46:57 +0000 Received: by arjuna.pair.com (Postfix, from userid 3006) id CB4FC8A261; Wed, 10 Sep 2014 15:46:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by arjuna.pair.com (Postfix) with ESMTP id BAAB98A224; Wed, 10 Sep 2014 15:46:51 -0400 (EDT) Date: Wed, 10 Sep 2014 15:46:51 -0400 (EDT) From: Hans-Peter Nilsson To: gcc-patches@gcc.gnu.org cc: oleg.endo@t-online.de, derodat@adacore.com, gingold@adacore.com Subject: Committed: update simtest-howto.html Message-ID: User-Agent: Alpine 2.02 (BSF 1266 2009-07-14) MIME-Version: 1.0 X-IsSubscribed: yes (Thanks to people CC'ed and others forgotten; I hope I incorporated at least some of everyone's suggestions.) First, as noted, the instructions are outdated due to repos merging, splitting, moving and switching, with fallout such as it now seemed odd as-is with one minor component randomly being named "src". (It's a CVS artefact: when the "-d topdir" option is used, cvs-1.11.22 gets confused over the "newlib" subdirectory different to the "newlib" CVS module; add -N and you get the "src" subdirectory anyway, within "topdir". Love CVS! If someone has a simple working solution just using options and it works for me too, we can call the newlib topdir something else than "src". In the meantime, not going there.) There was other outdated information, such as gcc-2.95 being a valid host-gcc. Hah! Better point to the general build prerequisites. Also, the idea of using a *combined* tree here, has been challenged, so I toned down the wording from the actual "require" to the negation(!) and added an apologetic blurb. (For my own autotester, I use a separate install as mentioned in the blurb, if only to simplify not depending on a simultaneous working state, but I wouldn't do a separate build just for newlib, so some kind of combination instructions seems called for anyway.) There has also historically been people doing their edits in the combined tree. (Understandable; that's where gdb points...) Better add a few words about that. With the combined binutils-gdb.git used as-is, now GDB has to be manually disabled so we don't have to worry about its target obsoletion triggers. The gdb we're likely to use it probably the host gdb anyway. (If it's recent enough that is; if not, it might be a good idea to install a native build somewhere locally, to apply on the cross-gcc.) Also arm-elf is obsoleted, so let's choose arm-eabi for the example. Except when trying that, thebuild gets lost building libjava. (Target maintainers: don't be afraid to add a clause for your target in the *first* case in top/configure.ac where unsupported_languages is set for a target, for languages you never use and never intend to build. For example, I know vax should do a 'unsupported_languages="$unsupported_languages "', as last time I checked, it didn't build for c++ and when checked, only C support was intended.) Rather than choosing a target which mostly by coincidence doesn't enable java (lack of libffi), I just added a language option to make it more likely for a random build for a random target to complete. ISTR reports to the gcc-testresults@ for several targets but just for c and c++ enabled. If you think this is a bad move, I'd value work fixing the situation in the right way (see above) higher than just an opinion. Also, the reason is explained and people are free to not use --enable-languages when testing. I see mcore-elf build; I could use that instead but let's not go to far off main-stream. I could use cris-elf if I also wanted decent test-results, but I'm probably too biased to offer that with a straight face. ;) As a future step, we may want to just drop the status-ish table at the end, for one it's out of date by a decade. Briefly watched locally, committed; watched again on-line to catch glaring mark-up errors. brgds, H-P Index: simtest-howto.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/simtest-howto.html,v retrieving revision 1.29 retrieving revision 1.30 diff -p -u -r1.29 -r1.30 --- simtest-howto.html 27 Jun 2014 11:48:46 -0000 1.29 +++ simtest-howto.html 10 Sep 2014 19:37:25 -0000 1.30 @@ -16,22 +16,32 @@

Set up sources

-

Testing with a simulator requires use of a combined tree; +

Testing with a simulator makes use of a combined tree here; 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.

+ is easiest in a combined tree. A combined tree is not a + requirement for testing with a simulator; other alternatives + exist. For example, binutils and simulators can be built for the + target, and installed beforehand. However, we use a combined tree + here as it's a convenient example and does not require separate + installation steps or parameters.

-

The combined tree contains GCC sources plus several modules of - the src tree: binutils and - newlib for the build and sim for the +

The combined tree contains GCC sources plus binutils and + newlib for the generated code and sim 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.

-

Check out initial CVS trees

+

-

If you don't yet have either tree you'll need to do an initial - check-outs.

+

Check out initial trees

+ +

We check out each component from each separate project's + version-control-system repository, but it's possible to use + release or snapshot tarballs, with an increased risk of version + lag causing configuration framework mismatches in the combined + tree. If you don't yet have either tree you'll need to do some + initial check-outs.

Check out mainline GCC:

@@ -43,19 +53,26 @@ cd ${TOP}/gcc contrib/gcc_update --touch -

Check out the src tree:

+

Check out the newlib (src) tree:

 cd ${TOP}
 cvs -d :pserver:anoncvs@sourceware.org:/cvs/src login
 # You will be prompted for a password; reply with "anoncvs".
-cvs -d :pserver:anoncvs@sourceware.org:/cvs/src co binutils newlib sim
+cvs -d :pserver:anoncvs@sourceware.org:/cvs/src co newlib
+
+ +

Check out the sim and binutils tree:

+ +
+cd ${TOP}
+git clone git://sourceware.org/git/binutils-gdb.git sim+binutils
-

Update CVS trees

+

Update trees

-

You can update existing CVS trees rather than starting from - scratch each time. Update the GCC tree using the +

You can update existing CVS, git and subversion trees rather than + starting from scratch each time. Update the GCC tree using the gcc_update 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 @@ -66,17 +83,23 @@ cd ${TOP}/gcc contrib/gcc_update -

Update the src tree with the same sequence of - commands that you used to check out that tree initially, invoked from - the src directory (NOT from within the combined tree).

+

Update the newlib src tree with the same sequence of + commands that you used to check out that tree initially + (edits in the src tree will be preserved). + Make sure you do not do this from within the combined tree. + For the binutils+sim tree a normal git pull command will do. + Remove the combined tree and re-create it. (Beware, edits in the + combined tree will be lost.)

Create a combined tree

Create a tree that consists of all of the files from the GCC and binutils/sim/newlib source trees (including several simulators in - src/sim), 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 + the sim directory), with the GCC files overriding the + binutils/sim/newlib files when there's a conflict, and binutils and + with sim overriding newlib files. It's done this way because the GCC + files are the master copy, while binutils and gdb move faster than + newlib. To save on disk space, these commands actually make a tree of hard links rather than duplicating all the files:

@@ -85,25 +108,30 @@ cd ${TOP} rm -rf combined mkdir combined cd src && find . -print | cpio -pdlm ../combined && cd .. +cd sim+binutils && find . -print | cpio -pdlmu ../combined && cd .. cd gcc && find . -print | cpio -pdlmu ../combined && cd ..

Build it

-

Use a recent version of GCC as the build compiler, no earlier - than 2.95.

+

Make sure the + building + prerequisites for GCC are met, for example a host GCC no earlier + than 3.4 or later, with C++ support enabled.

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 - arm-elf.

+ it's powerpc-eabi or powerpc-eabisim, and for arm, the arm-elf support + is obsoleted. Here we build arm-eabi, but we avoid gdb + and build only for the c and c++ languages, because some of the targets + mentioned below will otherwise fail building.

 cd ${TOP}
 mkdir build install
 cd build
 ../combined/configure \
-    --target=arm-elf --prefix=${TOP}/install
+    --target=arm-eabi --disable-gdb --enable-languages=c,c++ --prefix=${TOP}/install
 make