This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


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

Changing the "enclosing_type" of a value structure


Hi, all...

I found a number of places in the gdb sources where we are changing the
enclosing_type field of a value structure.  For instance, in
valops.c:3490ff,  the following is done:

   /* If we have the full object, but for some reason the enclosing
      type is wrong, set it *//* pai: FIXME -- sounds iffy */
   if (full)
     {
       VALUE_ENCLOSING_TYPE (argp) = real_type;
       return argp;
     }

NB: it is NOT a good idea to blythely change the enclosing type of a
value, since allocate_value uses the length of the enclosing type to
figure out the size of the data area to allocate at the end of the
"value structure".  So if the new enclosing_type is bigger than the one
you passed to allocate_value, and you ever go to read in the data, you
will stomp whatever happens to be after this value structure in memory,
causing all sorts of badness later on...  This bit of code was causing a
crash for just this reason when I was viewing member objects of a C++
class.

There are other cases like this (valops.c:791ff):

  /* Get target memory address */
  arg2 = value_from_pointer (lookup_pointer_type (VALUE_TYPE (arg1)),
                 (VALUE_ADDRESS (arg1)
                  + VALUE_OFFSET (arg1)
                  + VALUE_EMBEDDED_OFFSET (arg1)));

  /* This may be a pointer to a base subobject; so remember the
     full derived object's type ... */
  VALUE_ENCLOSING_TYPE (arg2) = lookup_pointer_type(VALUE_ENCLOSING_TYPE
(arg1));

Which happens to work because these are both pointers, and so have the same
size...

My software fascist side says you should NEVER be allowed to change the
enclosing_type of a value without at least putting in an assert making
sure that the new enclosing_type's length is <= that of the old
enclosing type.  After all, making an error here may cause memory
corruption in the application, which is generally pretty unpleasant to
track down.

It might even be good to introduce a function like:

value_ptr
value_change_enclosing_type (value_ptr val, type *new_type)
{
  if (TYPE_LENGTH (new_type) <= TYPE_LENGTH (VALUE_ENCLOSING_TYPE (val)))
    {
      VALUE_ENCLOSING_TYPE(val) = new_type;
      return val;
    }
  else
    {
       return (value_ptr) xrealloc (val, sizeof (struct type)
                                    + TYPE_LENGTH (new_type));
    }
}

and use that everywhere that we were just reassigning before.

If this makes sense to people (and/or I am not missing something
obvious), then I will whip up a patch and submit it.

Jim
-- 
Jim Ingham                                 jingham@apple.com
Apple Computer



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