Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sources.redhat.com
Subject: Re: Switch ARM, SPARC and i386 to generic dummy frames (PC_IN_CALL_DUMMY)?
Date: Sun, 14 Apr 2002 08:53:00 -0000	[thread overview]
Message-ID: <20020414115322.A5825@nevyn.them.org> (raw)
In-Reply-To: <3CB9A15D.8030807@cygnus.com>

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


  reply	other threads:[~2002-04-14 15:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-14  7:51 Andrew Cagney
2002-04-14  8:18 ` Daniel Jacobowitz
2002-04-14  8:33   ` Andrew Cagney
2002-04-14  8:53     ` Daniel Jacobowitz [this message]
2002-04-14  9:40       ` Andrew Cagney
2002-04-14 10:17         ` Daniel Jacobowitz
2002-04-15  0:51 ` Peter.Schauer
2002-04-15  6:42   ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020414115322.A5825@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=ac131313@cygnus.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox