Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Oct 2016 21:37:35 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-arm@FreeBSD.org
Subject:   [Bug 213785] stable/11 -r307797 on BPi-M3 (cortex-a7): xgcc's cc1 during lang/gcc6 build gets SIGSYS failures (/usr/ports -r424540)
Message-ID:  <bug-213785-7@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213785

            Bug ID: 213785
           Summary: stable/11 -r307797 on BPi-M3 (cortex-a7): xgcc's cc1
                    during lang/gcc6 build gets SIGSYS failures
                    (/usr/ports -r424540)
           Product: Base System
           Version: 11.0-STABLE
          Hardware: arm
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: markmi@dsl-only.net

[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 "x=
gcc:
internal compiler error: Bad system call (program cc1)", which means a SIGS=
YS
(signal 12) resulted.

[I will note that I'v never seen this issue (so far) on the rpi2: This may =
be
KERNCONF=3DALLWINNER 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=20=20=20=20
markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALL=
WINNER
 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 u=
se
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 ha=
ndle
watching the SIGSYS related activity. (A truss bugzilla report has been mad=
e.)
Thus the following tail of the truss output for leading up to the SIGSYS do=
es
not cover the SIGSYS related activity itself:

root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-p=
ortbld-freebsd11.0/libgcc
# tail truss.log
31183 100086: close(3)                           =3D 0 (0x0)
31183 100086:
openat(AT_FDCWD,"/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libg=
cc/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 fi=
le
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/libg=
cc/../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/libg=
cc/../include/longlong.h",O_NOCTTY,00)
=3D 3 (0x3)
31183 100086: fstat(3,{ mode=3D-rw-r--r-- ,inode=3D573594,size=3D61185,blks=
ize=3D32768
}) =3D 0 (0x0)
31183 100086: read(3,"/* longlong.h -- definitions for"...,61185) =3D 61185
(0xef01)
31183 100086: close(3)                           =3D 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-p=
ortbld-freebsd11.0/libgcc
# gdb truss
. . . [the below is in enter_syscall] . . .
380             t->cs.name =3D sysdecode_syscallname(t->proc->abi->abi,
t->cs.number);
381             if (t->cs.name =3D=3D NULL)
(gdb)=20
382                     fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d --=
\n",
383                         t->proc->abi->type, t->cs.number);
384=20=20=20=20=20
385             sc =3D get_syscall(t->cs.name, narg);
386             t->cs.nargs =3D sc->nargs;
387             assert(sc->nargs <=3D nitems(t->cs.s_args));
388=20=20=20=20=20
389             t->cs.sc =3D sc;

(t->cs.name =3D=3D NULL after line 380). . .

Looking at the two things that the fprintf on lines 382 and 383 would repor=
t:

(gdb) print t->proc->abi->type
$4 =3D 0x10166 "FreeBSD ELF32"

(gdb) print t->cs.number
$5 =3D 580828064

FYI: 580828064 =3D 0x229EBBA0

(sc =3D=3D NULL results from line 385 so sc->nargs on line 386 gets a SIGSE=
GV.)

Just for completness:

(gdb) print *t
$2 =3D {entries =3D {le_next =3D 0x0, le_prev =3D 0x20617070}, proc =3D 0x2=
0617060, tid =3D
100150, in_syscall =3D 1, cs =3D {sc =3D 0x0, name =3D 0x0, number =3D 5808=
28064, args =3D
0x2061b0c0, nargs =3D 0,=20
  s_args =3D 0x2061b0ec}, before =3D {tv_sec =3D 1477418265, tv_nsec =3D 49=
2342263},
after =3D {tv_sec =3D 1477418265, tv_nsec =3D 492496630}}

(gdb) print sc
$3 =3D (struct syscall *) 0x0

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-213785-7>