Re: Identifying a dummy frame using a frame id

Re: Identifying a dummy frame using a frame id

[Michael Elizabeth Chastain]

> 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.

I can't comment on the internal mechanism, but I know that as a user of
gdb, if something happens during a hand function call to marker2() like
gdb hitting another breakpoint or me hitting ^C, then gdb starts acting
a little drunk at that point.  So I bet that explicit save/restore of
these frames would help.

Michael C

Re: Identifying a dummy frame using a frame id

[Andrew Cagney]

>> 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.
> 
> 
> I can't comment on the internal mechanism, but I know that as a user of
> gdb, if something happens during a hand function call to marker2() like
> gdb hitting another breakpoint or me hitting ^C, then gdb starts acting
> a little drunk at that point.  So I bet that explicit save/restore of
> these frames would help.

FYI, that's a different problem.

This proposal just refines the mechanism used to identify a dummy frame. 
  For something like the i386, there would be no immediate change in 
behavior.

Andrew

Identifying a dummy frame using a frame id

[Andrew Cagney]

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

Re: Identifying a dummy frame using a frame id

[Andrew Cagney]

> - 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.

Refinement #1.

unwind dummy frame id (next_frame)

Given the `next' frame, use frame_register_unwind() to construct the 
dummy frame's ID.

Why?  Because this also needs to work when the dummy-frame isn't 
innermost (the inner most frame edge case is covered by passing it the 
sentinel frame).

(my brain hurts!)
Andrew