[Bug 213934] lang/gcc6 -r424540: xgcc's cc1's internal gimple_resimplify1 messes up the stack handling on armv6 and so cc1 crashes

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213934

            Bug ID: 213934
           Summary: lang/gcc6 -r424540: xgcc's cc1's internal
                    gimple_resimplify1 messes up the stack handling on
                    armv6 and so cc1 crashes
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: gerald at FreeBSD.org
          Reporter: markmi at dsl-only.net
             Flags: maintainer-feedback?(gerald at FreeBSD.org)
          Assignee: gerald at FreeBSD.org

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.

So it is a code generation defect for at least armv6.


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.