frame info's saved registers

[Andrew Cagney <ac131313 at redhat dot com>]

Hello,

The d10v, like many architectures, has a Link-Register (r13) that is 
used to save the PC return address when making a function call.  The 
LR's value is then, typically, saved on the stack.

The current `info frame' code reports this thus (r13 is the LR):

(gdb) info frame
....
 Saved registers:
  r0 at 0x200bdec, r11 at 0x200bdf6, r13 at 0x200bdf4

The offbyone branch, reports something slightly different:

(gdb) info frame
....
 Saved registers:
  r0 at 0x200bdec, r11 at 0x200bdf6, pc at 0x200bdf4

i.e., instead of reporting where r13 (the link register) was saved, it 
is reporting where the `pc' was saved.


What happened?

The `Saved registers' line of the `info frame' code was written back 
when GDB could assume that all registers saved by a function's prologue 
could be located using a simple table (the saved regs array).  The code 
could simply print out the addresses found in that table.

Unfortunatly, life is no longer that simple.  The table is no more.  In 
its place, is the call:
          /* Find out the location of the saved register without
             fetching the corresponding value.  */
          frame_register_unwind (fi, i, &optimized, &lval, &addr,
				 &realnum, NULL);
The thing is, for the d10v, this function is recursive, and this 
function is more exact.  It tracks down the ultimate location, if any, 
of a register.  For the d10v:

- the caller's PC was first saved in r13 (lr) and then stored on the 
stack.  Hence it reports that the pc was ultimatly saved at 0x200bdf4

- for r13, on the other hand, the code knows that the call instruction 
trashed the register's value and, hence, marks that register as 
optimized away (not shown in the above list)

It can even report the ultimate address of a register that was saved N 
frames further in on the stack.


Is this wrong?

No.  The simplistic `Saved registers' line no longer makes much sense. 
What is displayed there needing a re-think:

- should it be recursive?
- should it display additional information such as registers moved to 
other registers?
- what happens when a register value is split across several 
memory/register locations?
- should it display where the selected frames registers came from, 
instead of where the caller's registers are going to?
- should there instead be `info unwind'?

Andrew