Bug 26713 - Stack frame allocation limited to 32k
Summary: Stack frame allocation limited to 32k
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.1.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2006-03-16 12:34 UTC by Christoph Stueckjuergen
Modified: 2006-03-21 13:25 UTC (History)
2 users (show)

See Also:
Host: x86_64-linux-gnu
Target: mips64-linux-gnu
Build: x86_64-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Stueckjuergen 2006-03-16 12:34:42 UTC
Allocation of stack frames is limited to a maximum of 32k, regardless of how much memory is needed by local variables. Addressing of local variables, on the other hand, is also possible beyond the 32k limit. This can lead to unpredictable application behavior. No compiler warning is generated. See the C code below and the commented assembler output.

int main(void)
{
        char array[32770];
        array[0] = 12;
        array[32769] = 34;
        
        return 0;
}

results in:

10000690 <main>:
10000690:	27bd8020 	addiu	sp,sp,-32736    # char array[32770]
                                                        # only results in 32736
                                                        # bytes being allocated
10000694:	ffbe7fd8 	sd	s8,32728(sp)
10000698:	ffbc7fd0 	sd	gp,32720(sp)
1000069c:	27bdffc0 	addiu	sp,sp,-64
100006a0:	03a0f02d 	move	s8,sp
100006a4:	3c1c0011 	lui	gp,0x11
100006a8:	0399e021 	addu	gp,gp,t9
100006ac:	279c82a0 	addiu	gp,gp,-32096
100006b0:	2402000c 	li	v0,12
100006b4:	a3c20000 	sb	v0,0(s8)        # array[0]=12
100006b8:	3c020001 	lui	v0,0x1
100006bc:	03c21821 	addu	v1,s8,v0        # v1=s8+65536
100006c0:	24020022 	li	v0,34
100006c4:	a0628001 	sb	v0,-32767(v1)   # array[65536-32767]=34
                                                        # Addressing of local
                                                        # variables is possible
                                                        # beyond the 32k
                                                        # boundary
100006c8:	0000102d 	move	v0,zero
100006cc:	27dd0040 	addiu	sp,s8,64
100006d0:	dfbe7fd8 	ld	s8,32728(sp)
100006d4:	dfbc7fd0 	ld	gp,32720(sp)
100006d8:	03e00008 	jr	ra
100006dc:	27bd7fe0 	addiu	sp,sp,32736
Comment 1 Richard Biener 2006-03-16 12:38:29 UTC
Please try 4.0.3 or 4.1.0, the 3.4 series is no longer maintained (you may turn to your system provider though).
Comment 2 Christoph Stueckjuergen 2006-03-16 15:08:05 UTC
I tried 4.1.0. The assembly code looks slightly different, but the problem remains the same:

00000000 <main>:
   0:   27bd8010        addiu   sp,sp,-32752
   4:   ffbe7fe0        sd      s8,32736(sp)
   8:   27bdffd0        addiu   sp,sp,-48
   c:   03a0f02d        move    s8,sp
  10:   2402000c        li      v0,12
  14:   a3c20000        sb      v0,0(s8)
  18:   3c020001        lui     v0,0x1
  1c:   005e1821        addu    v1,v0,s8
  20:   24020022        li      v0,34
  24:   a0628001        sb      v0,-32767(v1)
  28:   0000102d        move    v0,zero
  2c:   27dd0030        addiu   sp,s8,48
  30:   dfbe7fe0        ld      s8,32736(sp)
  34:   27bd7ff0        addiu   sp,sp,32752
  38:   03e00008        jr      ra
  3c:   00000000        nop
Comment 3 Christoph Stueckjuergen 2006-03-21 12:02:17 UTC
We found out that our problem is not related to the toolchain but to the rlimit settings of the kernel. Sorry if the bug caused confusion! Please mark the bug as invalid.
Comment 4 Andrew Pinski 2006-03-21 13:25:35 UTC
Closing as invalid as requested by the reporter.