Problem building sh-elf cross gcc under Cygwin

[Michael Beach <michaelb at ieee dot 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@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 <URL:http://www.gnu.org/software/gcc/bugs.html> 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 <Address 0x7e0 out of 
bounds>, 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/