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
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Fri, 28 Mar 2003 19:28:36 -0500
- Subject: Re: [RFA] Remove calls to inside_entry_file
- References: <20030327113330.GH23762@cygbert.vinschen.de>
Hi,
according to my RFC on the gdb mailing list
http://sources.redhat.com/ml/gdb/2003-03/msg00358.html
I'm now proposing to remove calls to inside_entry_func entirely from
the generic code. Additionally I've removed the call from
i386_frame_chain with no regressions on Linux and 7 new PASSes instead
of FAILs on Cygwin.
Index: blockframe.c
===================================================================
RCS file: /cvs/src/src/gdb/blockframe.c,v
For "blockframe.c", please leave it as is. I'm already in enough
trouble for breaking old targets so I'd prefer to leave that part
untouched. It would only affect out-of-date targets anyway. The
up-to-date targets don't rely on that function.
Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.89
diff -u -p -r1.89 frame.c
--- frame.c 26 Mar 2003 00:00:07 -0000 1.89
+++ frame.c 27 Mar 2003 11:25:20 -0000
@@ -1419,26 +1419,6 @@ get_prev_frame (struct frame_info *this_
return this_frame->prev;
this_frame->prev_p = 1;
- /* 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.
- Sentinel frames should always be allowed to unwind. */
- /* NOTE: drow/2002-12-25: should there be a way to disable this
- check? It assumes a single small entry file, and the way some
- debug readers (e.g. dbxread) figure out which object is the
- entry file is somewhat hokey. */
- /* 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. */
- if (this_frame->type != DUMMY_FRAME && this_frame->level >= 0
- && inside_entry_file (get_frame_pc (this_frame)))
- {
- if (frame_debug)
- fprintf_unfiltered (gdb_stdlog,
- "Outermost frame - inside entry file\n");
- return NULL;
- }
-
/* 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 -
dummy frame PC's typically land in the entry func. Don't apply
For "frame.c", it doesn't break the current d10v and that is the only
target that the change would affect.. Rather than deleting the code,
though, can you instead disable it vis:
if (0
&& ....
and then add a comment giving a detailed rationale for why the test was
disabled. Consider that approved.
If the code is simply deleted, that knowledge will be lost, and in 6
months time we'll have someone trying to add that exact same test again ...
Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.123
diff -u -p -r1.123 i386-tdep.c
--- i386-tdep.c 26 Mar 2003 22:39:52 -0000 1.123
+++ i386-tdep.c 27 Mar 2003 11:25:21 -0000
Please post the i386 change separatly, that way it is easier for the
i386 maintainers to identify/review. I've no idea. The function may
well have been rewritten. frame_chain is deprecated.
Andrew