This is the mail archive of the insight@sources.redhat.com mailing list for the Insight project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Warning: Couldn't restore frame in current thread


Keith Seitz wrote:
> 
> On Wed, 2 May 2001, Holger Vogt wrote:
> 
> > gdb -nw is working without problems.
> >
> > In Insight either typing n, s, si to the console window or mouse-clicking to
> > the source window will generate the warning message. It appears for the
> > first time  after typing 'run' to the console window.
> 
> Wow, that is weird. The warning message you are displaying comes from gdb.
> I would not expect Insight to show this message at all. Something fishy
> must be going on...
> 
> What does gdb -v show? (If you're on cygwin, can you include the output of
> "gcc -v" and "uname -a", too?)
> 

Don't worry.  I have a patch already to cope with the change in the way
the type is created for (void *).  It is backward compatible, so we can
just make the change.

I decided to allow for (char *) to be dereferenced now, as this works
fine (like in the command line interface).  Only (void *) cannot be
dereferenced.

Please try the attached patch.


I still wonder why (void *) was tested used the name field and not the
type_code and whether the change (i.e., the removal of the name field of
VOID types) was intentional or a bug. 

For the ones that did not follow the thread, TYPE_CODE_VOID types now
have the name field empty (i.e. TYPE_NAME == NULL) -- previously it was
"void".  At least when they are the target_type of a TYPE_CODE_PTR type.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
Index: varobj.c
===================================================================
RCS file: /cvs/src/src/gdb/varobj.c,v
retrieving revision 1.17
diff -c -p -r1.17 varobj.c
*** varobj.c	2001/03/27 20:36:24	1.17
--- varobj.c	2001/05/02 02:35:16
*************** c_number_of_children (struct varobj *var
*** 1761,1767 ****
      case TYPE_CODE_PTR:
        /* This is where things get compilcated. All pointers have one child.
           Except, of course, for struct and union ptr, which we automagically
!          dereference for the user and function ptrs, which have no children. */
        switch (TYPE_CODE (target))
  	{
  	case TYPE_CODE_STRUCT:
--- 1761,1773 ----
      case TYPE_CODE_PTR:
        /* This is where things get compilcated. All pointers have one child.
           Except, of course, for struct and union ptr, which we automagically
!          dereference for the user and function ptrs, which have no children.
!          We also don't dereference void* as we don't know what to show.
!          We can show char* so we allow it to be dereferenced.  If you decide
!          to test for it, please mind that a little magic is necessary to
!          properly identify it: char* has TYPE_CODE == TYPE_CODE_INT and 
!          TYPE_NAME == "char" */
! 
        switch (TYPE_CODE (target))
  	{
  	case TYPE_CODE_STRUCT:
*************** c_number_of_children (struct varobj *var
*** 1770,1786 ****
  	  break;
  
  	case TYPE_CODE_FUNC:
  	  children = 0;
  	  break;
  
  	default:
! 	  /* Don't dereference char* or void*. */
! 	  if (TYPE_NAME (target) != NULL
! 	      && (STREQ (TYPE_NAME (target), "char")
! 		  || STREQ (TYPE_NAME (target), "void")))
! 	    children = 0;
! 	  else
! 	    children = 1;
  	}
        break;
  
--- 1776,1787 ----
  	  break;
  
  	case TYPE_CODE_FUNC:
+ 	case TYPE_CODE_VOID:
  	  children = 0;
  	  break;
  
  	default:
! 	  children = 1;
  	}
        break;
  

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]