This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Remove calls to inside_entry_file
On Tue, Apr 01, 2003 at 11:35:48AM -0500, Andrew Cagney wrote:
>
> >>Andrew
> >>
> >>PS: Patch?
>
> The revised change you committed to frame.c?
Oh, you wrote "Consider that approved" so I didn't thought I'd have
to send it again to gdb-patches. However, what about the important
part of my posting:
>I've checked in the frame.c patch but still, I don't understand this
>decision. So called out-of-date targets can easily add the
>inside_entry_file() call to their frame_chain_valid() implementation
>so removing this call from blockframe.c does not necessarily break
>them. Keeping this call in blockframe.c on the other hand breaks
>some targets for which this call is plainly wrong. So the logic would
>imply to remove the call in favour of *all* targets able to run correctly.
The patch to frame.c looks like this now:
Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.91
retrieving revision 1.92
diff -u -p -r1.91 -r1.92
--- frame.c 31 Mar 2003 19:01:19 -0000 1.91
+++ frame.c 1 Apr 2003 15:26:08 -0000 1.92
@@ -1428,6 +1428,7 @@ get_prev_frame (struct frame_info *this_
return this_frame->prev;
this_frame->prev_p = 1;
+#if 0
/* If we're inside the entry file, it isn't valid. Don't apply this
test to a dummy frame - dummy frame PC's typically land in the
entry file. Don't apply this test to the sentinel frame.
@@ -1439,6 +1440,15 @@ get_prev_frame (struct frame_info *this_
/* NOTE: cagney/2003-01-10: If there is a way of disabling this test
then it should probably be moved to before the ->prev_p test,
above. */
+ /* NOTE: vinschen/2003-04-01: Disabled. It turns out that the call to
+ inside_entry_file destroys a meaningful backtrace under some
+ conditions. E. g. the backtrace tests in the asm-source testcase
+ are broken for some targets. In this test the functions are all
+ implemented as part of one file and the testcase is not necessarily
+ linked with a start file (depending on the target). What happens is,
+ that the first frame is printed normaly and following frames are
+ treated as being inside the enttry file then. This way, only the
+ #0 frame is printed in the backtrace output. */
if (this_frame->type != DUMMY_FRAME && this_frame->level >= 0
&& inside_entry_file (get_frame_pc (this_frame)))
{
@@ -1447,6 +1457,7 @@ get_prev_frame (struct frame_info *this_
"Outermost frame - inside entry file\n");
return NULL;
}
+#endif
/* If we're already inside the entry function for the main objfile,
then it isn't valid. Don't apply this test to a dummy frame -
Corinna
--
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen at redhat dot com