This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] Remove some hardwired assumptions about register sets
- From: Andrew Cagney <cagney at gnu dot org>
- To: fnf at ninemoons dot com
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 05 Jan 2004 10:50:53 -0500
- Subject: Re: [PATCH] Remove some hardwired assumptions about register sets
- References: <200312170614.hBH6Ebtl003033@fred.ninemoons.com> <20031223020339.GA13570@nevyn.them.org> <3FF5C642.email@example.com> <firstname.lastname@example.org>
Daniel, the patch adds a global variable "num_mips_processor_regs"
We could use a new "tdep->num_mips_processor_regs" variable instead.
That is probably cleaner anyway.
I'm wondering what motivated the change?
... sidestep the issue
... made all the arrays the same size.
The problem is the assumption that all the arrays are the same size,
or perhaps more fundamentally, that "all mips architectures will have
registers sets of similar size'.
The number of registers is determined by "num_regs". Thinking about it,
wouldn't ->num_mips_processor_regs be redundant information?
I'm working on port, which will soon be contributed, that currently
adds 384 new register names (reg numbers 32-415) for a matrix
coprocessor (cop 2).
When contributed though the names will be reduced to just 69 new
names (32-100). The original port assigned separate register names to
each of the individual 256 matrix elements (16 vectors of 16 elements)
instead of handling each 16 element vector as a single named vector
Still, even with 69 new names, it gets really ugly having all the
other *_reg_name arrays have to be full of mostly null strings.
True, but it isn't that much memory.
Does setting "num_regs" to ARRAY_SIZE (relevant register name array) +
magic:32 work? What of the function
deprecated_mips_set_processor_regs_hack which would need an array size