[See https://lists.freebsd.org/pipermail/freebsd-stable/2016-October/086125.html for more supporting details.] While trying to build lang/gcc6 on a BPI-M3 (Cortex-A7, ALLWINNER) I got "xgcc: internal compiler error: Bad system call (program cc1)", which means a SIGSYS (signal 12) resulted. [I will note that I'v never seen this issue (so far) on the rpi2: This may be KERNCONF=ALLWINNER specific. But I've not yet updated to -r307797 on the rpi2. The BPI-M3 context is new for me; the rpi2 I've been using for a long time.] This was under/on: root@bananapi-m3:/usr/ports # uname -apKU FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon Oct 24 00:41:16 PDT 2016 markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALLWINNER arm armv6 1100505 1100505 [Note this was cross-built and then a matching svnlite co was done on the BPi-M3. So the source timestamps on the BPi-M3 are newer than the times from the cross build.] root@bananapi-m3:/usr/ports # svnlite info /usr/ports/ | grep "Re[lv]" Relative URL: ^/head Revision: 424540 Last Changed Rev: 424540 dmesg | tail shows: pid 29581 (cc1), uid 0: exited on signal 12 (core dumped) pid 29613 (cc1), uid 0: exited on signal 12 (core dumped) pid 29622 (cc1), uid 0: exited on signal 12 (core dumped) pid 29651 (cc1), uid 0: exited on signal 12 (core dumped) pid 29660 (cc1), uid 0: exited on signal 12 (core dumped) pid 29798 (cc1), uid 0: exited on signal 12 (core dumped) pid 30422 (cc1), uid 0: exited on signal 12 (core dumped) pid 30426 (cc1), uid 0: exited on signal 12 (core dumped) pid 30428 (cc1), uid 0: exited on signal 12 (core dumped) pid 30431 (cc1), uid 0: exited on signal 12 (core dumped) (All the lang/gcc6 prerequisites built okay on the BPi-M3.) Unfortunately direct execution of the cc1 command on the libgcc2.i from a use of -save-temps does not fail. For some reason the failure is only when xgcc causes the cc1 command execution. Also unfortunately truss gets a segmentation fault of its own trying the handle watching the SIGSYS related activity. (A truss bugzilla report has been made.) Thus the following tail of the truss output for leading up to the SIGSYS does not cover the SIGSYS related activity itself: root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-portbld-freebsd11.0/libgcc # tail truss.log 31183 100086: close(3) = 0 (0x0) 31183 100086: openat(AT_FDCWD,"/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/longlong.h",O_NOCTTY,00) ERR#2 'No such file or directory' 31183 100086: openat(AT_FDCWD,"./longlong.h",O_NOCTTY,00) ERR#2 'No such file or directory' 31183 100086: openat(AT_FDCWD,"../.././gcc/longlong.h",O_NOCTTY,00) ERR#2 'No such file or directory' 31183 100086: openat(AT_FDCWD,"/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc/longlong.h",O_NOCTTY,00) ERR#2 'No such file or directory' 31183 100086: openat(AT_FDCWD,"/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include/longlong.h",O_NOCTTY,00) = 3 (0x3) 31183 100086: fstat(3,{ mode=-rw-r--r-- ,inode=573594,size=61185,blksize=32768 }) = 0 (0x0) 31183 100086: read(3,"/* longlong.h -- definitions for"...,61185) = 61185 (0xef01) 31183 100086: close(3) = 0 (0x0) 31183 100086: mmap(0x0,16384,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,16384,0x100000000) Via using gdb on truss [with truss running xgcc and xgcc in turn running its cc1 instance]: root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-portbld-freebsd11.0/libgcc # gdb truss . . . [the below is in enter_syscall] . . . 380 t->cs.name = sysdecode_syscallname(t->proc->abi->abi, t->cs.number); 381 if (t->cs.name == NULL) (gdb) 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d --\n", 383 t->proc->abi->type, t->cs.number); 384 385 sc = get_syscall(t->cs.name, narg); 386 t->cs.nargs = sc->nargs; 387 assert(sc->nargs <= nitems(t->cs.s_args)); 388 389 t->cs.sc = sc; (t->cs.name == NULL after line 380). . . Looking at the two things that the fprintf on lines 382 and 383 would report: (gdb) print t->proc->abi->type $4 = 0x10166 "FreeBSD ELF32" (gdb) print t->cs.number $5 = 580828064 FYI: 580828064 = 0x229EBBA0 (sc == NULL results from line 385 so sc->nargs on line 386 gets a SIGSEGV.) Just for completness: (gdb) print *t $2 = {entries = {le_next = 0x0, le_prev = 0x20617070}, proc = 0x20617060, tid = 100150, in_syscall = 1, cs = {sc = 0x0, name = 0x0, number = 580828064, args = 0x2061b0c0, nargs = 0, s_args = 0x2061b0ec}, before = {tv_sec = 1477418265, tv_nsec = 492342263}, after = {tv_sec = 1477418265, tv_nsec = 492496630}} (gdb) print sc $3 = (struct syscall *) 0x0
(In reply to Mark Millard from comment #0) ktrace -i -t sc and kdump report: . . . 32098 cc1 CALL sigaction(SIGSEGV,0xbfbfdee8,0xbfbfded0) 32098 cc1 RET sigaction 0 32098 cc1 CALL sigaction(SIGILL,0xbfbfdee8,0xbfbfded0) 32098 cc1 RET sigaction 0 32098 cc1 CALL sigaction(SIGBUS,0xbfbfdee8,0xbfbfded0) 32098 cc1 RET sigaction 0 32098 cc1 CALL sigaction(SIGIOT,0xbfbfdee8,0xbfbfded0) 32098 cc1 RET sigaction 0 32098 cc1 CALL sigaction(SIGFPE,0xbfbfdee8,0xbfbfded0) 32098 cc1 RET sigaction 0 32098 cc1 CALL mmap(0,0x1000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,0xffffffff,0xbfbfe018,0,0) 32098 cc1 RET mmap 565104640/0x21aed000 32099 as CALL mmap(0,0x200000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,0xffffffff,0xd827524,0,0) 32099 as RET mmap 553648128/0x21000000 32098 cc1 CALL mmap(0,0x200000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,0xffffffff,0xbfbfde80,0,0) 32098 cc1 RET mmap 574619648/0x22400000 32098 cc1 CALL mmap(0,0x2000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,0xffffffff,0x2220c000,0,0) 32098 cc1 RET mmap 565108736/0x21aee000 32099 as CALL getuid 32099 as RET getuid 0 32099 as CALL geteuid 32099 as RET geteuid 0 32099 as CALL getgid 32099 as RET getgid 0 32099 as CALL getegid 32099 as RET getegid 0 32099 as CALL fstat(0,0xbfbfe0c8) 32099 as RET fstat 0 32099 as CALL read(0,0x20df5000,0x1000) 32098 cc1 CALL ioctl(0x2,TIOCGETA,0xbfbfdee4) 32098 cc1 RET ioctl 0 . . . . . . [note the last "as" action above is a read] . . . . . . 32098 cc1 CALL openat(AT_FDCWD,0x22248c30,0x8000<O_NOCTTY>,<unused>0) 32098 cc1 RET openat -1 errno 2 No such file or directory 32098 cc1 CALL openat(AT_FDCWD,0x2230d710,0x8000<O_NOCTTY>,<unused>0) 32098 cc1 RET openat -1 errno 2 No such file or directory 32098 cc1 CALL openat(AT_FDCWD,0x22245fc0,0x8000<O_NOCTTY>,<unused>0) 32098 cc1 RET openat -1 errno 2 No such file or directory 32098 cc1 CALL openat(AT_FDCWD,0x22248c80,0x8000<O_NOCTTY>,<unused>0) 32098 cc1 RET openat -1 errno 2 No such file or directory 32098 cc1 CALL openat(AT_FDCWD,0x222918c0,0x8000<O_NOCTTY>,<unused>0) 32098 cc1 RET openat 3 32098 cc1 CALL fstat(0x3,0x2228c1a8) 32098 cc1 RET fstat 0 32098 cc1 CALL read(0x3,0x2239abc0,0xef01) 32098 cc1 RET read 61185/0xef01 32098 cc1 CALL close(0x3) 32098 cc1 RET close 0 32098 cc1 CALL mmap(0,0x4000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,0xffffffff,0x1c,0,0) 32098 cc1 RET mmap 568225792/0x21de7000 32098 cc1 CALL [-17504] 32098 cc1 RET [-17504] -1 errno 78 Function not implemented 32099 as RET read 0 32099 as CALL close(0) 32099 as RET close 0 32099 as CALL fstat(0x3,0xbfbfde28) 32099 as RET fstat 0 32099 as CALL lseek(0x3,0x209423bc,<invalid=176>,0,0,0x2097b278) 32099 as RET lseek 176/0xb0 32099 as CALL write(0x3,0x20fb4480,0x1) 32099 as RET write 1 32099 as CALL lseek(0x3,0x209423bc,<invalid=52>,0,0,0x2097b278) 32099 as RET lseek 52/0x34 32099 as CALL write(0x3,0x20fb4480,0x2b) 32098 cc1 PSIG SIGSYS SIG_DFL code=SI_KERNEL . . . -17504 as 2's complement is: 0xF...FBBA0
(In reply to Mark Millard from comment #0) Where the failure occurs in the overall execution moves around as I try debugging. But the lr and pc end up with the same bad values each time. And lr's bad value is a copy of r3's value. And pc looks like it might be a stack address for its bad value. Program received signal SIGSYS, Bad system call. 0xbfbf6d4c in ?? () (gdb) x/i $pc 0xbfbf6d4c A syntax error in expression, near `0xbfbf6d4c'. (gdb) x/i $pc 0xbfbf6d4c: ldrhteq pc, [r0], #-120 (gdb) info reg r0 0x4e 78 r1 0x0 0 r2 0x17c8506 24937734 r3 0x65 101 r4 0xbfbf6ea8 -1077973336 r5 0xbfbf6ea4 -1077973340 r6 0xbfbf6ea8 -1077973336 r7 0x229ebba0 580828064 r8 0x0 0 r9 0xbfbfe164 -1077943964 r10 0xbfbf6ea4 -1077973340 r11 0x0 0 r12 0x17ef3b1 25097137 sp 0xbfbf6ba0 -1077974112 lr 0x65 101 pc 0xbfbf6d4c -1077973684 fps 0x0 0 cpsr 0xa0000010 -1610612720 Here is the last few stepi's (with display/i $pc) that in one case lead to the failure (in __umodsi3): (gdb) 0x0178301c in __udivmoddi4 () 1: x/i $pc 0x178301c <__udivmoddi4+348>: bl 0x1783224 <__umodsi3> (gdb) 0x01783224 in __umodsi3 () 1: x/i $pc 0x1783224 <__umodsi3>: cmp r1, #1 ; 0x1 (gdb) 0x01783228 in __umodsi3 () 1: x/i $pc 0x1783228 <__umodsi3+4>: bcc 0x1783358 <__umodsi3+308> (gdb) 0x0178322c in __umodsi3 () 1: x/i $pc 0x178322c <__umodsi3+8>: moveq r0, #0 ; 0x0 (gdb) 0x01783230 in __umodsi3 () 1: x/i $pc 0x1783230 <__umodsi3+12>: bxeq lr (gdb) 0x01783234 in __umodsi3 () 1: x/i $pc 0x1783234 <__umodsi3+16>: cmp r0, r1 (gdb) 0x01783238 in __umodsi3 () 1: x/i $pc 0x1783238 <__umodsi3+20>: bxcc lr (gdb) Program received signal SIGSYS, Bad system call. 0xbfbf6d4c in ?? () Other times getting to the same step (and beyond) in the overall execution works well --but it does eventually die someplace.
Using ktrace -i -t +fw it looks like every repeat of the problem ends up with the following (up to process numbers), from the mmap to past the odd syscall report, having the user "ast" CSW's between the mmap and the odd syscall report at the same point of the sequence: 34629 cc1 CALL mmap(0,0x4000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,0xffffffff,0x1c,0,0) 34629 cc1 RET mmap 568225792/0x21de7000 34629 cc1 PFLT 0x21de7000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x21de8000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x21de9000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x21dea000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x229e8000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x229e9000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x229ea000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 CSW stop user "ast" 34629 cc1 CSW resume user "ast" 34629 cc1 PFLT 0x229eb000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 PFLT 0x229ec000 VM_PROT_WRITE 34629 cc1 PRET KERN_SUCCESS 34629 cc1 CALL [-17504] 34629 cc1 RET [-17504] -1 errno 78 Function not implemented 34629 cc1 PSIG SIGSYS SIG_DFL code=SI_KERNEL 34629 cc1 NAMI "cc1.core" 34630 as CSW stop kernel "piperd" 34630 as Events dropped. 34630 as RET read 0 34630 as CALL close(0) 34630 as RET close 0 . . .
(In reply to Mark Millard from comment #3) The details do vary some based on the source file being compiled. For example here the user "ast" CSW's are just before the mmap but are still just after the 0x229ea000 PFLT: 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0xbfbf2000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x229e7000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x229e8000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x229e9000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x229ea000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 CSW stop user "ast" 34698 cc1 CSW resume user "ast" 34698 cc1 CALL mmap(0,0x4000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,0xffffffff,0,0,0) 34698 cc1 RET mmap 568225792/0x21de7000 34698 cc1 PFLT 0x21de7000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x21de8000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x21de9000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x21dea000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 PFLT 0x229eb000 VM_PROT_WRITE 34698 cc1 PRET KERN_SUCCESS 34698 cc1 CALL [-25840] 34698 cc1 RET [-25840] -1 errno 78 Function not implemented 34698 cc1 PSIG SIGSYS SIG_DFL code=SI_KERNEL 34698 cc1 NAMI "cc1.core" 34699 as CSW stop kernel "piperd" 34699 as Events dropped. 34699 as RET read 0 34699 as CALL close(0) 34699 as RET close 0 -25840 in 2's complement is: 0xF...F9B10 I'll note that for the source I used initially gdb truss -feH -o truss.log reported: (gdb) print t->cs.number $5 = 580828064 FYI: 580828064 = 0x229EBBA0 And the 229E matched the upper part of local PFLT activity around the user "ast" CSW's, including just before the bad call. Here doing such instead reports: (gdb) print t->cs.number $1 = 580819728 and 580819728 = 0x229E9B10 and the 229E part matches several PFLT's in the area, including just before the bad call as well as just before the user "ast"s. Between there are some PFLT's that do not match.
I built and installed world based on -mcpu=cortex-a7 (my usual way of building) and having /etc/make.conf supply it for CC and CXX as well --and got an example message when running the old xgcc on the example source code (and so indirectly cc1 was in use): /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1: Undefined symbol "__aeabi_uidiv" I'll rebuild without -mcpu=cortex-a7 and see if I can reproduce the original behavior. The command that lead to the above message was: truss -faeH -o truss.log /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/ -B/usr/local/armv6-portbld-freebsd11.0/bin/ -B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem /usr/local/armv6-portbld-freebsd11.0/include -isystem /usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe -mcpu=cortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe -mcpu=cortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -pthread -fno-inline -fomit-frame-pointer -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread -fno-inline -fomit-frame-pointer -I. -I. -I../.././gcc -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/. -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../gcc -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS (I was actually testing/exploring a John Baldwin update to truss for the segfault it was getting.)
(In reply to Mark Millard from comment #5) [More about Undefined symbol "__aeabi_uidiv". . . from a list notice that I sent] I will note that in my "with debug symbols" and -mcpu=cortex-a7 style of buildworld buildkernel type of boot context I got an explicit message in the xgcc/cc1 test that may indicate the original problem for cc1: /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1: Undefined symbol "__aeabi_uidiv" [bugzilla https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213785 ] At this stage in trying to bootstrap lang/gcc6 as the first gcc compiler on the BPi-M3: # ldd /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1 /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/cc1: libmpc.so.3 => /usr/local/lib/libmpc.so.3 (0x21aff000) libmpfr.so.4 => /usr/local/lib/libmpfr.so.4 (0x21b25000) libgmp.so.10 => /usr/local/lib/libgmp.so.10 (0x21bba000) libz.so.6 => /lib/libz.so.6 (0x21c5b000) libc++.so.1 => /usr/lib/libc++.so.1 (0x21c77000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x21d1d000) libm.so.5 => /lib/libm.so.5 (0x21d3f000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x21d62000) libc.so.7 => /lib/libc.so.7 (0x21e00000) So /usr/local/lib/ is not yet providing gcc's own library of primitives for xgcc or cc1 to use and when FreeBSD is missing something like__aeabi_uidiv that xgcc/cc1 expects to use there could then be problems: # ls -l /usr/local/lib total 127288 -r-xr-xr-x 1 root wheel 10168 Oct 25 07:39 bindtextdomain.so drwxr-xr-x 2 root wheel 512 Oct 25 05:57 gettext -rw-r--r-- 1 root wheel 72026 Oct 25 05:40 libasprintf.a lrwxr-xr-x 1 root wheel 20 Oct 25 05:40 libasprintf.so -> libasprintf.so.0.0.0 lrwxr-xr-x 1 root wheel 20 Oct 25 05:40 libasprintf.so.0 -> libasprintf.so.0.0.0 -rwxr-xr-x 1 root wheel 64717 Oct 25 05:40 libasprintf.so.0.0.0 -rw-r--r-- 1 root wheel 58917550 Oct 25 08:52 libbfd.a -rwxr-xr-x 1 root wheel 4421893 Oct 25 05:56 libgettextlib-0.19.8.1.so lrwxr-xr-x 1 root wheel 25 Oct 25 05:56 libgettextlib.so -> libgettextlib-0.19.8.1.so -rw-r--r-- 1 root wheel 1611908 Oct 25 05:56 libgettextpo.a lrwxr-xr-x 1 root wheel 21 Oct 25 05:56 libgettextpo.so -> libgettextpo.so.0.5.4 lrwxr-xr-x 1 root wheel 21 Oct 25 05:56 libgettextpo.so.0 -> libgettextpo.so.0.5.4 -rwxr-xr-x 1 root wheel 1134132 Oct 25 05:56 libgettextpo.so.0.5.4 -rwxr-xr-x 1 root wheel 1005228 Oct 25 05:56 libgettextsrc-0.19.8.1.so lrwxr-xr-x 1 root wheel 25 Oct 25 05:56 libgettextsrc.so -> libgettextsrc-0.19.8.1.so -rw-r--r-- 1 root wheel 2935784 Oct 25 08:01 libgmp.a lrwxr-xr-x 1 root wheel 16 Oct 25 08:01 libgmp.so -> libgmp.so.10.1.3 lrwxr-xr-x 1 root wheel 16 Oct 25 08:01 libgmp.so.10 -> libgmp.so.10.1.3 -rwxr-xr-x 1 root wheel 1709666 Oct 25 08:01 libgmp.so.10.1.3 -rw-r--r-- 1 root wheel 1112250 Oct 25 08:01 libgmpxx.a lrwxr-xr-x 1 root wheel 17 Oct 25 08:01 libgmpxx.so -> libgmpxx.so.4.3.3 lrwxr-xr-x 1 root wheel 17 Oct 25 08:01 libgmpxx.so.4 -> libgmpxx.so.4.3.3 -rwxr-xr-x 1 root wheel 657771 Oct 25 08:01 libgmpxx.so.4.3.3 -rw-r--r-- 1 root wheel 238518 Oct 25 05:40 libintl.a lrwxr-xr-x 1 root wheel 16 Oct 25 05:40 libintl.so -> libintl.so.8.1.5 lrwxr-xr-x 1 root wheel 16 Oct 25 05:40 libintl.so.8 -> libintl.so.8.1.5 -rw-r--r-- 1 root wheel 157207 Oct 25 05:40 libintl.so.8.1.5 lrwxr-xr-x 1 root wheel 12 Oct 25 05:40 libintl.so.9 -> libintl.so.8 -rw-r--r-- 1 root wheel 565968 Oct 25 09:02 libmpc.a lrwxr-xr-x 1 root wheel 15 Oct 25 09:02 libmpc.so -> libmpc.so.3.0.0 lrwxr-xr-x 1 root wheel 15 Oct 25 09:02 libmpc.so.3 -> libmpc.so.3.0.0 -rwxr-xr-x 1 root wheel 346999 Oct 25 09:02 libmpc.so.3.0.0 -rw-r--r-- 1 root wheel 2053300 Oct 25 08:05 libmpfr.a lrwxr-xr-x 1 root wheel 16 Oct 25 08:05 libmpfr.so -> libmpfr.so.4.1.5 lrwxr-xr-x 1 root wheel 16 Oct 25 08:05 libmpfr.so.4 -> libmpfr.so.4.1.5 -rwxr-xr-x 1 root wheel 1294011 Oct 25 08:05 libmpfr.so.4.1.5 -rw-r--r-- 1 root wheel 38488604 Oct 25 08:52 libopcodes.a -rw-r--r-- 1 root wheel 7155654 Oct 25 05:36 libpkg.a lrwxr-xr-x 1 root wheel 15 Oct 25 05:36 libpkg.so -> libpkg.so.3.0.0 lrwxr-xr-x 1 root wheel 15 Oct 25 05:36 libpkg.so.3 -> libpkg.so.3.0.0 -rwxr-xr-x 1 root wheel 5621424 Oct 25 05:36 libpkg.so.3.0.0 drwxr-xr-x 4 root wheel 512 Oct 25 07:37 perl5 Part of the issue may be that unlike my usual procedure for gcc* builds: OPTIONS_FILE_UNSET+=BOOTSTRAP for the BPI-M3 lang/gcc6 build I used: OPTIONS_FILE_SET+=BOOTSTRAP This might explain why I did not see a problem on the rpi2 historically.
(In reply to Mark Millard from comment #6) Comment 6 was wrong in its direction: the crochet buildworld (without my usual -mcpu=cortex-a7 ) does define __aeabi_uidiv (and an alias __udivsi3). (gdb) info shared From To Syms Read Shared Object Library 0x21b01c8c 0x21b1b0e8 Yes /usr/local/lib/libmpc.so.3 0x21b2caa0 0x21ba9d24 Yes /usr/local/lib/libmpfr.so.4 0x21bc2940 0x21c46330 Yes /usr/local/lib/libgmp.so.10 0x21c5b988 0x21c69a74 Yes /lib/libz.so.6 0x21ca5f80 0x21cfe570 Yes /usr/lib/libc++.so.1 0x21d21bf8 0x21d2f234 Yes /lib/libcxxrt.so.1 0x21d416c8 0x21d56378 Yes /lib/libm.so.5 0x21d634b8 0x21d68234 Yes /lib/libgcc_s.so.1 0x21e29448 0x21f437b0 Yes /lib/libc.so.7 0x21ad3180 0x21ae9784 Yes /libexec/ld-elf.so.1 (gdb) break __aeabi_uidiv Breakpoint 2 at 0x21cfe3a0 which puts the routine in: 0x21ca5f80 0x21cfe570 Yes /usr/lib/libc++.so.1
(In reply to Mark Millard from comment #7) I've tracked down a problem with the armv6/cortex-a7 code generated in lang/gcc6's xgcc' cc1 and submitted bugzilla 213934 against lang/gcc6 for it. The history here in bugzilla 213785 is not of much use for the lang/gcc6 issue. (It might be somewhat useful for the truss crash issue that xgcc's cc1 exposed.) So I'm closing this report so that lang/gcc6 has a simpler report with just the actual code generation problem documented. But bugzilla 213778's report for truss's crashing when watching the failing cc1 is still active and John Baldwin has taken at least one stab at fixing that issue. So for now I leave the BPI-M3 environment in the form that allows me to test truss updates: I'm not exploring compiler option variations and such for lang/gcc6.
(In reply to Mark Millard from comment #8) The new bugzilla report is now/really 213936: It turned out that clang had built xgcc's cc1 for the stage that showed the problem. So it really is a base system/clang 3.8.0 armv6/cortex-a7 code-generation problem, not a port lang/gcc6 code-generation problem.