* [RFA] Fix backtrace/1435
@ 2003-11-17 21:35 Mark Kettenis
2003-11-17 22:27 ` Andrew Cagney
0 siblings, 1 reply; 3+ messages in thread
From: Mark Kettenis @ 2003-11-17 21:35 UTC (permalink / raw)
To: gdb-patches
This patch fixes backtrace/1435. The failure occurs when main
immediately follows a function (say foo) which has its epilogue
optimized out by the compiler. In that case the backtrace will be
terminated prematurely since get_frame_pc on foo's frame will return
the address of the first instruction of main. This can be fixed by
using get_frame_address_in_block.
Ok to check this in?
Mark
Index: ChangeLog
from Mark Kettenis <kettenis@gnu.org>
* frame.c (get_prev_frame): Use result from
get_frame_address_in_block instead of get_frame_pc as argument to
inside_main_func.
Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.147
diff -u -p -r1.147 frame.c
--- frame.c 24 Oct 2003 17:37:03 -0000 1.147
+++ frame.c 17 Nov 2003 21:02:40 -0000
@@ -1792,7 +1792,7 @@ get_prev_frame (struct frame_info *this_
if (this_frame->level >= 0
&& !backtrace_past_main
- && inside_main_func (get_frame_pc (this_frame)))
+ && inside_main_func (get_frame_address_in_block (this_frame)))
/* Don't unwind past main(), bug always unwind the sentinel frame.
Note, this is done _before_ the frame has been marked as
previously unwound. That way if the user later decides to
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFA] Fix backtrace/1435
2003-11-17 21:35 [RFA] Fix backtrace/1435 Mark Kettenis
@ 2003-11-17 22:27 ` Andrew Cagney
2003-11-19 17:36 ` Mark Kettenis
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Cagney @ 2003-11-17 22:27 UTC (permalink / raw)
To: Mark Kettenis; +Cc: gdb-patches
> This patch fixes backtrace/1435. The failure occurs when main
> immediately follows a function (say foo) which has its epilogue
> optimized out by the compiler. In that case the backtrace will be
> terminated prematurely since get_frame_pc on foo's frame will return
> the address of the first instruction of main. This can be fixed by
> using get_frame_address_in_block.
>
> Ok to check this in?
Yes, but with more comments :-)
> Index: ChangeLog
> from Mark Kettenis <kettenis@gnu.org>
>
> * frame.c (get_prev_frame): Use result from
> get_frame_address_in_block instead of get_frame_pc as argument to
> inside_main_func.
>
Andrew
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFA] Fix backtrace/1435
2003-11-17 22:27 ` Andrew Cagney
@ 2003-11-19 17:36 ` Mark Kettenis
0 siblings, 0 replies; 3+ messages in thread
From: Mark Kettenis @ 2003-11-19 17:36 UTC (permalink / raw)
To: cagney; +Cc: gdb-patches
Date: Mon, 17 Nov 2003 17:27:47 -0500
From: Andrew Cagney <cagney@gnu.org>
> Ok to check this in?
Yes, but with more comments :-)
Here's what I actually checked in.
Mark
Index: ChangeLog
from Mark Kettenis <kettenis@gnu.org>
* frame.c (get_prev_frame): Use result from
get_frame_address_in_block instead of get_frame_pc as argument to
inside_main_func. Fixes PR backtrace/1435.
Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.147
diff -u -p -r1.147 frame.c
--- frame.c 24 Oct 2003 17:37:03 -0000 1.147
+++ frame.c 19 Nov 2003 17:34:38 -0000
@@ -1790,9 +1790,13 @@ get_prev_frame (struct frame_info *this_
get_current_frame(). */
gdb_assert (this_frame != NULL);
+ /* Make sure we pass an address within THIS_FRAME's code block to
+ inside_main_func. Otherwise, we might stop unwinding at a
+ function which has a call instruction as its last instruction if
+ that function immediately precedes main(). */
if (this_frame->level >= 0
&& !backtrace_past_main
- && inside_main_func (get_frame_pc (this_frame)))
+ && inside_main_func (get_frame_address_in_block (this_frame)))
/* Don't unwind past main(), bug always unwind the sentinel frame.
Note, this is done _before_ the frame has been marked as
previously unwound. That way if the user later decides to
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-11-19 17:36 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-11-17 21:35 [RFA] Fix backtrace/1435 Mark Kettenis
2003-11-17 22:27 ` Andrew Cagney
2003-11-19 17:36 ` Mark Kettenis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox