[patch rfc] signal_handler_caller -> get_frame_type()

[Andrew Cagney]

Hello,

This change is to clean-up two problems (and at the same time eliminate 
another case of code directly manipulating


-- Many sections of code want to know the type of a frame. Is it a 
dummy?  Is it a signal handler trampoline? Is it ...?  At present they 
use deprecated_frame_is_dummy() and frame->signal_handler_caller.

This patch introduces a new method - get_frame_type() - that returns the 
frame's `type'.  At present it defines three different frame types:

* normal
* dummy
* sigtramp

All the ->signal_handler_caller tests have been (mindlessly) replaced by 
(get_frame_type() == SIGTRAMP_FRAME).

Follow-on changes would include replacing deprecated_frame_is_dummy() 
with (get_frame_type() == DUMMY_FRAME), and even (get_frame_type() == 
NORMAL_FRAME).


-- Sections of code were tweaking ->signal_handler_caller in the frame 
init function (instead of waiting for get_prev_frame() to do it for them).

The patch adds the method deprecated_set_frame_type() so that those 
functions can continue to do the tweak.

The real problem (as the comments point out) is that get_prev_frame() is 
setting the frame's type very late.  It should initialized much earlier, 
however that will involve making a call to frame_pc_unwind() (nee, 
FRAME_SAFED_PC() before FRAME_CHAIN() - knowing how fragile the frame 
code is, that is pretty scary so I'll be doing it as a separate change.


Comments?  Especially on the word `type'.  Is it going to get confused 
with the language `type'.

I'll look to commit this later this week.
Andrew
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20021111/cac212f8/attachment.ksh>