This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
pending/1173: stupify MAX_REGISTER_{RAW,VIRTUAL}_SIZE
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: gdb-gnats at sources dot redhat dot com
- Date: Tue, 01 Apr 2003 19:13:40 -0500
- Subject: pending/1173: stupify MAX_REGISTER_{RAW,VIRTUAL}_SIZE
>Number: 1173
>Category: pending
>Synopsis: stupify MAX_REGISTER_{RAW,VIRTUAL}_SIZE
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: change-request
>Submitter-Id: unknown
>Arrival-Date: Sat Apr 05 01:58:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:
>Release:
>Organization:
>Environment:
>Description:
Hmm,
The architecture vector contains the two macros:
MAX_REGISTER_RAW_SIZE
MAX_REGISTER_VIRTUAL_SIZE
which provide small per-architecture upper bounds on a register. They
are used when allocating scratch buffers (typically using alloca()).
The regcache provides a successor - max_register_size().
I'm now wondering if it would be easier to simply define:
enum { MAX_REGISTER_SIZE = 16 };
and then, if that ever proves to be too small, make it bigger. Just as
long as no one creates an architecture with >~2k registers ....
Andrew
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: