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
next prev parent 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