[Bug c/42882] New: Mips16 generated code with -O0 will often lead GDB to be lost when the first instruction of a C code is a function call

["ben at coolsand-tech dot fr" <gcc-bugzilla at gcc dot gnu dot org>]

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