Subject: port-sun3/34851: max data size stays at DFLDSIZ / doesn't increase to MAXDSIZ
To: None <port-sun3-maintainer@netbsd.org, gnats-admin@netbsd.org,>
From: None <sigmfsk@aol.com>
List: netbsd-bugs
Date: 10/18/2006 15:20:01
>Number:         34851
>Category:       port-sun3
>Synopsis:       max data size stays at DFLDSIZ / doesn't increase to MAXDSIZ
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    port-sun3-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Oct 18 15:20:01 +0000 2006
>Originator:     Arthur Townsend
>Release:        3.0
>Organization:
>Environment:
>Description:
On a sun 3/80 (sun3x), the maximum data size is the default data size of 16Mb (DFLDSIZ in /usr/src/sys/arch/sun3/include/vmparam3x.h).  The stack does not increase to MAXSSIZ.

This problem is similar to port-sun3/34849, where the stack size would not increase over the default.
>How-To-Repeat:
The following program requires more than 16Mb (but less than 32Mb) of data size to compile.

from vmparam3.h and vmparam3x.h
sun3 DFLDSIZ 16Mb
sun3 MAXDSIZ 32Mb
sun3x DFLDSIZ 32Mb
sun3x MAXDSIZ 128Mb

It will compile with a generic kernel on a sun3x (since the default data size is 32Mb), but will not compile with a generic kernel on a sun3 (since the default data size is 16Mb, and NetBSD does not increase the max data size to the sun3 MAXDSIZ of 32Mb).

Generating a custom sun3x kernel with DFLDSIZ of 16Mb causes the program to not compile.
Generating a custom sun3 kernel with DFLDSIZ of 32Mb (thereby making DFLDSIZ and MAXDSIZ both 32Mb), causes the program to compile.


The following is gcc-3.3.3 testcase 20001226-1.c.  Compiling with DFLDSIZ >= 32Mb works successfully.  Compiling with DFLDSIZ of 16Mb causes the error:

cc1 in malloc(): error: brk(2) failed [internal error]
cc1 in malloc(): warning: recursive call.
cc1 in malloc(): warning: recursive call.
cc1 in malloc(): warning: recursive call.
In function `foo':
cc1 in free(): warning: recursive call.
cc1 in malloc(): warning: recursive call.
Abort trap
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.netbsd.org/Misc/send-pr.html> for instructions.


/* This testcase exposed two branch shortening bugs on powerpc.  */

#define C(a,b) \
  if (a > b)  goto gt; \
  if (a < b)  goto lt;

#define C4(x,b) C((x)[0], b) C((x)[1],b) C((x)[2],b) C((x)[3],b)
#define C16(x,y) C4(x, (y)[0]) C4(x, (y)[1]) C4(x, (y)[2]) C4(x, (y)[3])

#define C64(x,y) C16(x,y) C16(x+4,y) C16(x+8,y) C16(x+12,y)
#define C256(x,y) C64(x,y) C64(x,y+4) C64(x,y+8) C64(x,y+12)

#define C1024(x,y) C256(x,y) C256(x+16,y) C256(x+32,y) C256(x+48,y)
#define C4096(x,y) C1024(x,y) C1024(x,y+16) C1024(x,y+32) C1024(x,y+48)

unsigned foo(int x[64], int y[64])
{
  C4096(x,y);
  
  return 0x01234567;
 gt:
  return 0x12345678;
 lt:
  return 0xF0123456;
}

>Fix: