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)?
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Sun, 14 Apr 2002 11:33:49 -0400
- Subject: Re: Switch ARM, SPARC and i386 to generic dummy frames (PC_IN_CALL_DUMMY)?
- References: <3CB99778.4050403@cygnus.com> <20020414111854.A4874@nevyn.them.org>
> 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