This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]