Problem with gcc 3.4.0 & 3.4.6 in ARM thumb mode regarding stack buffer allocation

[Mick CORNUT <mick_cornut at yahoo dot fr>]

    Hello everybody!
    
We've just pointed out a strange problem with gcc 3.4.0: we use it for generating ARM 7 processor thumb code.
This strange behavior was pointed out with a function taking 5 parameters (the fifth one is passed through stack according to the abi spec).
We use the following "test.c" code:

#include <stdio.h>
void trace(int p1, int p2, int p3, int p4, char * message)
{   char temp[512];
    printf("msg is: %s", message);
}

the command line for gcc (3.4.0 or 3.4.6) is

    gcc.exe -g test.c -o test.o -Os -mcpu=arm7tdmi -mthumb -c 

disassembling the output gives:


test.o:     file format elf32-littlearm

Disassembly of section .text:

00000000 <trace>:
#include <stdio.h>

void trace(int p1, int p2, int p3, int p4, char * message)
{   char temp[512];
   0:    b580          push    {r7, r14}       ==> r7 and r14 are pushed to the stack
   2:    46bc          mov    r12, r7            ==> r12 = r7
   4:    4f05          ldr    r7, [pc, #20]    (1c <.text+0x1c>)    ==> r7 = -512
   6:    44bd          add    r13, r7            ==> sp += -512
    printf("msg is: %s", message);
   8:    9981          ldr    r1, [sp, #516]    ==> /!\  r1 = sp + 516, but since r7 and r14 were pushed, it should be r1 = sp + 520 /!\
   a:    4805          ldr    r0, [pc, #20]    (20 <.text+0x20>)
   c:    4667          mov    r7, r12
   e:    f7ff fffe     bl    0 <op_printf>
  12:    2380          movs    r3, #128
  14:    009b          lsls    r3, r3, #2
  16:    449d          add    r13, r3
  18:    bd80          pop    {r7, r15}
  1a:    0000          lsls    r0, r0, #0
  1c:    fe00 ffff     mcr2    15, 0, r15, cr0, cr15, {7}
  20:    0000          lsls    r0, r0, #0
    ...

When -O2 is used, the output is also wrong, but when compiling with -O1 we get

void trace(int p1, int p2, int p3, int p4, char * message)
{   char temp[512];
   0:    b500          push    {r14}
   2:    46bc          mov    r12, r7
   4:    4f05          ldr    r7, [pc, #20]    (1c <.text+0x1c>)
   6:    44bd          add    r13, r7
   8:    4667          mov    r7, r12
    printf("msg is: %s", message);
   a:    4805          ldr    r0, [pc, #20]    (20 <.text+0x20>)
   c:    9981          ldr    r1, [sp, #516]    ==> r1 = sp + 516, this time it's good, since only r14 has been pushed!
   e:    f7ff fffe     bl    0 <op_printf>
}
  12:    2380          movs    r3, #128
  14:    009b          lsls    r3, r3, #2
  16:    449d          add    r13, r3
  18:    bd00          pop    {r15}
  1a:    0000          lsls    r0, r0, #0
  1c:    fe00 ffff     mcr2    15, 0, r15, cr0, cr15, {7}
  20:    0000          lsls    r0, r0, #0
    ...

I've built the gcc 3.4.6 for arm target, and I get the same results. I've tracked bugzilla entries for such an issue, without success: maybe it's a side effect of another issue I don't know, but when compiling to generate ARM code, the output is ok, so it seems particular to thumb mode...

Did someone already encountered this issue? Am I doing something wrong (ok ok, allocating a 512 bytes buffer on the stack is quite dirty ;=) )?
Should I post a bug entry?


Thx for your attention,
Best regards,
Mick.





      
___________________________________________________________________________ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com