https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518
--- Comment #10 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
I'm having some trouble reproducing this bug. I'm a little rusty on cross
builds, so perhaps someone can lend a hand.
I have a set of combined sources which I'm using to build a toolchain like
this:
~/src/combined/configure --host=x86_64-linux --build=x86_64-linux
--target=armeb-eabi --with-mode=arm --with-cpu=cortex-a9 --with-fpu=neon-fp16
--enable-languages=fortran --disable-libgomp --disable-libsanitizer
--disable-werror
I then do:
cd gcc && make check-fortran RUNTESTFLAGS="execute.exp=in-pack.f90
--target_board=arm-sim"
=== gfortran tests ===
Schedule of variations:
arm-sim
Running target arm-sim
Using /usr/share/dejagnu/baseboards/arm-sim.exp as board description file for
target.
Using /usr/share/dejagnu/config/sim.exp as generic interface file for target.
Using /usr/share/dejagnu/baseboards/basic-sim.exp as board description file for
target.
Using /home/cygnus/aldyh/src/combined/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running
/home/cygnus/aldyh/src/combined/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp
...
FAIL: gfortran.fortran-torture/execute/in-pack.f90 execution, -O0
FAIL: gfortran.fortran-torture/execute/in-pack.f90 execution, -O1
...
I get failures for everything, but it seems every execution test fails, even
simple C tests. Tests fail with no messages, just a simple execution failure,
so I had to dig into the simulator.
I patched the gdb simulator to trace the instructions to see where we are
dying:
diff --git a/sim/arm/wrapper.c b/sim/arm/wrapper.c
index bc1a043..4492b19 100644
--- a/sim/arm/wrapper.c
+++ b/sim/arm/wrapper.c
@@ -53,7 +53,7 @@ int stop_simulator;
#include "dis-asm.h"
This presumably gives us some tracing in gcc/testsuite/*/*.log:
/* TODO: Tracing should be converted to common tracing module. */
-int trace = 0;
+int trace = 1;
int disas = 0;
int trace_funcs = 0;
The GCC testsuite log file now shows:
pc: 8c8c, instr: e3530014
pc: 8c90, instr: 1afffffb
pc: 8c94, instr: e5952000
pc: 8c98, instr: e3a03000
pc: 8c9c, instr: e5856014
pc: 8ca0, instr: e5853018
pc: 8ca4, instr: e1c520fc
pc: 4, instr: ea00089b
I took a peek at the executable being run with "/my-arm-build/objdudump -D
the-executable.exe", and I see we are failing in initialise_monitor_handles().
This suggests we're failing during the start-up code:
8c8c: e3530014 cmp r3, #20
8c90: 1afffffb bne 8c84 <initialise_monitor_handles+0x7c>
8c94: e5952000 ldr r2, [r5]
8c98: e3a03000 mov r3, #0
8c9c: e5856014 str r6, [r5, #20]
8ca0: e5853018 str r3, [r5, #24]
8ca4: e1c520fc strd r2, [r5, #12]
It seems that last store is corrupting things and making us jump to a PC of
4???
Before I bark up the wrong trees, I have some questions.
Am I running the simulator correctly? Does it require a special flag for
cortex-a9?
Is the cortex-a9 CPU even handled by the simulator?
Should I run the dejagnu tests with -mcpu=xxxx or whatever, or is the
--with-cpu=cortex-a9 configury flag enough?
Does the arm newlib/libgloss/whatever code have instructions that aren't
handled by the GDB simulator?
I don't want to dig too deep into this, only to find out that our simulator,
newlib, or whatever cannot handle cortex-a9 + neon-fp16.
For that matter, is this bug reproducible on a more generic Arm variant that
*IS* supported by gdb?
Sorry for the barrage of questions, but this is a P1, and there doesn't seem to
be an easy way to reproduce this.
