[patch rfc] push_dummy_call return a frame ID; eliminate need for read_fp

[Andrew Cagney]

Hello,

Now that the inferior function call code is all in a single function, 
more, and significant, cleanups become possible.

This patch modifies the architecture method push_dummy_call() so that it 
returns a frame ID, and not just a stack pointer.  That frame ID is then 
used:

- to create the breakpoint (the ID identifies the breakpoint's frame)

- to identify the dummy (somewhat indirectly at present as it still goes 
via SAVE_DUMMY_FRAME_TOS() and generic_save_call_dummy_addr())

This means that:

- push_dummy_call(regcache, ...) creates the dummy frame's ID

- unwind_dummy_id(frame, ...) is then expected to return that same value

so the need for one to match the other is hopefully both clear and easy ...

Future changes will involve:

- deprecating read_fp / TARGET_READ_FP, as core GDB no longer contains 
any legitimate calls

- merging SAVE_DUMMY_FRAME_TOS and generic_save_call_dummy_addr() into a 
single method that receives the full frame ID, and can not be overridden 
by the architecture.

Someone studying this carefully will probably realise that instead of 
having push_dummy_call() return the ID, the code could simply use:

	flush cached frames;
	id = get_frame_id (get_current_frame ());

but that would incure additional overhead.

Mark,
I think this patch resolves the i386's FP/SP frame ID problem.  It makes 
push_dummy_call responsible for computing the ID, and then just passes 
it through.

Richard,
For the ARM, I've pulled a quick hack.  I'm not sure what would happen 
if the ARM started returning a full frame ID.

I'll leave this one sit for a week.

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