Hello,

This is a work-in-progress diff which I'm about to commit to my 
cagney_tramp-20040309-branch (it's actually created by taking a diff 
against the branchpoint).  I've omitted the trad-frame patches as they 
are not immediatly relevant.

First this modifies the frame-unwind so that:

-- A new static (in the OO sense) method called sniffer is added to 
"struct frame_unwind" and that is called to sniff out the frame.  That 
sniffer (unlike the other) returns the initial value of the frame cache.

-- A new data field (unwind_data) is added to "struct frame_unwind" so 
that more generic unwinders can be parameterised with [const] data

-- A mechanism for registering the "struct frame_unwind" (complete with 
sniffer) is added (the old mechanism remains).

-- All the unwind methods are parameterized with "struct frame_unwind"

With this in place a new object "tramp_frame", that can handle signal 
trampolines, is added.  A tramp_frame both describes the instruction 
sequence used by the trampoline and provides a method for populating a 
trad_frame cache describing the registers saved by that signal 
trampoline.  Note that this tramp_frame:

-- Matches the entire instruction sequence and hence determines the 
address of the trampolines first instruction (aka the FUNC addr).  At 
present most trampolines (i.e., all the ones I looked at) incorrectly 
call frame_func_unwind (for these frames that function will return zero 
which the frame ID code treats as a wild card).

-- Does the unwind in two stages: the sniffer matches the trampoline and 
computes FUNC; if needed (i.e., called), this_id and/or prev_register, 
populate the trad_frame cache (using that computed FUNC).

I've included a sample tramp-frame.  I think it is far simpler, and far 
more robust (I've got evil testcases pending), and more correct, than 
the old way of doing this.

comments?

My next tasks are to review the changes to frame-unwind and trad-frame 
(seeing if they can be trimmed back further) and then push them out to 
the mainline.

Andrew