Here's what's to be done for maintaining GCC.
Apart from the target-specific configuration machinery, there shouldn't be any major differences within GCC between the GNU/Hurd and GNU/Linux ports, for example. Especially all the compiler magic is all the same.
General information
Sources
Configuration
Last reviewed up to the Git mirror's 71cfadefb994de9249449fb7e71be012b6264a3f (2013-02-17) sources.
http://gcc.gnu.org/install/configure.html has documentation for the
configure switches.
Configure fragments that have
*linux*cases might/should often contain those for us (and GNU/k*BSD) as well.configure.aclibgomp/configure.tgtlibstdc++-v3/configure.hostabi_baseline_pairetc. setting.libstdc++-v3/config/os/gnu-linux/*Is used for all GNU systems, as per
libstdc++-v3/configure.host. Should rename tognu-userto reflect this?gcc/acinclude.m4:gcc_GAS_FLAGS: always pass--32to assembler for x86 Linux. (Why?)
hurd/usrNATIVE_SYSTEM_HEADER_DIR,638454a19c1c08f01c10517bc72a114250fc4f33,id:"mcrzkhcbftp.fsf@coign.corp.google.com".Debian.
- Eventually: get rid of this special-casing.
id:"gckk1s$e0b$1@ger.gmane.org".
- Eventually: get rid of this special-casing.
-
Also see
libgcc/config/i386/morestack.S: comments w.r.tTARGET_THREAD_SPLIT_STACK_OFFSET/%gs:0x30usage; likely needs porting.As per
libgcc/config/i386/t-stack-i386, the former file is only used for-fsplit-stacksupport -- which is currently enabled for us inlibgcc/config.host.gcc/config/gnu-user.hdefines*SPLIT_STACK*macros -- which aren't valid for us (yet), I think.Might
-fsplit-stackbe useful for us with respect to our multithreaded libraries?
--enable-languages=[...]Ada (GNAT) support is work in progress.
The Google Go's libgo (introduced in e440a3286bc89368b8d3a8fd6accd47191790bf2 (2010-12-03)) needs OS configuration / support.
--enable-frame-pointergcc/configure.ac:enable_frame_pointer=no--with-dwarf2?--enable-werror--enable-checking--enable-linker-build-id--enable-gnu-unique-object--enable-lto--enable-indirect-functionhttp://gcc.gnu.org/ml/gcc/2007-11/msg00289.html, http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00672.html
gcc/config/t-linuxshould be namedgcc/config/t-gnu-useror similar. Likewise forgcc/config/i386/t-linux.
Debian's GCC package has Hurd-specific patches. Some have been forwarded upstream (and have been ignored). Thomas Schwinge is working on getting them integrated.
build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR
-fstack-protector shouldn't use TLS in freestanding mode
- See also commit bf1c0af128f33bd342636c4afeaa8f3a8a7cf8ca (reverted in commit a204f0622242865ffea889bd698bc7c7bd236bd1), commit 05c1aa95e6c37b3b281d749c76c673392941a031.
Check before/after Joseph changes. (Should be fine.)
34618b3190c110b8926cc2b1db4b4eac95451995 »config-list.mk«
What's this used for? (Check ML.) Ask to include i686-pc-gnu (once it is buildable out of the box)? See also 73905b5de0d9a086f22ded7638bb1c0ae1b91326.
Various testsuite bits should include
*-*-gnu*, too.[low] cross-gnu toolchain bootstrap vs.
fenv.hin libgcc's libbid:[...]/xgcc [...] -DIN_LIBGCC2 -fbuilding-libgcc [...] -Dinhibit_libc [...] -o bid_decimal_globals.o [...] -c [...]/libgcc/config/libbid/bid_decimal_globals.c [...]/libgcc/config/libbid/bid_decimal_globals.c:47:18: fatal error: fenv.h: No such file or directory compilation terminated. make[1]: *** [bid_decimal_globals.o] Error 1 make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj/i686-pc-gnu/libgcc' make: *** [all-target-libgcc] Error 2See threads at
id:"AANLkTinY1Cd4 qO 9euYJN8zev4hdr7 ANpjNG+yGRMn@mail.gmail.com",id:"20110328225532.GE5293@synopsys.com",id:"4D52D522.1040804@gmail.com". Can simply configure the first GCC with--disable-decimal-float.Alternatively, can we use
#ifndef inhibit_libcfor this (these?) file(s)? Seegeneric-nonstrack.c, for example. The latter (and alsogeneric-morestack-thread.c) also has a nice explanation ofinhibit_libcwhich could be centralized at one place, for example definition ofinhibit_libc.[low] cross-gnu
The directory that should contain system headers does not exist: /media/boole-data/thomas/tmp/gnu-0/sys_root/usr/include make[2]: *** [stmp-fixinc] Error 1 make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj'mkdirthe directory for now, but what is really going on? GCC has use/usr/includepatch, but glibc still installs into/include/?__GLIBC__IRC, freenode, #hurd, 2012-01-05:
<civodul> on GNU/kFreeBSD, it's GCC that defines __GLIBC__, funny <youpi> ?? <youpi> not from features.h ? <civodul> in gcc/config/kfreebsd-gnu.h <civodul> :-) <pinotree> correct, it's enabled in gcc's config <pinotree> i discovered that after banging my head on the wall trying to find out why some stuff wasn't compiling even after kfreebsd porting patches adding preprocessors checks for __GLIBC__GNU/kFreeBSD and GNU/kNetBSD: commit 6396cc37141180db4d2c8f73cab4f5977d8a1e19 (2004-06-24, r83577), GNU/kOpenSolaris: commit 3bef40126fb1633018fce47828df0fa9f65f110c (2009-01-29, r143768). See also GDB commits fda1b24c62843f81d31de2af57b1ed9c55f1e348 and 1acb4f4ff73d20850a7524fc939d2651be75f47b, and binutils commits e3081899be7570eb90ccfd5d767950d3a62871ee, 127c4d4a4fe65bd17ea64db1be7f3c93d393afcb, 47dbf5b634b955c2db1221715d15751e1281546a, and ad2be7e8b846f4cd67fa1e032f98d5dc1cdb6b8d.
IRC, freenode, #hurd, 2012-05-25:
<gnu_srs> Hi, looks like __GLIBC__ is not defined by default for GNU? <gnu_srs> touch foo.h; cpp -dM foo.h|grep LIBC: empty <braunr> gnu_srs: well, this only tells your the compiler defaults <tschwinge> gnu_srs: See the email I just sent.id:"87396od3ej.fsf@schwinge.name"<braunr> __GLIBC__ would probably be introduced by a glibc header <gnu_srs> tschwinge: I saw your email. I wonder if features.h is included in the kFreeBSD build of webkit. <gnu_srs> It is defined in their build, but not in the Hurd build. <pinotree> gcc on kfreebsd unconditionally defines __GLIBC__ <pinotree> (a bit stupid choice imho, but hardly something that could be changed now...) <braunr> :/ <braunr> personally i don't consider this only "a bit" stupid, as kfreebsd is one of the various efforts pushing towards portability <braunr> and using such hacks actually hinders portability ... <pinotree> yeah don't tell me, i can remember at least half dozen of occasions when a code wouldn't have been compiling at all on other glibc platforms otherwise <pinotree> sure, i have nothing against kfreebsd's efforts, but making gcc define something which is proper of the libc used is stupid <braunr> it is <pinotree> i spotted changes like: <pinotree> -#ifdef __linux <pinotree> +#if defined(__linux__) || defined(__GLIBC__) <pinotree> and wondered why they wouldn't work at all for us... and then realized there were no #include in that file before that preprocessor check <tschwinge> This is even in upstream GCC gcc/config/kfreebsd-gnu.h: <tschwinge> #define GNU_USER_TARGET_OS_CPP_BUILTINS() \ <tschwinge> do \ <tschwinge> { \ <tschwinge> builtin_define ("__FreeBSD_kernel__"); \ <tschwinge> builtin_define ("__GLIBC__"); \ <tschwinge> builtin_define_std ("unix"); \ <tschwinge> builtin_assert ("system=unix"); \ <tschwinge> builtin_assert ("system=posix"); \ <tschwinge> } \ <tschwinge> while (0) <tschwinge> I might raise this upstream at some point. <pinotree> tschwinge: i could guess the change was proposed by the kfreebsd people, so asking them before at d-bsd@d.o would be a start <tschwinge> pinotree: Ack. <pinotree> especially that they would need to fix stuff afterwards <pinotree> imho we could propose them the change, and if they agree put that as local patch to debian's gcc4.6/.7 after wheezy, so there is plenty of time for them to fix stuff <pinotree> what should be done first is, however, find out why that define has been added to gcc[low] Does
-mcpu=nativeetc. work? (For example, 2ae1f0cc764e998bfc684d662aba0497e8723e52.)transactional memory, 4c0315d05fa0f707875686abc4f91f7a979a7c7b
config/mmap.m4In
libitm/config/, is the generic stuff (tls.h, etc.) enough for us?f29a2041f32773464e226a83f41762c2e9cf658e (e53a96c2136f7cdff4699475fea41afeed9dece3)
Testresults same as for GNU/Linux.
[high] 3efc00f6f17778172d3fa7ac737fa1473b3b4d5a,
Check __GLIBC__ when using __SIGRTMIN. GCC PR52390. Fixed by 8d2259c83f94c082ad8a00b5d00bb639ce24efce.15ac1e637ad0cb92bf7629205c617ea847a4b810
Build 64-bit libffi multilib for i?86-linux.libstdc++: uses_GLIBCXX_HAVE_TLS, but where is this defined? Supposed to come fromconfig/tls.m4:GCC_CHECK_TLS?libgcc/gthr-posix.h:__gthread_active_p-- is this suitable for us? This is used in libgcc for ObjC wrapper stuff and similar in libstdc++. C.f.id:"x57jobtqx89w.fsf@frobland.mtv.corp.google.com",id:"x57jd359fkx3.fsf@frobland.mtv.corp.google.com"as well as Debian bug #629866/id:"20110609002620.GA16719@const.famille.thibault.fr". commit 026e608ecebcb2a6193971006a85276307d79b00.549e2197b118efb2d947aaa15d445b05c1b5ed62
Import the asan runtime library into GCC tree. Linux-specific things:ASAN_USE_ALIAS_ATTRIBUTE_FOR_INDEX,ASAN_LINUX,ASAN_POSIX,libsanitizer/asan/asan_linux.cc,libsanitizer/asan/asan_malloc_linux.cc,libsanitizer/asan/asan_posix.cc,libsanitizer/interception/interception.h,libsanitizer/interception/interception_linux.cc,libsanitizer/interception/interception_linux.h,libsanitizer/sanitizer_common/sanitizer_allocator.cc,libsanitizer/sanitizer_common/sanitizer_linux.cc,libsanitizer/sanitizer_common/sanitizer_posix.cc,libsanitizer/sanitizer_common/sanitizer_procmaps.h,libsanitizer/sanitizer_common/sanitizer_symbolizer_linux.cc. 4afab99bf0fe2d6905a9fa9d6ab886ca102312dfEnable libsanitizer just on x86 linux for now. 492e75a7336b4dbfe38207ea3abf8d5bd72376a9Move libsanitizer configure logic to subdirectory. 6aea389d84c2172668af5f108e2b17e131120d0bAdd STATIC_LIBASAN_LIBS for -static-libasan. Further commits later on.- 9cf754572854d9d9cd43c277eb7afb12e4911358
Import tsan runtime from llvm. Linux-specific things:libsanitizer/tsan/tsan_platform.h,libsanitizer/tsan/tsan_platform_linux.cc,libsanitizer/tsan/tsan_symbolize_addr2line_linux.cc. a96132f29aa3dfe94141a87537f62ea73ce0fc19Set TSAN_SUPPORTED=yes for x86_64/i686-linux for 64-bit multilib. Further commits later on.
- 9cf754572854d9d9cd43c277eb7afb12e4911358
Build
Here's a log of a GCC build run; this is from our Git repository's 06a4535f69cf9613943fd12f97fe94e471dedcce (2013-02-18; 71cfadefb994de9249449fb7e71be012b6264a3f (2013-02-17)) sources, run on kepler.SCHWINGE and coulomb.SCHWINGE.
$ export LC_ALL=C
$ (cd ../master/ && contrib/gcc_update --touch)
$ ../master/configure --prefix="$PWD".install SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 --enable-languages=all,ada 2>&1 | tee log_build
[...]
$ make 2>&1 | tee log_build_
[...]
Different hosts may default to different shells and compiler versions; thus harmonized.
We're stuck with GCC 4.6 until there are Debian gnat-4.7 packages avaible.
This takes up around 3.5 GiB, and needs roughly 3.25 h on kepler.SCHWINGE and 14.25 h on coulomb.SCHWINGE.
Analysis
$ toolchain/logs/process gcc build
checking if gcc static flag -static works... noAddressed in Debian glibc.
host-linux.cvs.host-default.cfixincludes stuff
malloc?
-cat ../../hurd/gcc/config/i386/pmm_malloc.h > mm_malloc.h +cat ../../hurd/gcc/config/i386/gmm_malloc.h > mm_malloc.hComes from
gcc/config.gcc:i386/t-pmm_mallocvs.i386/t-gmm_mallocfori[34567]86-*-linux*vs.i[34567]86-*-*.libgomp
libgomp/config/linux/,libgomp/config/linux/x86
seded away.-ftls-model=initial-exec -march=i486 -mtune=i686
seded away.Missing
EOWNERDEAD,ENOTRECOVERABLE. What're they used for?RLIMIT_VMEM. Usage kosher?libtool: link: ar rc .libs/libstdc++.a [...]Just different order of object files, or another problem? TODO
libobjc/encoding.c:libtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] [...]/hurd/master/libobjc/encoding.c -c [...] +[...]/hurd/master/libobjc/encoding.c:128:1: warning: '_darwin_rs6000_special_round_type_align' defined but not used [-Wunused-function]libobjc/thr.c:gcc/gthr-posix.hlibtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] [...]/hurd/master/libobjc/thr.c -c [...] +In file included from [...]/hurd/master/libobjc/../libgcc/gthr.h:142:0, + from [...]/hurd/master/libobjc/thr.c:45: +../libgcc/gthr-default.h: In function '__gthread_objc_thread_set_priority': +../libgcc/gthr-default.h:388:41: warning: unused parameter 'priority' [-Wunused-parameter]/proc/self/*-checking for /proc/self/exe... yes -checking for /proc/self/maps... yes +checking for /proc/self/exe... no +checking for /proc/self/maps... noGCJ:
java-signal.h,java-signal-aux.h-config.status: linking ../../../hurd/libjava/include/i386-signal.h to include/java-signal.h -config.status: linking ../../../hurd/libjava/include/i386-signal.h to include/java-signal-aux.h +config.status: linking ../../../hurd/libjava/include/default-signal.h to include/java-signal.h +config.status: linking ../../../hurd/libjava/include/default-signal.h to include/java-signal-aux.hGCJ:
jni_md.h-checking jni_md.h support... yes +checking jni_md.h support... configure: WARNING: nodefault library search path
-checking for the default library search path... /lib /usr/lib /lib/i386-linux-gnu /usr/lib/i386-linux-gnu /lib/i486-linux-gnu /usr/lib/i486-linux-gnu /usr/local/lib +checking for the default library search path... /lib /usr/libbinutils issue? Should be aligned by Samuel's binutils patch.
./classpath/[...]/*.propertiesJust different order of files, or another problem?
libjava/gnu/gcj/util/natGCInfo.cclibtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] -c ../../../master/libjava/gnu/gcj/util/natGCInfo.cc [...] +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:440:1: warning: unused parameter 'name' [-Wunused-parameter] +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:446:1: warning: unused parameter 'name' [-Wunused-parameter] +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:452:1: warning: unused parameter 'name' [-Wunused-parameter]libgcj.laJust different order of object files, or another problem?
Is there a pattern that GNU/Hurd hands out the files alphabetically sorted where it wouldn't need to (open issue hurd)?
libjvm.la,.libs/libjvm.so,libgij.la,.libs/libgij.so.12.0.0-Wl,-Bsymbolicvs.-Wl,-Bsymbolic-functionsjarmake[2]: Entering directory `[...]/hurd/master.build/[ARCH]/libjava' -: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=[...]/hurd/master.build/[ARCH]/libjava/scripts/jar" DO=all multi-do +: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=jar" DO=all multi-doProbably because kepler.SCHWINGE has an OpenJDK
/usr/bin/jar, and coulomb.SCHWINGE a GCJ one.There are other instances of this in the following.
value-unwind.h-DEFINES='' HEADERS='../../../master/libgcc/config/i386/value-unwind.h' \ +DEFINES='' HEADERS='' \ ../../../master/libgcc/mkheader.sh > tmp-libgcc_tm.hComes from
gcc/config.gcc: fori[34567]86-*-linux*vs.i[34567]86-*-*, but apparently is important only for x86_64 anyway.soft-fpprototypes../../../master/libgcc/soft-fp/eqtf2.c:34:9: warning: no previous prototype for '__eqtf2' [-Wmissing-prototypes] +../../../master/libgcc/soft-fp/eqtf2.c:50:1: warning: no previous prototype for '__netf2' [-Wmissing-prototypes] ../../../master/libgcc/soft-fp/getf2.c:34:9: warning: no previous prototype for '__getf2' [-Wmissing-prototypes] +../../../master/libgcc/soft-fp/getf2.c:50:1: warning: no previous prototype for '__gttf2' [-Wmissing-prototypes] ../../../master/libgcc/soft-fp/letf2.c:34:9: warning: no previous prototype for '__letf2' [-Wmissing-prototypes] +../../../master/libgcc/soft-fp/letf2.c:50:1: warning: no previous prototype for '__lttf2' [-Wmissing-prototypes]libatomicon GNU/Linux compiles several more files than on GNU/Hurd. Is that correct? Probably futex support.2e2db3f92b534460c68c2f9ae64455884424beb6..3336556d2cb32f46322922a83015f760cfb79d8f
Both GNU/Linux and GNU/Hurd:
-checking assembler for rep and lock prefix... yes +checking assembler for rep and lock prefix... noTODO.
Install
$ make install 2>&1 | tee log_install
[...]
This takes up around 1 GiB, and needs roughly 5 min on kepler.SCHWINGE and 37 min on coulomb.SCHWINGE.
Analysis
$ toolchain/logs/process gcc install
libtool: finish:ldconfigis not run for the Hurd.libjvm.la,.libs/libjvm.so,libgij.la,.libs/libgij.so.12.0.0-Wl,-Bsymbolicvs.-Wl,-Bsymbolic-functions(as above)jar: as above.
Testsuite
http://gcc.gnu.org/install/test.html
Testing on GNU/Hurd is blocked on fork mach port mod refs ekern urefs owerflow.
TODO. On GNU/Hurd, it is advisable to reboot after having built and installed
GCC, before running the testsuite, as otherwise there seems to be a tendency
that the system crashes during the gcc.c-torture/compile/limits-structnest.c
tests, which are rather memory hungry, see id:"87bol6aixd.fsf@schwinge.name". Likewise, it also seems advisable to add
further reboots in between, that is, separate make check's check-host into
several separate runs, and then one for check-target (see
[build]/Makefile:do-check, [build]/gcc/Makefile:CHECK_TARGETS), as
otherwise there seems to be a tendency for the system crashing sooner or later.
(Running check-host accumulates to something like 44 hours worth of
forking/execing of GCC and testcases.) On GNU/Linux we run it in one go, so
that we'll catch any fundamental rearrangements of/additions to the testsuites.
kepler.SCHWINGE:
$ make -k check 2>&1 | tee log_test
[...]
coulomb.SCHWINGE:
$ awk '/^maybe-check-target/ { next; }; /^maybe-check-[^:]*:./ { print; };' < Makefile
maybe-check-fixincludes: check-fixincludes
maybe-check-gcc: check-gcc
maybe-check-intl: check-intl
maybe-check-libbacktrace: check-libbacktrace
maybe-check-libcpp: check-libcpp
maybe-check-libdecnumber: check-libdecnumber
maybe-check-libiberty: check-libiberty
maybe-check-zlib: check-zlib
maybe-check-gnattools: check-gnattools
maybe-check-lto-plugin: check-lto-plugin
$ grep ^CHECK_TARGETS gcc/Makefile
CHECK_TARGETS = check-ada check-c check-c++ check-fortran check-java check-lto check-objc
$ export LC_ALL=C
[reboot]
$ make -k check-fixincludes 2>&1 | tee log_test_1_check-fixincludes
[...]
$ make -k -C gcc check-ada 2>&1 | tee log_test_2_gcc_check-ada
[...]
[reboot]
$ make -k -C gcc check-c 2>&1 | tee log_test_2_gcc_check-c
[...]
[reboot]
$ make -k -C gcc check-c++ 2>&1 | tee log_test_2_gcc_check-c++
[...]
[reboot]
$ make -k -C gcc check-fortran check-java check-lto check-objc 2>&1 | tee log_test_2_gcc_check-fortran,check-java,check-lto,check-objc
[...]
[reboot]
$ make -k check-intl check-libbacktrace check-libcpp check-libdecnumber check-libiberty check-zlib check-gnattools check-lto-plugin 2>&1 | tee log_test_3
[...]
$ make -k check-target 2>&1 | tee log_test_4_check-target
[...]
This needs roughly 7 h on kepler.SCHWINGE and 3.5 h (check-fixincludes,
gcc/check-ada) + 13 h (gcc/check-c) + 4.25 h (gcc/check-c++) + 5.75 h
(gcc/check-fortran, gcc/check-java, gcc/check-lto, gcc/check-objc) +
9.25 h (check-intl, [...], check-lto-plugin, check-target) = 35.75 h on
coulomb.SCHWINGE.
Analysis
$ toolchain/logs/process gcc test
PTYs
Occasionally tests FAIL due to:
spawn -open -1 failed, 1 5, The system has no more ptys. Ask your system administrator to create more.TODO.
As of b401cb7ed15602d244a6807835b0b9d740a302a8 (2012-11-26; 769bf18a20ee2540ca7601cdafabd62b18b9751b (2012-10-01)), all
gcc.dg/gualityandg++.dg/gualityand a few more are no longer tested on coulomb.SCHWINGE and kepler.SCHWINGE.As of b401cb7ed15602d244a6807835b0b9d740a302a8 (2012-11-26; 769bf18a20ee2540ca7601cdafabd62b18b9751b (2012-10-01)), there are regressions (FAILs) in libgomp execution tests on coulomb.SCHWINGE.
769bf18a20ee2540ca7601cdafabd62b18b9751b..be3860ba8df48cca3253da4f02fd2d42d856ce80
On GNU/Hurd:
Running [...]/hurd/master/gcc/testsuite/g++.dg/tls/tls.exp ... +FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 execution test +FAIL: g++.dg/tls/thread_local3g.C -std=gnu++11 execution test +FAIL: g++.dg/tls/thread_local4.C -std=gnu++11 execution test +FAIL: g++.dg/tls/thread_local4g.C -std=gnu++11 execution test +FAIL: g++.dg/tls/thread_local5.C -std=gnu++11 execution test +FAIL: g++.dg/tls/thread_local5g.C -std=gnu++11 execution testThey used to PASS.
What is
gcc/testsuite/gcc.test-framework/test-framework.expand should we defineCHECK_TEST_FRAMEWORKto run these tests?TODO
Enhancements
contrib/testsuite-management/, contrib/regression/
- 35a27ee8c4b349fea44fd1fadc9614ab3cc9d578
Add an xfail manifest for x86_64-unknown-linux-gnu to trunk.
Parallel Testing
id:"20110331070322.GI11563@sunsite.ms.mff.cuni.cz".
Distributed Testing
IRC, OFTC, #gcc, 2012-05-31
<dnovillo> jsm28: in your mentor testing, you have the source and build
tree available for make check? or it's a pure installed-tree test?
<jsm28> dnovillo: Source tree, install tree, no build tree.
<dnovillo> jsm28: so, you run make check on top of the source tree or copy
the */testsuite trees to a testing area?
<jsm28> Create a site.exp and do runtest in a temporary directory. runtest
is pointed to the source tree to find sources.
<jsm28> For cross testing for GNU/Linux targets, the temporary directory is
mounted at the same path on host and target.
<dnovillo> jsm28: thanks. i guess i'll have to find the slice of the
source tree i need to copy.
<dnovillo> jsm28: for libstdc++ do you write a different site.exp?
<dnovillo> i noticed that it generates a different site,exp there.
<jsm28> The site.exp is mostly the same for all testsuites (so includes
settings that only some testsuites use).
<dnovillo> ok, thanks.
<dnovillo> and when you say "pointed to the source tree" you mean "set
srcdir /path/to/top/of/gcc" ?
<dnovillo> (in site.exp)
<jsm28> The GDB testsuite requires that you run the GDB testsuite's
configure script in the temporary directory where you will run runtest.
I don't think any GCC testsuites we use have requirements like that.
<jsm28> dnovillo: --srcdir option to runtest.
<dnovillo> ah, yes.
<jsm28> (and --tool, --target_board etc.)
<dnovillo> right
<dnovillo> since i'm distributing the tests. i want each node to only do a
bunch of files. this means that i either use 'tool.exp=file-pattern' or
simply copy the subset of files i want tool.exp to find.
<dnovillo> i chose the second approach, but that breaks in a handful of
cases that need files from other sub-directories.
<dnovillo> like g++.dg gcc.dg using stuff from c-c++-common.
<dnovillo> for libstdc++, the possibilities for splitting are enormous as
it has many directories.
<dnovillo> but i'm not setting it right. runtest runs without even trying
to test anything.
<dnovillo> i'm not having it pick up the right driver.
<jsm28> Probably all .exp files should be copied to anywhere running
testsuites, since some read .exp files from other directories.
<dnovillo> jsm28: that could be it too. it's irritating that libstdc++
does not even error out. runtest just does nothing and returns 0.
IRC, OFTC, #gcc, 2012-06-06
<dnovillo> any libstdc++ maintainer around?
<dnovillo> or, does anyone know when the testsuite/data files are copied
into the running testsuite/ dir?
<dnovillo> seems to be done in advance by make.