Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <cagney@gnu.org>
To: Joel Brobecker <brobecker@gnat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] OSF/1 - "next" over prologueless function call
Date: Tue, 09 Dec 2003 23:10:00 -0000	[thread overview]
Message-ID: <3FD6565C.5000300@gnu.org> (raw)
In-Reply-To: <20031208232502.GF698@gnat.com>


> So I think we should follow your suggestion above and separate
> completely the two conditions, conditionalized by legacy_frame_p().
> The function name we could use, at least for now, could be
> handle_subroutine_call() or handle_step_into_function().
> 
> It seems that the correct test when legacy_frame_p() is nonzero
> would only be the frame ID equality test, but I must admit being
> nervous again not knowing how reliable the new frame implementations
> are... Despite the fact that the current heuristics (check if PC ==
> address of function first instruction or is inside function prologue)
> doesn't cover 100% of the cases, it was still a simple, platform
> independent, solid test that worked in most cases. We are about to
> replace that by something that's a bit more complex and might cause some
> unexpected behavior if the unwinder fails to unwind properly (imagine
> for instance that the unwinder skipped one frame).

The new frame code is reliable.  If it wasn't many other areas of the 
testsuite will fail.  I'm ok with the change going in with the new 
handle_step_into_function().

Andrew


> I am really torn, so I am relying on you who has had a closer look at
> the frame implementations that have been converted so far. If it was
> just me, I would be very conservative and simply add and extra
> 
>   || (legacy_frame_p() && frame_id_eq (...))
> 
> It only fixes one problem, but the changes of introducing another is
> smaller. I am a coward :-).
> 
> -- Joel 



  reply	other threads:[~2003-12-09 23:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-02  4:26 Joel Brobecker
2003-12-02  4:30 ` Daniel Jacobowitz
2003-12-02  6:06   ` Joel Brobecker
2003-12-02  6:35 ` Richard Henderson
2003-12-02  7:21   ` Joel Brobecker
2003-12-02 15:14     ` Daniel Jacobowitz
2003-12-03  1:54       ` Joel Brobecker
2003-12-02 13:55   ` Daniel Jacobowitz
2003-12-03  4:19 ` Andrew Cagney
2003-12-04  0:55   ` Joel Brobecker
2003-12-04  1:49     ` Andrew Cagney
2003-12-04 23:24       ` Joel Brobecker
2003-12-04 23:28         ` Daniel Jacobowitz
2003-12-05 20:19         ` Andrew Cagney
2003-12-08 23:25           ` Joel Brobecker
2003-12-09 23:10             ` Andrew Cagney [this message]
2003-12-02  5:49 Michael Elizabeth Chastain
2003-12-02  7:53 Michael Elizabeth Chastain

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=3FD6565C.5000300@gnu.org \
    --to=cagney@gnu.org \
    --cc=brobecker@gnat.com \
    --cc=gdb-patches@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