[RFA]: Java baseclass offset patch (Was Re: question about gdb)

[Daniel Berlin]

Tom Tromey <tromey@cygnus.com> writes:

> Daniel> There are a few places where virtual baseclass botch can get
> Daniel> printed.  What line/file is printing the one you are seeing,
> Daniel> so i can explain what the problem is.
> 
> Now I can't reproduce it.
> Next time I'll attach tot he running gdb and submit a real bug report.
> 
> Tom

I can tell you how to reproduce it, if you tell me if it's the same
one you are seeing (ie you are doing the same type of thing).

class hwbase
{
        public String q;
}
public class hw extends hwbase
{
        public String s;
        public hw (String str)
        {
                super();
                s=str;
        }
        public static void main(String [] arg)
        {
                hw o = new hw("hello\n");
                System.out.println(o.s);
        }
}


break hw::main
run
next
p *o.s

It's happening because it's trying to find the baseclass offset of a
java class, and can't figure out how, so it botches. My previous patch
just made it stop erroring out, because it would continue on, and be
happy. This patch makes it actually find the offset properly.

Okay to commit to sourceware (I didn't put the strcmp in vb_match
because vb_match does other things, and is supposed to be specific to
g++).

--Dan

Index: values.c
===================================================================
RCS file: /cvs/src/src/gdb/values.c,v
retrieving revision 1.9
diff -c -3 -p -r1.9 values.c
*** values.c	2000/07/30 01:48:27	1.9
--- values.c	2000/09/09 23:46:49
*************** baseclass_offset (struct type *type, int
*** 1238,1248 ****
           in the fields.  */
        for (i = n_baseclasses; i < len; i++)
  	{
  	  if (vb_match (type, i, basetype))
  	    {
  	      CORE_ADDR addr
! 	      = unpack_pointer (TYPE_FIELD_TYPE (type, i),
! 				valaddr + (TYPE_FIELD_BITPOS (type, i) / 8));
  
  	      return addr - (LONGEST) address;
  	    }
--- 1238,1254 ----
           in the fields.  */
        for (i = n_baseclasses; i < len; i++)
  	{
+ 	  /* For GCJ, we have a boffset field that should give us the
+ 	     base offset */
+ 	  if (current_language->la_language == language_java && !strcmp(TYPE_FIELD_NAME(type, i), "boffset"))
+ 	    {
+ 	      return unpack_pointer(TYPE_FIELD_TYPE(type, i), valaddr+(TYPE_FIELD_BITPOS (type, i) / 8));
+ 	    }
  	  if (vb_match (type, i, basetype))
  	    {
  	      CORE_ADDR addr
! 		= unpack_pointer (TYPE_FIELD_TYPE (type, i),
! 				  valaddr + (TYPE_FIELD_BITPOS (type, i) / 8));
  
  	      return addr - (LONGEST) address;
  	    }
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.663
diff -c -3 -p -r1.663 ChangeLog
*** ChangeLog	2000/09/06 15:23:04	1.663
--- ChangeLog	2000/09/09 23:46:50
***************
*** 1,3 ****
--- 1,7 ----
+ 2000-09-09  Daniel Berlin  <dberlin@redhat.com>
+ 
+ 	* values.c (baseclass_offset): Handle GCJ java baseclass offset properly
+ 
  2000-09-06  H.J. Lu  <hjl@gnu.org>
  
  	* TODO: Add hardware watchpint problems on x86 OSes for 5.1.