This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]