https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571
Bug ID: 71571
Summary: [CRIS] Multiple inheritance non-virtual PIC thunk
causes crash
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at davidrobins dot net
Target Milestone: ---
Created attachment 38719
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38719&action=edit
Add nop for ba (branch) delay slot in PIC multiple inheritance thunk
The jump to the primary function in the generated non-virtual thunk for the
CRIS platform is missing the delay slot instruction (an instruction following
the jump that is executed before it) in PIC mode, so it runs the following
instruction in the text segment instead. (This following instruction is
frequently the next function's preamble, usually a sub from $sp, which causes a
crash in a subsequent return or other stack lookup.)
We initially saw this problem on a vendor-provided (Axis) GCC 4.3.1, but it
repros on current SVN (r237536 when I checked it out). Details of GCC build:
gcc version 7.0.0 20160616 (experimental) (GCC)
Host: x86_64-unknown-linux-gnu
Target: crisv32-axis-linux-gnu
Configured with: ../gcc-svn/configure --prefix=/opt/cross
--target=crisv32-axis-linux-gnu --enable-languages=c,c++ --disable-multilib
The build command-line is: /opt/cross/bin/crisv32-axis-linux-gnu-g++ -fPIC
-save-temps -o test main.cpp (substitute main.ii)
I am attaching:
* a repro program, main.ii; after reduction it (probably) doesn't crash but
the thunk with branch ("ba") without a delay-slot instruction can be seen in
the assembly,
* a slightly larger repro, crash.ii, that reliably crashes (due to an
$sp-modifying instruction following the branch); this requires additional g++
options -O2 -fno-inline (the -O2 to eliminate a dword stored in memory after
the ba instruction, and -fno-inline to prevent the thunk from being an inline
copy of the function it would jump to)
* a patch to fix the problem.
Runs of "make check-gcc-c++ RUNTESTFLAGS=--target_board=cris-sim" with/without
the fix do not differ in passes/failures. I would like to add a test for this
issue but am unsure as to the correct way of doing so; crash.ii could be used
in an execute test, or is checking the output assembly better, or something
else?
