[rfc] Add per frame frame_saved_pc()

[rfc] Add per frame frame_saved_pc()

[Andrew Cagney]

Hello,

Back to (trumpet noises) CFI and more fall-out from the MIPS and generic 
dummy frames.

- The CFI doco describes a ``return_address_register'' which ``[...] 
might not correspond to a machine register''.  This means a CFI specific 
frame saved PC method.

- Given a generic dummy frame, it knows exactly where the callers frame 
PC is.  No need to ask the target code.

With this in mind, I'd like to propose making frame_saved_pc() a 
per-frame method.

Thoughts?

To be honest, it is largely motivated by me having to wade though the 
MIPS code and add if(PC_IN_CALL_DUMMY()) to everything - I'm hopeing to 
avoid it next time :-)

After this is comes FRAME_CHAIN() but I think that needs more careful 
consideration.

Andrew

Re: [rfc] Add per frame frame_saved_pc()

[Kevin Buettner]

On Sep 19, 11:30pm, Andrew Cagney wrote:

> Back to (trumpet noises) CFI and more fall-out from the MIPS and generic 
> dummy frames.
> 
> - The CFI doco describes a ``return_address_register'' which ``[...] 
> might not correspond to a machine register''.  This means a CFI specific 
> frame saved PC method.

I'm not certain that this should (necessarily) drive our decisions.

> - Given a generic dummy frame, it knows exactly where the callers frame 
> PC is.  No need to ask the target code.
> 
> With this in mind, I'd like to propose making frame_saved_pc() a 
> per-frame method.

I'd be willing to look at a patch.  In particular, what I'm curious
about it to see the places where the frame_saved_pc field is
initialized in the frame.  I can picture how the generic dummy
frame code would look, but what I'm less clear about is what it'd
look like for normal frames.  It seems to me that you have two choices,
1) have a generic method which falls back on the current machinery, or
2) have architecture specific methods.  I'm more interested in how (2)
will be accomplished.

Kevin

Re: [rfc] Add per frame frame_saved_pc()

[Andrew Cagney]

> On Sep 19, 11:30pm, Andrew Cagney wrote:
> 
> 
>> Back to (trumpet noises) CFI and more fall-out from the MIPS and generic 
>> dummy frames.
>> 
>> - The CFI doco describes a ``return_address_register'' which ``[...] 
>> might not correspond to a machine register''.  This means a CFI specific 
>> frame saved PC method.
> 
> 
> I'm not certain that this should (necessarily) drive our decisions.

There are currently three (er 4) frame_saved_pc() functions:

frame_saved_pc(dummy)
frame_saved_pc(CFI)
frame_saved_pc(``old style with frame init saved regs'')
frame_saved_pc(NULL) === read_pc() (but only sort of)

>> - Given a generic dummy frame, it knows exactly where the callers frame 
>> PC is.  No need to ask the target code.
>> 
>> With this in mind, I'd like to propose making frame_saved_pc() a 
>> per-frame method.
> 
> 
> I'd be willing to look at a patch.  In particular, what I'm curious
> about it to see the places where the frame_saved_pc field is
> initialized in the frame.  I can picture how the generic dummy
> frame code would look, but what I'm less clear about is what it'd
> look like for normal frames.  It seems to me that you have two choices,
> 1) have a generic method which falls back on the current machinery, or
> 2) have architecture specific methods.  I'm more interested in how (2)
> will be accomplished.

If I get the code right, I won't be changing any targets :-^  The target 
frame_saved_pc() code would, simply, not be called in certain cases.

It would be handled the same way as the unwind code - See 
set_unwind_by_pc().

Andrew

Re: [rfc] Add per frame frame_saved_pc()

[Andrew Cagney]

> There are currently three (er 4) frame_saved_pc() functions:

Hmm, found another one ....

> frame_saved_pc(dummy)
> frame_saved_pc(CFI)
> frame_saved_pc(``old style with frame init saved regs'')
> frame_saved_pc(NULL) === read_pc() (but only sort of)

frame_saved_pc(``sigtramp'')

Andrew