RFC: [patch] Circunvent GCC/GDB problem with (void*) types

RFC: [patch] Circunvent GCC/GDB problem with (void*) types

[Fernando Nasser]

GDB (or GCC) is recently experiencing a problem where the (void *) types
are not properly identified with the type name "void" in the target
type.  As a consequence, Insight is dying if some sequence of operations
are made on the (void *) variable shown in the variable windows.

I will notify GDB people about that, but I saw no reason for us to
depend on the target type name.  The target type being TYPE_CODE_VOID
should be enough.  

The (char *) target types would need that trick as they are of
TYPE_CODE_INT type (don't ask me why) but have "char" as the type name. 
However, I saw no reason for disallowing the dereferencing of (char *)
either.  It looks like a useful feature.  If you do not agree, please
let me know.

The attached patch makes Insight work regardless.

ChangeLog:

	* varobj.c (c_number_of_children): Check for target type of void*,
	not the target type name.  Allow dereferencing char*.

-- 
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;
  

Re: RFC: [patch] Circunvent GCC/GDB problem with (void*) types

[Keith Seitz]

On Mon, 7 May 2001, Fernando Nasser wrote:

> The (char *) target types would need that trick as they are of
> TYPE_CODE_INT type (don't ask me why) but have "char" as the type name.
> However, I saw no reason for disallowing the dereferencing of (char *)
> either.  It looks like a useful feature.  If you do not agree, please
> let me know.

The reason for not dereferencing char*: we always printed the contents of
the string, so there was no need to dereference it.

But you are right, there really is no overwhelming reason not to allow
this. (It is, afterall, a UI decision, not a backend one.)

Keith

Re: RFC: [patch] Circunvent GCC/GDB problem with (void*) types

[Fernando Nasser]

Keith Seitz wrote:
> 
> On Mon, 7 May 2001, Fernando Nasser wrote:
> 
> > The (char *) target types would need that trick as they are of
> > TYPE_CODE_INT type (don't ask me why) but have "char" as the type name.
> > However, I saw no reason for disallowing the dereferencing of (char *)
> > either.  It looks like a useful feature.  If you do not agree, please
> > let me know.
> 
> The reason for not dereferencing char*: we always printed the contents of
> the string, so there was no need to dereference it.
> 
> But you are right, there really is no overwhelming reason not to allow
> this. (It is, afterall, a UI decision, not a backend one.)
> 

The only thing we do have an argument is (void *), which is the fact
that we don't know how to display it.  The GDB command line interface
does the same; it prints something like "attempt to dereference a void
pointer".

I don't have any strong opinion about this.  So, if people prefer to
disallow dereferencing char* just let me know.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: RFC: [patch] Circunvent GCC/GDB problem with (void*) types

[Keith Seitz]

On Mon, 7 May 2001, Fernando Nasser wrote:

> The only thing we do have an argument is (void *), which is the fact
> that we don't know how to display it.  The GDB command line interface
> does the same; it prints something like "attempt to dereference a void
> pointer".
>
> I don't have any strong opinion about this.  So, if people prefer to
> disallow dereferencing char* just let me know.

I don't think I care one way or the other: I say allow it. Less code, less
exceptions to rules. I can remember dereference anything but void* easier
than deref anything but void* and char*. :-)

Keith

Re: RFC: [patch] Circunvent GCC/GDB problem with (void*) types

[Fernando Nasser]

Checked in.


Fernando Nasser wrote:
> 
> GDB (or GCC) is recently experiencing a problem where the (void *) types
> are not properly identified with the type name "void" in the target
> type.  As a consequence, Insight is dying if some sequence of operations
> are made on the (void *) variable shown in the variable windows.
> 
> I will notify GDB people about that, but I saw no reason for us to
> depend on the target type name.  The target type being TYPE_CODE_VOID
> should be enough.
> 
> The (char *) target types would need that trick as they are of
> TYPE_CODE_INT type (don't ask me why) but have "char" as the type name.
> However, I saw no reason for disallowing the dereferencing of (char *)
> either.  It looks like a useful feature.  If you do not agree, please
> let me know.
> 
> The attached patch makes Insight work regardless.
> 
> ChangeLog:
> 
>         * varobj.c (c_number_of_children): Check for target type of void*,
>         not the target type name.  Allow dereferencing char*.
> 
> --
> 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;
> 

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

[patch] Fix memory leak.

[Fernando Nasser]

I have checked this in.

	* varobj.c (c_number_of_children): Fix memory leak. Delete unwanted
	old variables, not just unregister them.


Index: varobj.c
===================================================================
RCS file: /cvs/src/src/gdb/varobj.c,v
retrieving revision 1.18
diff -c -p -r1.18 varobj.c
*** varobj.c	2001/05/10 16:44:56	1.18
--- varobj.c	2001/05/10 16:45:36
*************** value_of_root (struct varobj **var_handl
*** 1639,1645 ****
  	    {
  	      tmp_var->obj_name = 
  		savestring (var->obj_name, strlen (var->obj_name));
! 	      uninstall_variable (var);
  	    }
  	  else
  	    {
--- 1639,1645 ----
  	    {
  	      tmp_var->obj_name = 
  		savestring (var->obj_name, strlen (var->obj_name));
! 	      varobj_delete (var, NULL, 0);
  	    }
  	  else
  	    {
                                                                               


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9