Re: [RFA] Remove calls to inside_entry_file

[Corinna Vinschen <vinschen@redhat.com>]

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@redhat.com