Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: Anthony Green <green@redhat.com>
Cc: Nick Clifton <nickc@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: ARM sim patch: increase default target memory
Date: Tue, 19 Mar 2002 08:39:00 -0000	[thread overview]
Message-ID: <3C9769BA.2050401@cygnus.com> (raw)
In-Reply-To: <1016554885.18678.76.camel@dhcppc2>

> 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.

As I said a compromise for the ``basic'' gcc tests.  I recall this value 
being put up once before and people complaining that the basic tests 
slowed down and GDB grabbed too much memory.

>> 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.

We're going to degenerate into semantics :-)

Arm can't change its memory size at run time.  This is the bug that hurt 
you - you had to change a compile time constant to fix your problem and 
that simply shouldn't have been necessary.  Remember, the other 
simulators don't have this problem as -m<blah> can be used.

As a separate issue, it is probably time to review the default memory 
size for all the simulators.  Should they all be increased (to again be 
consistent)?  Should the GDB builder be allowed to 
--enable-sim-memory-size=BLAH this?

Andrew






  reply	other threads:[~2002-03-19 16:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-17  8:52 Anthony Green
2002-03-17  9:13 ` Andrew Cagney
     [not found] ` <m3ofhnyt7d.fsf@north-pole.nickc.cambridge.redhat.com>
2002-03-18 13:50   ` Anthony Green
2002-03-18 17:30     ` Andrew Cagney
2002-03-18 23:06       ` Anthony Green
2002-03-19  7:46         ` Andrew Cagney
2002-03-19  8:20           ` Anthony Green
2002-03-19  8:39             ` Andrew Cagney [this message]
2002-03-19  9:43               ` Andrew Cagney
2002-04-07 10:06 ` [rfa] Add -m; Was: " Andrew Cagney
2002-04-08  2:34   ` Nick Clifton
2002-04-08 20:05     ` Andrew Cagney
2002-04-09  1:21       ` Nick Clifton
2002-09-27 17:00         ` Andrew Cagney
2002-03-17 10:04 Anthony Green
2002-03-17 10:24 ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C9769BA.2050401@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=green@redhat.com \
    --cc=nickc@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox