Date: Mon, 31 Oct 2016 05:15:33 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 213936] stable/11 -r307797 on BPi-M3 (cortex-a7): clang 3.8.0 produces bad stack code in lang/gcc6's xgcc's cc1 and so cc1 gets SIGSYS during lang/gcc6 bootstrap Message-ID: <bug-213936-7@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213936 Bug ID: 213936 Summary: stable/11 -r307797 on BPi-M3 (cortex-a7): clang 3.8.0 produces bad stack code in lang/gcc6's xgcc's cc1 and so cc1 gets SIGSYS during lang/gcc6 bootstrap Product: Base System Version: 11.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: markmi@dsl-only.net [Note: lang/gcc6's xgcc's cc1 was built by clang for the stage of the lang/gcc6 bootstrap that was in use below. So the code generation problem is clang's, not gcc6's or xgcc's.] The below was found while trying to figure out why a bootstrap lang/gcc6 build on a armv6/cortex-a7 stable/11 -r307797 crashes in xgcc's cc1 with SIGSYS for some of what xgcc tries to build. I'm recording this here while pursuing the system problems the context has also exposed: truss's error handling for watching the failing cc1 has crash problems of its own. The cc1 crash (when under gdb) shows a stack address as the pc value once the problem happens. In more detail, when ( in gcc/gimple-match-head.c ): bool gimple_resimplify1 (gimple_seq *seq, code_helper *res_code, tree type, tree *res_ops, tree (*valueize)(tree)) { . . . } returns the armv6 pc ends up with a stack address instead of a code address. [There may be other cc1 routines with similar problems. I've only analyzed the one example stack corruption.] Eliminating the long names (mostly) in the gdb disassembly output for gimple_resimplify1 so the code is easier to see --and showing function stack-handing preamble/post-amble code only: Dump of assembler code for function _Z18gimple_resimplify1PP6gimpleP11code_helperP9tree_nodePS5_PFS5_S5_E: 0x0105d5ec push {r0, r1, r4, r6, r8, r11, sp, lr} 0x0105d5f0 add r11, sp, #16 ; 0x10 0x0105d5f4 sub sp, sp, #88 ; 0x58 . . . 0x0105d7e0 sub sp, r11, #16 ; 0x10 0x0105d7e4 pop {r4, r5, r6, r10, r11, pc} Note that, just after restoring sp to its value from just after the push, the pop does not match the push and restores what was r11 (a pointer into the stack) to the pc register, matching the observed behavior that gdb shows: execution of stack contents. I have used stepi in gdb to go up to and through the pop and so have seen the evidence of the corruption fairly directly: just after the pop things are messed up in gdb with a stack address shown for the pc value. So it is a code generation defect for at least armv6 / cortext-a7. Context details: root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-portbld-freebsd11.0/libgcc # svnlite info /mnt/usr/ports | grep "Re[lv]" Relative URL: ^/head Revision: 424540 Last Changed Rev: 424540 root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-portbld-freebsd11.0/libgcc # uname -apKU FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Sat Oct 29 10:54:45 PDT 2016 markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALLWINNER arm armv6 1100505 1100505 (So stable/11 -r307797 was built with crochet, not with my usual procedure.) The crashing cc1 shows crash problems in truss. ktrace reports odd information from the stack corruption as well but does not crash. So for now the environment with all these issues is being kept in a form appropriate to testing the stable/11 truss issue(s). For example John Baldwin is working on truss for the its issue(s) and when he asks I rebuild world/kernel with his truss related updates and report what happened. (truss does not work yet for handling the cc1 failure as of when I wrote this.) root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-portbld-freebsd11.0/libgcc # more /etc/make.conf DEFAULT_VERSIONS+=perl5=5.22 WRKDIRPREFIX=/usr/obj/portswork WITH_DEBUG= WITH_DEBUG_FILES= MALLOC_PRODUCTION= # CFLAGS+= -mcpu=cortex-a7 CXXFLAGS+= -mcpu=cortex-a7 CPPFLAGS+= -mcpu=cortex-a7 So -mcpu=cortex-a7 was part of the CFLAGS/CXXFLAGS context while lang/gcc6 was being built. I'm not trying alternatives for such for now as I'm keeping the truss-testing context in place. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-213936-7>