Hi all,
These are the items asked by the "Reporting Bugs" guide:
Output of gcc -v:
=================
Using built-in specs.
Target: mips-elf
Configured with: ../gcc-4.4.2/configure --prefix=/gcc442_mips/linux
--target=mips-elf --with-newlib
--with-headers=../newlib-1.17.0/newlib/libc/include/
--with-ar=/gcc442_mips/linux/bin/mips-elf-ar
--with-as=/gcc442_mips/linux/bin/mips-elf-as
--with-ld=/gcc442_mips/linux/bin/mips-elf-ld --with-mpfr=/gcc442_mips/linux
--with-gmp=/gcc442_mips/linux --with-ppl=/gcc442_mips/linux
--with-cloog=/gcc442_mips/linux --enable-languages=c,c++ --disable-multilib
--with-gcc-version-trigger=../gcc-4.4.2/gcc/version.c --disable-libstdcxx-pch
Thread model: single
gcc version 4.4.2 (GCC)
Preprocessed files:
===================
Not needed, we've reduced the testcase to a small file that doesn't include any
other file. Here is the code :
>--- Code snippet code.c ---<
int test()
{
return 3;
}
int jumpy(int argc,char** argv)
{
test();
return 2;
}
int main(int argc,char** argv)
{
return jumpy(argc,argv);
}
>--- End of code snippet ---<
Command lines to generated the bug:
===================================
mips-elf-gcc code.c -o code16 -O0 -mips16
and (for comparison purposes, see below)
mips-elf-gcc code.c -o code32 -O0 -mips32
Note:
=====
There's no need to debug the compiled code on a real target to observe the
problem, looking at the disassembly should be sufficient.
Explanation of the Problem:
===========================
When connecting GDB on the above compiled code in *MIPS16*, stepping in the
function 'jumpy' will lost GDB a bit. It will not find the first instruction
corresponding to the call to test, and instead will then point to the first
assembly instruction of the jumpy function. The consequence is that the
function arguments will not be properly analyzed by GDB because the stack is
not yet in the proper state. Worse, if we try to set a breakpoint on the first
line of code of the function 'jumpy', this will lead GDB to be completely lost.
In *MIPS32*, debugging with GDB has no such problems.
Investigation of the Problem:
=============================
By looking at the disassembly of the jumpy function in MIPS32 and MIPS16, we
can see that
* In MIPS32, the compiler did not do any optimization with delay slots when
dealing with a call instruction.
* In MIPS16, the compiler did some optimization with delay slots, and put one
instruction of the stack saving process in the delay slot, after the first call
to the function 'test'.
Here are these disassembly dumps:
MIPS32: A nop is in the delay slot:
-----------------------------------
00400198 <jumpy>:
400198: 27bdffe8 addiu sp,sp,-24
40019c: afbf0014 sw ra,20(sp)
4001a0: afbe0010 sw s8,16(sp)
4001a4: 03a0f021 move s8,sp
4001a8: afc40018 sw a0,24(s8)
4001ac: afc5001c sw a1,28(s8)
4001b0: 0c10005d jal 400174 <test>
4001b4: 00000000 nop <= Good!
4001b8: 24020002 li v0,2
4001bc: 03c0e821 move sp,s8
4001c0: 8fbf0014 lw ra,20(sp)
4001c4: 8fbe0010 lw s8,16(sp)
4001c8: 27bd0018 addiu sp,sp,24
4001cc: 03e00008 jr ra
4001d0: 00000000 nop
MIPS16: A stack-saving instruction is in the delay slot:
--------------------------------------------------------
00400188 <jumpy>:
400188: 63fd addiu sp,-24
40018a: 6205 sw ra,20(sp)
40018c: d104 sw s1,16(sp)
40018e: 0104 addiu s1,sp,16
400190: d982 sw a0,8(s1)
400192: 1a00 005d jal 400174 <test>
400196: d9a3 sw a1,12(s1) <= Bad!
400198: 6a02 li v0,2
40019a: 65b9 move sp,s1
40019c: 9701 lw a3,4(sp)
40019e: 9100 lw s1,0(sp)
4001a0: ef00 jr a3
4001a2: 6301 addiu sp,8
Expected Behaviour:
===================
We believe that the MIPS16 code should not be optimized, and that a nop should
be found in the delay slot too, the jal instruction being AFTER all stack
saving instructions.
Thanks by advance for you attention! We would be very grateful for your help,
and sorry for any flaw this bug report could contain.
Ben
--
Summary: Mips16 generated code with -O0 will often lead GDB to be
lost when the first instruction of a C code is a
function call
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ben at coolsand-tech dot fr
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: mips-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42882
