Identifying a dummy frame using a frame id

[Andrew Cagney <ac131313 at redhat dot com>]

Given a command like:

(gdb) print marker2(99)

GDB, in the function hand_function_call() in combination with a few 
other bits of code:

- creates a dummy frame object and pushes that onto the top of a 
gdb-internal dummy frame stack
- saves the registers in that dummy frame
- plants a magic breakpoint somewhere in the target (saving that address 
in the dummy frame object)
- fakes up a frame that correspons to a call to marker2() with parameter 
`99', and with the return address pointing at that `magic breakpoint'
- set's the PC to marker2()
- resumes the target

the target then, eventually, returns from marker2() and hits the magic 
breakpoint.  GDB then:

- relocates the corresponding dummy frame object
- restores the registers from that object

Now, there is a little detail missing - how GDB relocate the dummy frame 
object that contains those saved registers.  The problem is that GDB 
can't just take the most recent one as, due to long jumps and the like, 
it can be wrong.

So GDB instead tries to re-find the dummy frame object using, er, a 
combination of the saved stack pointer before the call, the saved frame 
base, the saved stack pointer after the call, and various other heruistics.

I'm thinking that, instead, GDB should use a pair of architecture 
specific methods:

- save_dummy_frame_id (pre-push-registers, post-push-registers, any 
other value thought to be useful)
Given the value of the registers pre/post the creation of the fake dummy 
frame call, store the frame ID that identifies the frame.  This is a 
refinement of SAVE_DUMMY_FRAME_TOS().

- get_dummy_frame_id (target registers)
Given a target stopped on that dummy frame breakpoint, return a frame ID 
that exactly matches dummy_frame_id() above.

There are two key changes here:

- save a dummy frame specific frame id.  Previously 
SAVE_DUMMY_FRAME_TOS() would save the top-of-stack.  Some ISAs (namely 
ia64) have two stack pointers so, when identifying a frame, need both. 
frame ID was `designed with this in mind'.

- use an explicit method for extracting the frame ID from the registers 
when the target is sitting on a dummy frame breakpoint (the underlying 
problem with the x86-64 is that cfi_read_fp() it was never ment to find 
the FP of a dummy frame).  Previously, sp/fp were used.

thoughts?
Andrew