Switch ARM, SPARC and i386 to generic dummy frames (PC_IN_CALL_DUMMY)?

Switch ARM, SPARC and i386 to generic dummy frames (PC_IN_CALL_DUMMY)?

[Andrew Cagney]

Hello,

If I remember one of those unwritten ``grand plans'' correctly, the 
intent is to have all targets switched to ``generic dummy frames''.  True?

Among other things, generic dummy frames do not save/restore registers 
on the target stack (instead they are cached locally) and this should 
improve the overall performance of an inferior function call.

Anyway, the thing that prompts this is PC_IN_CALL_DUMMY(PC, SP, FP). 
There are several implementations.  Only two:

- generic: looks for the FP in the list of dummy frames
- stack: looks for PC in [FP..SP)

require the SP/FP parameters.  I've a patch to fix the first one (search 
for the PC).  If the ARM, SPARC and i386 can switch to generic dummy 
frames then those parameters can be eliminated and all calls simplified.

Any chance of having these converted?

Andrew

Re: Switch ARM, SPARC and i386 to generic dummy frames (PC_IN_CALL_DUMMY)?

[Daniel Jacobowitz]

On Sun, Apr 14, 2002 at 10:51:36AM -0400, Andrew Cagney wrote:
> Hello,
> 
> If I remember one of those unwritten ``grand plans'' correctly, the 
> intent is to have all targets switched to ``generic dummy frames''.  True?
> 
> Among other things, generic dummy frames do not save/restore registers 
> on the target stack (instead they are cached locally) and this should 
> improve the overall performance of an inferior function call.
> 
> Anyway, the thing that prompts this is PC_IN_CALL_DUMMY(PC, SP, FP). 
> There are several implementations.  Only two:
> 
> - generic: looks for the FP in the list of dummy frames
> - stack: looks for PC in [FP..SP)
> 
> require the SP/FP parameters.  I've a patch to fix the first one (search 
> for the PC).  If the ARM, SPARC and i386 can switch to generic dummy 
> frames then those parameters can be eliminated and all calls simplified.

Wait a second.  Switch to searching for the PC?  Does that work
reliably if the PC being searched for is in more than one dummy frame?
I guess it does for PC_IN_CALL_DUMMY (a predicate), but does anything
else use the search code?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Switch ARM, SPARC and i386 to generic dummy frames (PC_IN_CALL_DUMMY)?

[Andrew Cagney]

> On Sun, Apr 14, 2002 at 10:51:36AM -0400, Andrew Cagney wrote:
> 
>> Hello,
>> 
>> If I remember one of those unwritten ``grand plans'' correctly, the 
>> intent is to have all targets switched to ``generic dummy frames''.  True?
>> 
>> Among other things, generic dummy frames do not save/restore registers 
>> on the target stack (instead they are cached locally) and this should 
>> improve the overall performance of an inferior function call.
>> 
>> Anyway, the thing that prompts this is PC_IN_CALL_DUMMY(PC, SP, FP). 
>> There are several implementations.  Only two:
>> 
>> - generic: looks for the FP in the list of dummy frames
>> - stack: looks for PC in [FP..SP)
>> 
>> require the SP/FP parameters.  I've a patch to fix the first one (search 
>> for the PC).  If the ARM, SPARC and i386 can switch to generic dummy 
>> frames then those parameters can be eliminated and all calls simplified.
> 
> 
> Wait a second.  Switch to searching for the PC?  Does that work
> reliably if the PC being searched for is in more than one dummy frame?
> I guess it does for PC_IN_CALL_DUMMY (a predicate), but does anything
> else use the search code?

Sorry, you've lost me.  BTW, the line:
 >> - generic: looks for the FP in the list of dummy frames
isn't a typo.

Andrew

Re: Switch ARM, SPARC and i386 to generic dummy frames (PC_IN_CALL_DUMMY)?

[Daniel Jacobowitz]

On Sun, Apr 14, 2002 at 11:33:49AM -0400, Andrew Cagney wrote:
> >On Sun, Apr 14, 2002 at 10:51:36AM -0400, Andrew Cagney wrote:
> >
> >>Hello,
> >>
> >>If I remember one of those unwritten ``grand plans'' correctly, the 
> >>intent is to have all targets switched to ``generic dummy frames''.  True?
> >>
> >>Among other things, generic dummy frames do not save/restore registers 
> >>on the target stack (instead they are cached locally) and this should 
> >>improve the overall performance of an inferior function call.
> >>
> >>Anyway, the thing that prompts this is PC_IN_CALL_DUMMY(PC, SP, FP). 
> >>There are several implementations.  Only two:
> >>
> >>- generic: looks for the FP in the list of dummy frames
> >>- stack: looks for PC in [FP..SP)
> >>
> >>require the SP/FP parameters.  I've a patch to fix the first one (search 
> >>for the PC).  If the ARM, SPARC and i386 can switch to generic dummy 
> >>frames then those parameters can be eliminated and all calls simplified.
> >
> >
> >Wait a second.  Switch to searching for the PC?  Does that work
> >reliably if the PC being searched for is in more than one dummy frame?
> >I guess it does for PC_IN_CALL_DUMMY (a predicate), but does anything
> >else use the search code?
> 
> Sorry, you've lost me.  BTW, the line:
> >> - generic: looks for the FP in the list of dummy frames
> isn't a typo.

