Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@red-bean.com>
To: pgilliam@us.ibm.com
Cc: gdb-patches@sourceware.org, Daniel Jacobowitz <drow@false.org>,
	 	gdb-patches@sources.redhat.com
Subject: Re: [PATCH] add 'rs6000_in_function_epilogue_p()'
Date: Sat, 03 Dec 2005 03:05:00 -0000	[thread overview]
Message-ID: <8f2776cb0512021419w5af03946je07634a4400417fd@mail.gmail.com> (raw)
In-Reply-To: <200512021146.54036.pgilliam@us.ibm.com>

On 12/2/05, Paul Gilliam <pgilliam@us.ibm.com> wrote:
> This patch does *not* assume that the exit of the function is near the end of the function.
>
> It's more/less of a hack than that!
>
> Here is the 'algorithm':
> 1) scan forward from the point of execution:
>     a) If you find an instruction that modifies the stack pointer, execution is not in an epilogue, return.
>     b) Stop scanning if you find a return instruction or reach the end of the function.
> 2) scan backward from the point of execution:
>      a) If you find an instruction that modifies the stack pointer, execution *is* in an epilogue, return.
>      b) Stop scanning if you reach the beginning of the function.

(That text belongs in a comment, else Daniel wouldn't have got it wrong!)

You know, there's no reason this logic wouldn't be equally useful in
the skip_prologue function.  If the prologue scan doesn't make it to
the PC, then we could do the above, and use it to provide an accurate
frame ID.  That would fix the bug, and backtraces too.


WARNING: multiple messages have this Message-ID
From: Jim Blandy <jimb@red-bean.com>
To: pgilliam@us.ibm.com
Cc: gdb-patches@sourceware.org, Daniel Jacobowitz <drow@false.org>,
	 	gdb-patches@sources.redhat.com
Subject: Re: [PATCH] add 'rs6000_in_function_epilogue_p()'
Date: Fri, 02 Dec 2005 23:38:00 -0000	[thread overview]
Message-ID: <8f2776cb0512021419w5af03946je07634a4400417fd@mail.gmail.com> (raw)
Message-ID: <20051202233800.8CeNZuXc6-FyVYrL2jvJS6cEH8ZdOM1aWftpRe-JAAA@z> (raw)
In-Reply-To: <200512021146.54036.pgilliam@us.ibm.com>

On 12/2/05, Paul Gilliam <pgilliam@us.ibm.com> wrote:
> This patch does *not* assume that the exit of the function is near the end of the function.
>
> It's more/less of a hack than that!
>
> Here is the 'algorithm':
> 1) scan forward from the point of execution:
>     a) If you find an instruction that modifies the stack pointer, execution is not in an epilogue, return.
>     b) Stop scanning if you find a return instruction or reach the end of the function.
> 2) scan backward from the point of execution:
>      a) If you find an instruction that modifies the stack pointer, execution *is* in an epilogue, return.
>      b) Stop scanning if you reach the beginning of the function.

(That text belongs in a comment, else Daniel wouldn't have got it wrong!)

You know, there's no reason this logic wouldn't be equally useful in
the skip_prologue function.  If the prologue scan doesn't make it to
the PC, then we could do the above, and use it to provide an accurate
frame ID.  That would fix the bug, and backtraces too.


  parent reply	other threads:[~2005-12-02 22:19 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-30 23:56 Paul Gilliam
2005-12-01  5:21 ` Jim Blandy
2005-12-01 18:27   ` Paul Gilliam
2005-12-01 20:14     ` Paul Gilliam
2005-12-02  1:13 ` Jim Blandy
2005-12-02  1:23   ` Daniel Jacobowitz
2005-12-02 20:12     ` Paul Gilliam
2005-12-02 20:17       ` Paul Gilliam
2005-12-03  3:05       ` Jim Blandy [this message]
2005-12-02 23:38         ` Jim Blandy
2005-12-04 20:19         ` Daniel Jacobowitz
2005-12-04 18:59           ` Daniel Jacobowitz
2005-12-04 20:48           ` Jim Blandy
2005-12-04 21:12             ` Jim Blandy
2005-12-04 21:16             ` Daniel Jacobowitz
2005-12-04 21:22               ` Jim Blandy
2005-12-02  4:02   ` Joel Brobecker
2005-12-02 18:44   ` Mark Kettenis
2005-12-02 19:15   ` [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) Paul Gilliam
2005-12-02 20:28     ` Mark Kettenis
2005-12-02 21:19       ` Daniel Jacobowitz
2005-12-02 21:21         ` Mark Kettenis
2005-12-03  4:53       ` [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised, again) Paul Gilliam
2005-12-03  5:43         ` Paul Gilliam
2005-12-02 21:44     ` [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) Kevin Buettner
2005-12-06 15:20       ` Paul Gilliam
2005-12-06 15:15         ` Paul Gilliam
2005-12-08  4:42         ` Kevin Buettner
2006-01-11 17:44       ` Paul Gilliam
2006-01-12  0:12         ` Paul Gilliam
2006-01-12 23:53           ` Paul Gilliam
2006-01-13 21:05             ` Mark Kettenis
2006-01-17  3:46               ` Paul Gilliam
2006-01-17 19:29                 ` Mark Kettenis
2006-02-09 17:46                 ` Kevin Buettner
2005-12-02 22:19     ` Jim Blandy
2005-12-02 22:28       ` Daniel Jacobowitz
2005-12-02 23:20         ` Jim Blandy
2005-12-03 12:48       ` Paul Gilliam

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=8f2776cb0512021419w5af03946je07634a4400417fd@mail.gmail.com \
    --to=jimb@red-bean.com \
    --cc=drow@false.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pgilliam@us.ibm.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