[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

[bugzilla-noreply at freebsd.org]

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 at FreeBSD.org
          Reporter: markmi at 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 at 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 at 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 at 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 at 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.