Re: [patch] a few more frame_in_dummy's

Re: [patch] a few more frame_in_dummy's

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 88 bytes --]

[list changed to insight@]

Good catch, thanks!  I've checked it in for you :-)

Andrew

[-- Attachment #2: mailbox-message://ac131313@movemail/fsf/gdb/patches#8505018 --]
[-- Type: message/rfc822, Size: 4647 bytes --]

From: David Carlton <carlton@math.stanford.edu>
To: gdb-patches@sources.redhat.com
Cc: Keith Seitz <keiths@redhat.com>, Andrew Cagney <ac131313@ges.redhat.com>
Subject: [patch] a few more frame_in_dummy's
Date: 11 Nov 2002 13:15:31 -0800
Message-ID: <ro1heen3j0s.fsf@jackfruit.Stanford.EDU>

Andrew's recent patch deprecating frame_in_dummy missed some instances
in gdbtk; here's a patch changing them over.  It seems obvious; I'll
apply it unless somebody complains.

David Carlton
carlton@math.stanford.edu

2002-11-11  David Carlton  <carlton@math.stanford.edu>

	* generic/gdbtk-stack.c (get_frame_name): Replace call to
	frame_in_dummy with one to deprecated_frame_in_dummy.
	* generic/gdbtk-cmds.c (gdb_loc): Ditto.

Index: gdbtk-stack.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-stack.c,v
retrieving revision 1.9
diff -u -p -r1.9 gdbtk-stack.c
--- gdbtk-stack.c	23 Apr 2002 00:03:09 -0000	1.9
+++ gdbtk-stack.c	11 Nov 2002 21:11:22 -0000
@@ -520,7 +520,7 @@ get_frame_name (Tcl_Interp *interp, Tcl_
   enum language funlang = language_unknown;
   Tcl_Obj *objv[1];
 
-  if (frame_in_dummy (fi))
+  if (deprecated_frame_in_dummy (fi))
     {
       objv[0] = Tcl_NewStringObj ("<function called from gdb>\n", -1);
       Tcl_ListObjAppendElement (interp, list, objv[0]);
@@ -537,7 +537,7 @@ get_frame_name (Tcl_Interp *interp, Tcl_
     find_pc_line (fi->pc,
 		  fi->next != NULL
 		  && !fi->next->signal_handler_caller
-		  && !frame_in_dummy (fi->next));
+		  && !deprecated_frame_in_dummy (fi->next));
 
   func = find_pc_function (fi->pc);
   if (func)
Index: gdbtk-cmds.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-cmds.c,v
retrieving revision 1.58
diff -u -p -r1.58 gdbtk-cmds.c
--- gdbtk-cmds.c	10 Oct 2002 23:55:36 -0000	1.58
+++ gdbtk-cmds.c	11 Nov 2002 21:11:17 -0000
@@ -2273,7 +2273,7 @@ gdb_loc (ClientData clientData, Tcl_Inte
 	  sal = find_pc_line (selected_frame->pc,
 			      selected_frame->next != NULL
 			      && !selected_frame->next->signal_handler_caller
-			      && !frame_in_dummy (selected_frame->next));
+			      && !deprecated_frame_in_dummy (selected_frame->next));
 	}
       else
         {

Re: [patch] a few more frame_in_dummy's

[David Carlton]

Incidentally, does core GDB really depend on the files in
SUBDIR_GDBTK_OBS?  If not, would it be possible to reorganize
Makefile.in to reflect that fact?  Because the way that I found those
frame_in_dummy problems was that I was trying to build GDB in a source
tree that included insight and where -Werror was turned on; it seems
to me unfortunate that I had to fix problems in insight before I could
get GDB to compile.

David Carlton
carlton@math.stanford.edu

Re: [patch] a few more frame_in_dummy's

[Keith Seitz]

On 15 Nov 2002, David Carlton wrote:

> Incidentally, does core GDB really depend on the files in
> SUBDIR_GDBTK_OBS?  If not, would it be possible to reorganize
> Makefile.in to reflect that fact?  Because the way that I found those
> frame_in_dummy problems was that I was trying to build GDB in a source
> tree that included insight and where -Werror was turned on; it seems
> to me unfortunate that I had to fix problems in insight before I could
> get GDB to compile.

I'm working on ripping everything Insight-related out of core gdb. I've 
submitted at least one RFC on how to complete this (one on init.c and one 
on options processing), but I haven't found the time to finish the work 
just yet. I seem to always get side-tracked by something.

I'll see if I can't find some time next week to at least revisit some of 
this.

Keith

Re: [patch] a few more frame_in_dummy's

[David Carlton]

On Fri, 15 Nov 2002 11:22:17 -0800 (PST), Keith Seitz <keiths@redhat.com> said:
> On 15 Nov 2002, David Carlton wrote:

>> Incidentally, does core GDB really depend on the files in
>> SUBDIR_GDBTK_OBS?  If not, would it be possible to reorganize
>> Makefile.in to reflect that fact?  Because the way that I found those
>> frame_in_dummy problems was that I was trying to build GDB in a source
>> tree that included insight and where -Werror was turned on; it seems
>> to me unfortunate that I had to fix problems in insight before I could
>> get GDB to compile.

> I'm working on ripping everything Insight-related out of core
> gdb. I've submitted at least one RFC on how to complete this (one on
> init.c and one on options processing), but I haven't found the time
> to finish the work just yet. I seem to always get side-tracked by
> something.

Ah, I see.

> I'll see if I can't find some time next week to at least revisit
> some of this.

Thanks.  Though please don't hurry on my account: it's quite rare for
insight to cause problems when compiling GDB, and probably most such
issues will be as easily fixed as this one was.  (On the other hand,
if you're waiting for an excuse to get back to this, I'm happy to
provide one!)

David Carlton
carlton@math.stanford.edu

Re: [patch] a few more frame_in_dummy's

[Andrew Cagney]

> Incidentally, does core GDB really depend on the files in
> SUBDIR_GDBTK_OBS?  If not, would it be possible to reorganize
> Makefile.in to reflect that fact?  Because the way that I found those
> frame_in_dummy problems was that I was trying to build GDB in a source
> tree that included insight and where -Werror was turned on; it seems
> to me unfortunate that I had to fix problems in insight before I could
> get GDB to compile.

The configury assumes that you want to build everything in your tree (if 
insight is present, then insight).  You can disable this (from memory) 
by configuring with --disable-gdbtk.

Andrew