This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Switch ARM, SPARC and i386 to generic dummy frames (PC_IN_CALL_DUMMY)?
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