From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21441 invoked by alias); 19 Mar 2002 16:20:50 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21268 invoked from network); 19 Mar 2002 16:20:39 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 19 Mar 2002 16:20:39 -0000 Received: from dhcppc2 (taarna.cygnus.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id IAA24947; Tue, 19 Mar 2002 08:20:34 -0800 (PST) Subject: Re: ARM sim patch: increase default target memory From: Anthony Green To: Andrew Cagney Cc: Nick Clifton , gdb-patches@sources.redhat.com In-Reply-To: <3C975D3B.8010805@cygnus.com> References: <200203171650.g2HGo8714138@louie.sfbay.redhat.com> <1016488049.16219.118.camel@dhcppc2> <3C9694AF.6050605@cygnus.com> <1016521626.18520.17.camel@dhcppc2> <3C975D3B.8010805@cygnus.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 (1.0.2-0.7x) Date: Tue, 19 Mar 2002 08:20:00 -0000 Message-Id: <1016554885.18678.76.camel@dhcppc2> Mime-Version: 1.0 X-SW-Source: 2002-03/txt/msg00346.txt.bz2 On Tue, 2002-03-19 at 07:46, Andrew Cagney wrote: > The number is a compromise between a fast simulator startup, sufficient > memory for a typical simulation and unnecessary VM grab. It was also > found to be sufficient for the basic GDB and GCC tests. Unfortunately this isn't true anymore. gcj is part of GCC and 2MB is not enough space. > From memory, he Java tests run on the MIPS (and PPC?) simulators and > yet there haven't been problems. The MIPS defaults to 2mb, the PPC 1mb. (just MIPS) The default runtime requirements have grown since the early days. 8MB appears to be a very comfortable amount of space, although with some experimentation this could probably be brought down. > I don't think that re-compiling GDB is the correct way for a user to > change the size of simulator memory. Instead the user should be able to > fix it at run time. I think that is the real bug here. Yes, I agree that this is a bug, which is why I filed a case against it. AG