[wip/rfc] Merge REGISTER_TO_VALUE and REGISTER_TO_TYPE

[Andrew Cagney]

Hello,

I've been looking at merging the MIPS specific REGISTER_TO_TYPE with 
REGISTER_TO_VALUE but first some background.

GDB currently has three register<->type conversion methods (I'm only 
looking at the forward conversions here):

REGISTER_CONVERTIBLE:
REGISTER_CONVERT_TO_RAW:
REGISTER_CONVERT_TO_VIRTUAL:
   Used by value_/of/_register.
   They date back to when GDB was trying to raw register values into an 
internal form.  For instance (from memory), the m68k was converting it's 
floating point registers into strict ieee.
   These methods are no longer needed,  Instead, registers are always 
exactly described by their type and the register's underlying contents 
are left unchanged.  If, as with the MIPS, a register has multiple 
views, then it is handled by having multiple pseudo registers.

CONVERT_REGISTER_P
REGISTER_TO_VALUE
VALUE_TO_REGISTER
   Use by value_/from/_register.
   These methods are used to perform single register <-> value 
conversions.  For instance, the Alpha will store integer values 
(variables) in floating point registers.  When GDB goes to extract an 
integer's value it needs to perform an Alpha specific float<->integer 
conversion.  The original code re-used REGISTER_CONVERTIBLE but was 
later separated out.

REGISTER_TO_TYPE
TYPE_TO_REGISTER
   Used by value_/from/_register.
   The MIPS uses this to convert a value spread across multiple 
registers (REGISTER_TO_VALUE applies to a single register only).

So ...

The REGISTER_CONVERTIBLE series is ``dead''.   I should at least 
deprecate them.  The only thing really making them stay around is the 
MIPS and there Kevins stuff should eliminate it.  The other 
architectures still using them can (as the Alpha just did) simply switch 
to REGISTER_TO_VALUE.

As for REGISTER_TO_TYPE and REGISTER_TO_VALUE, they very much have 
overlapping functionality.  The only significant difference is that one 
applies to a single register, while the second applies to multiple 
registers.  Even the condition selecting which to apply is ``magic''.
   num_storage_locs = (len > REGISTER_VIRTUAL_SIZE (regnum) ?
                       ((len - 1) / REGISTER_RAW_SIZE (regnum)) + 1 :
                       1);
   if (num_storage_locs > 1
     ... REGISTER_TO_TYPE ...
   else
     ... REGISTER_TO_VALUE ...
(remember a register can still have different raw and virtual sizes :-()

With this in mind, I'm thinking that REGISTER_TO_TYPE and 
REGISTER_TO_VALUE should be merged.  To that end, I can see several ways 
of doing it:

- Don't merge - add REGISTER_TO_TYPE to the architecture vector

- Retain the current logic - just apply REGISTER_TO_VALUE to values 
stored across multiple registers

- Add a frame parameter to REGISTER_TO_VALUE and make it responsible for 
both extracting the bytes from the register[s] and then storing them in 
the ``struct value''.

The last option is interesting, it would let the target draw the value 
from any register based on REGNUM.  The i386 with its long-long problem 
might be interested in this (you'll notice in the patch I made an 
attempt at doing this only I didn't see it affect the test results).

Thoughts?

Andrew
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20030604/b1a6422b/attachment.ksh>