Certainly.  But didn't you say "fix the first one (search for the PC)"?

My concern is if we have multiple call frames from (to?) the same PC. 
That's easy enough to do; I've done it by accident plenty of times.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Switch ARM, SPARC and i386 to generic dummy frames (PC_IN_CALL_DUMMY)?

[Andrew Cagney]

> Sorry, you've lost me.  BTW, the line:
> 
>> >> - generic: looks for the FP in the list of dummy frames
> 
>> isn't a typo.
> 
> 
> Certainly.  But didn't you say "fix the first one (search for the PC)"?
> 
> My concern is if we have multiple call frames from (to?) the same PC. 
> That's easy enough to do; I've done it by accident plenty of times.

Sorry, you've still lost me.

PC_IN_CALL_DUMMY() returns non-zero if the PC is in a ``call dummy'' 
(any call dummy).  Having multiple call dummies at the same address is 
normal (as with AT_ENTRY).

Andrew

Re: Switch ARM, SPARC and i386 to generic dummy frames (PC_IN_CALL_DUMMY)?

[Daniel Jacobowitz]

On Sun, Apr 14, 2002 at 12:40:04PM -0400, Andrew Cagney wrote:
> >Sorry, you've lost me.  BTW, the line:
> >
> >>>> - generic: looks for the FP in the list of dummy frames
> >
> >>isn't a typo.
> >
> >
> >Certainly.  But didn't you say "fix the first one (search for the PC)"?
> >
> >My concern is if we have multiple call frames from (to?) the same PC. 
> >That's easy enough to do; I've done it by accident plenty of times.
> 
> Sorry, you've still lost me.
> 
> PC_IN_CALL_DUMMY() returns non-zero if the PC is in a ``call dummy'' 
> (any call dummy).  Having multiple call dummies at the same address is 
> normal (as with AT_ENTRY).

That answers my question then :)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Switch ARM, SPARC and i386 to generic dummy frames (PC_IN_CALL_DUMMY)?

[Peter.Schauer]

AFAIK, generic dummy frames work only with the AT_ENTRY mechanism.

But for 32 bit SPARC ABI we need ON_STACK, see
http://sourceware.cygnus.com/ml/gdb/1999-q4/msg00064.html
http://sources.redhat.com/ml/gdb-patches/2000-05/msg00041.html
for an explanation.

I am afraid that we have to extend the generic dummy frame code to allow
ON_STACK, if we want to use generic dummy frames for SPARC.

> Hello,
> 
> If I remember one of those unwritten ``grand plans'' correctly, the 
> intent is to have all targets switched to ``generic dummy frames''.  True?
> 
> Among other things, generic dummy frames do not save/restore registers 
> on the target stack (instead they are cached locally) and this should 
> improve the overall performance of an inferior function call.
> 
> Anyway, the thing that prompts this is PC_IN_CALL_DUMMY(PC, SP, FP). 
> There are several implementations.  Only two:
> 
> - generic: looks for the FP in the list of dummy frames
> - stack: looks for PC in [FP..SP)
> 
> require the SP/FP parameters.  I've a patch to fix the first one (search 
> for the PC).  If the ARM, SPARC and i386 can switch to generic dummy 
> frames then those parameters can be eliminated and all calls simplified.
> 
> Any chance of having these converted?
> 
> Andrew
> 
> 
> 


-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de

Re: Switch ARM, SPARC and i386 to generic dummy frames (PC_IN_CALL_DUMMY)?

[Andrew Cagney]

> AFAIK, generic dummy frames work only with the AT_ENTRY mechanism.
> 
> But for 32 bit SPARC ABI we need ON_STACK, see
> http://sourceware.cygnus.com/ml/gdb/1999-q4/msg00064.html
> http://sources.redhat.com/ml/gdb-patches/2000-05/msg00041.html
> for an explanation.
> 
> I am afraid that we have to extend the generic dummy frame code to allow
> ON_STACK, i

I've this feeling that I might have just (accidently!) done this.  For 
sparc, the problem may be more the register window gunk.

Andrew