Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: Michael Beach To: cygwin AT cygwin DOT com Subject: Problem building sh-elf cross gcc under Cygwin Date: Tue, 4 Nov 2003 16:44:01 +1100 User-Agent: KMail/1.5.4 Cc: gcc AT gcc DOT gnu DOT org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311041644.01462.michaelb@ieee.org> Hi all, I'm currently experiencing a problem with building a cross compiler from Cygwin to sh-elf. In particular, I'm trying to build gcc-3.2.1 I'm building in a separate directory, and am configuring it like so... michaelb AT enkidu /work/stuff/sh_gcc_build $ ../gcc-3.2.1/configure --prefix=/work/stuff/sh_gcc_install --target=sh-elf --enable-languages=c --with-as=/work/stuff/sh_binutils_install/bin/sh-elf-as --with-ld=/work/stuff/sh_binutils_install/bin/sh-elf-ld --with-newlib This all seems to go fine, but after running make, it seems to crap out while building the newlib math library stuff... /work/stuff/sh_gcc_build/gcc/xgcc -B/work/stuff/sh_gcc_build/gcc/ -nostdinc -B/work/stuff/sh_gcc_build/sh-elf/ml/newlib/ -isystem /work/stuff/sh_gcc_build/sh-elf/ml/newlib/targ-include -isystem /work/stuff/gcc-3.2.1/newlib/libc/include -B/work/stuff/sh_gcc_install/sh-elf/bin/ -B/work/stuff/sh_gcc_install/sh-elf/lib/ -isystem /work/stuff/sh_gcc_install/sh-elf/include -ml -DPACKAGE=\"newlib\" -DVERSION=\"1.11.0\" -I. -I../../../../../../gcc-3.2.1/newlib/libm/math -I../../../../../../gcc-3.2.1/newlib/libm/math/../common -O2 -DHAVE_GETTIMEOFDAY -DWANT_PRINTF_LONG_LONG -fno-builtin -O2 -g -O2 -ml -c ../../../../../../gcc-3.2.1/newlib/libm/math/er_lgamma.c ../../../../../../gcc-3.2.1/newlib/libm/math/er_lgamma.c: In function `__ieee754_lgamma_r': ../../../../../../gcc-3.2.1/newlib/libm/math/er_lgamma.c:309: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make[7]: *** [er_lgamma.o] Error 1 make[7]: Leaving directory `/work/stuff/sh_gcc_build/sh-elf/ml/newlib/libm/math' make[6]: *** [all-recursive] Error 1 make[6]: Leaving directory `/work/stuff/sh_gcc_build/sh-elf/ml/newlib/libm' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/work/stuff/sh_gcc_build/sh-elf/ml/newlib' make[4]: *** [all-recursive-am] Error 2 make[4]: Leaving directory `/work/stuff/sh_gcc_build/sh-elf/ml/newlib' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/work/stuff/sh_gcc_build/sh-elf/newlib' make[2]: *** [all-multi] Error 2 make[2]: Leaving directory `/work/stuff/sh_gcc_build/sh-elf/newlib' make[1]: *** [all-recursive-am] Error 2 make[1]: Leaving directory `/work/stuff/sh_gcc_build/sh-elf/newlib' make: *** [all-target-newlib] Error 2 This occurs when I'm using version 1.5.5 of the Cygwin DLL (with the cygwin supplied 3.3.1 native gcc), but not when I'm using 1.3.22 (with the cygwin supplied 3.2 native gcc). Nor does it occur (for what it's worth) when I'm attempting to build the cross compiler on a Linux host. I've tried with 2.3.2, 3.3.1 and 3.3.2 native compilers. Building the gcc-3.2.1 sh-elf cross compiler succeeds in each of these cases. Thus I'm thinking that it's a Cygwin issue that I'm running into here, but of course for all I know it could be just a latent gcc 3.2.1 bug that is now being tickled. Note that I'm reluctant to switch away from gcc 3.2.1 because that is what the eCOS folks recommend for building eCOS (which is ultimately what I want to do). After doing some more digging it turns out that the actual segfault occurs in cc1, and it's being run like this... /work/stuff/sh_gcc_build/gcc/xgcc -v -B/work/stuff/sh_gcc_build/gcc/ -nostdinc -B/work/stuff/sh_gcc_build/sh-elf/ml/newlib/ -isystem /work/stuff/sh_gcc_build/sh-elf/ml/newlib/targ-include -isystem /work/stuff/gcc-3.2.1/newlib/libc/include -B/work/stuff/sh_gcc_install/sh-elf/bin/ -B/work/stuff/sh_gcc_install/sh-elf/lib/ -isystem /work/stuff/sh_gcc_install/sh-elf/include -ml -DPACKAGE=\"newlib\" -DVERSION=\"1.11.0\" -I. -I../../../../../../gcc-3.2.1/newlib/libm/math -I../../../../../../gcc-3.2.1/newlib/libm/math/../common -O2 -DHAVE_GETTIMEOFDAY -DWANT_PRINTF_LONG_LONG -fno-builtin -O2 -g -O2 -ml -c ../../../../../../gcc-3.2.1/newlib/libm/math/er_lgamma.c Running this under gdb shows that the segfault occurs somewhere in gcc's garbage collection code... Program received signal SIGSEGV, Segmentation fault. ggc_mark_rtx_children (r=0x1431700) at /work/PrinterGroupSoftware_win32/07-printers/01-printer_general/04-software_modules/08-gnu_tools/gcc-3.2.1/gcc/ggc-common.c:299 299 for (i = NEXT_INSN (r); ; i = NEXT_INSN (i)) (gdb) bt #0 ggc_mark_rtx_children (r=0x1431700) at /work/PrinterGroupSoftware_win32/07-printers/01-printer_general/04-software_modules/08-gnu_tools/gcc-3.2.1/gcc/ggc-common.c:299 #1 0x004aee71 in ggc_mark_rtx_children_1 (r=0x1431480) at /work/PrinterGroupSoftware_win32/07-printers/01-printer_general/04-software_modules/08-gnu_tools/gcc-3.2.1/gcc/ggc-common.c:394 #2 0x004af018 in ggc_mark_rtvec_children (v=0x142b8f0) at /work/PrinterGroupSoftware_win32/07-printers/01-printer_general/04-software_modules/08-gnu_tools/gcc-3.2.1/gcc/ggc-common.c:418 #3 0x004aee3f in ggc_mark_rtx_children_1 (r=0x14329a8) at /work/PrinterGroupSoftware_win32/07-printers/01-printer_general/04-software_modules/08-gnu_tools/gcc-3.2.1/gcc/ggc-common.c:398 #4 0x004aee71 in ggc_mark_rtx_children_1 (r=0x1284240) at /work/PrinterGroupSoftware_win32/07-printers/01-printer_general/04-software_modules/08-gnu_tools/gcc-3.2.1/gcc/ggc-common.c:394 #5 0x004aebc6 in ggc_mark_roots () at /work/PrinterGroupSoftware_win32/07-printers/01-printer_general/04-software_modules/08-gnu_tools/gcc-3.2.1/gcc/ggc-common.c:256 #6 0x004adfdb in ggc_collect () at /work/PrinterGroupSoftware_win32/07-printers/01-printer_general/04-software_modules/08-gnu_tools/gcc-3.2.1/gcc/ggc-page.c:1429 #7 0x0045e475 in rest_of_compilation (decl=0x1258700) at /work/PrinterGroupSoftware_win32/07-printers/01-printer_general/04-software_modules/08-gnu_tools/gcc-3.2.1/gcc/toplev.c:3440 #8 0x00421143 in c_expand_body (fndecl=0x1258700, nested_p=0, can_defer_p=1) at /work/PrinterGroupSoftware_win32/07-printers/01-printer_general/04-software_modules/08-gnu_tools/gcc-3.2.1/gcc/c-decl.c:7104 #9 0x00420e37 in finish_function (nested=0, can_defer_p=1) at /work/PrinterGroupSoftware_win32/07-printers/01-printer_general/04-software_modules/08-gnu_tools/gcc-3.2.1/gcc/c-decl.c:6971 #10 0x00409f78 in yyparse_1 () at c-parse.y:358 #11 0x00000001 in ?? () (gdb) It seems that when we try to find the rtx that corresponds to the instruction after r (which is at address 0x1431700) we experience the segfault. If we look at r we have... (gdb) p *r $1 = {code = JUMP_INSN, mode = VOIDmode, jump = 0, call = 0, unchanging = 0, volatil = 0, in_struct = 0, used = 0, integrated = 0, frame_related = 0, fld = {{rtwint = 2016, rtint = 2016, rtuint = 2016, rtstr = 0x7e0
, rtx = 0x7e0, rtvec = 0x7e0, rttype = 2016, rt_addr_diff_vec_flags = {min_align = 224, base_after_vec = 1, min_after_vec = 1, max_after_vec = 1, min_after_base = 0, max_after_base = 0, offset_unsigned = 0, 0, scale = 0}, rt_cselib = 0x7e0, rtbit = 0x7e0, rttree = 0x7e0, bb = 0x7e0, rtmem = 0x7e0}}} (gdb) Now I know almost nothing about gcc internals, but I did manage to figure out (grubbing through various headers etc) that getting to the next instruction a la NEXT_INSN(r) is done by following the rtx field of that struct. The rtx field has the suspicious looking value 0x7e0, and since it's a member of a union I suspect that we're just getting a little confused here as to what is stored in our union. I apologise for the vague nature of this, but I'm at a bit of a loss as to what would constitute useful information in this case. So anything from a complete solution down to just a few tips or pointers as to what to check next would be greatly appreciated. Thanks! Regards M.Beach -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/