[PATCH RFC] Problem with pascal objects.

[Pierre Muller <muller at cerbere dot u-strasbg dot fr>]

   I have still some very pascal specific problems with GDB.
I will try to explain this problem as simply as possible.

Some Pascal Compiler have both classes and Objects
(classes are similar to C++ classes in the sense that they are just
invisible pointers to a record).

On the contrary pascal objects are the record itself.

Pascal objects are then defined as

type
        PBaseObject = ^TBaseObject;
        TBaseObject = object
             x,y : longint;
         end;

       PDerivedObject = ^TDerivedObject;
       TDerivedObject = object(TBaseObject)
            z : longint;
       end;

       PIndependentObject = ^TIndependentObject;
       TIndependentObject = object
            x,y,z : longint;
       end;

        PBaseRecord = ^TBaseRecord;
        TBaseRecord = Record
             x,y : longint;
         end;

       PDerivedRecord = ^TDerivedRecord;
       TDerivedRecord = Record
            x,y,z : longint;
       end;

var
      BO : PBaseObject;
       BD : PDerivedObject;
      RO : PBaseRecord;
       RD : PDerivedRecord;

begin
    BD:=new(PDerivedObject);
    BD^.x:=1;BD^.y:=2;BD^.z:=3;
    BO:=BD;
    RD:=new(PDerivedRecord);
    RD^.x:=4;RD^.y:=5;RD^.z:=6;
    RO:=pbaserecord(RD);
end.

Break at last line, I can get the following results

Breakpoint 1, main () at testobj.pp:40
40      end.
(gdbpas) p pederivedobject(bo)^
No symbol "PEDERIVEDOBJECT" in current context.
(gdbpas) p pderivedobject(bo)
$1 = (PDERIVEDOBJECT) $14e9c
(gdbpas) p pderivedobject(bo)^
$2 = {<TBASEOBJECT> = {X = 1, Y = 2}, Z = 65538}
(gdbpas) p pindependentobject(bo)^
$3 = {X = 1, Y = 2, Z = 3}
(gdbpas)

Clearly the problem only happens because the tderivedobject
is a child of tbaseobject.

For normal records, I never get such problems.

I found out by debugging GDB that
the problem is that the value_ptr for the expression "pderivedobject(bo)^"
contains "Tderivedobject" as type field
and "TBaseObject" as enclosing_type field.
   As the size of the enclosing_type is used to retrieve the data from 
debuggee memory,
the z field is not read at all.

   The fact that pindependentobject  typecast works correctly seems to
indicate that this problem is object/class specific.

   I found a simple solution to the problem,
but I don't know if this is an acceptable patch.

2000-12-01  Pierre Muller <muller@ics.u-strasbg.fr>
		  * valops.c (value_fetch_lazy): use biggest size from type and 
enclosing_type.



--- origdb/valops.c	Sun Apr  9 15:02:10 2000
+++ gdb/valops.c	Fri Dec  1 10:30:30 2000
@@ -515,8 +515,13 @@
  {
    CORE_ADDR addr = VALUE_ADDRESS (val) + VALUE_OFFSET (val);
    int length = TYPE_LENGTH (VALUE_ENCLOSING_TYPE (val));
-
    struct type *type = VALUE_TYPE (val);
+  /* In some case the enclosing type end up smaller as the
+     type at least for pascal */
+  int blength = TYPE_LENGTH (type);
+  if (blength > length)
+    length = blength;
+
    if (GDB_TARGET_IS_D10V
        && TYPE_CODE (type) == TYPE_CODE_PTR
        && TYPE_TARGET_TYPE (type)



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99