patch to robustify gnuv3_rtti_type

patch to robustify gnuv3_rtti_type

[Per Bothner]

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

Ok to check in?  This doesn't fix the real problem, which is that
gcj produces vtables that aren't properly abi-compliant.  Hopefully,
we'll fix that.  But for now, let's at least prevent gdb from crashing.

	* gnu-v3-abi.c (gnuv3_rtti_type):  Guard that vtable_symbol_name
	isn't NULL, which can happen with some gcj3.0-produced code.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

[-- Attachment #2: rtti.patch --]
[-- Type: text/plain, Size: 777 bytes --]

Index: gnu-v3-abi.c
===================================================================
RCS file: /cvs/src/src/gdb/gnu-v3-abi.c,v
retrieving revision 1.6
diff -u -r1.6 gnu-v3-abi.c
--- gnu-v3-abi.c	2002/01/04 18:20:19	1.6
+++ gnu-v3-abi.c	2002/01/19 20:33:49
@@ -239,7 +239,8 @@
      type_info object itself to get the class name.  But this way
      should work just as well, and doesn't read target memory.  */
   vtable_symbol_name = SYMBOL_DEMANGLED_NAME (vtable_symbol);
-  if (strncmp (vtable_symbol_name, "vtable for ", 11))
+  if (vtable_symbol_name == NULL
+      || strncmp (vtable_symbol_name, "vtable for ", 11))
     error ("can't find linker symbol for virtual table for `%s' value",
            TYPE_NAME (value_type));
   class_name = vtable_symbol_name + 11;

Re: patch to robustify gnuv3_rtti_type

[Daniel Jacobowitz]

On Sat, Jan 19, 2002 at 12:41:03PM -0800, Per Bothner wrote:
> Ok to check in?  This doesn't fix the real problem, which is that
> gcj produces vtables that aren't properly abi-compliant.  Hopefully,
> we'll fix that.  But for now, let's at least prevent gdb from crashing.
> 
> 	* gnu-v3-abi.c (gnuv3_rtti_type):  Guard that vtable_symbol_name
> 	isn't NULL, which can happen with some gcj3.0-produced code.

OK for now.  I'll see if we can cope with the vtables that it currently
emits, too.


-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: patch to robustify gnuv3_rtti_type

[Per Bothner]

Daniel Jacobowitz wrote:
>>	* gnu-v3-abi.c (gnuv3_rtti_type):  Guard that vtable_symbol_name
>>	isn't NULL, which can happen with some gcj3.0-produced code.
> 
> OK for now.

I checked it in.

> I'll see if we can cope with the vtables that it currently
> emits, too.

Well, I have a non-checked-in gcj path that is one step towards
fixing the vtables, in that it add sthe extra header words "in
front of" the vtable pointer.  I.e. I've allocated space in
the vtable for the rtti pointer, though leaving the pointer
null.  The next step is sctually generating the type_info
object.  It might be nice to actually *embed* the type_info
object inside the Class object, possibly reducing some
duplication.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: patch to robustify gnuv3_rtti_type

[Daniel Jacobowitz]

On Sat, Jan 19, 2002 at 04:15:27PM -0800, Per Bothner wrote:
> Daniel Jacobowitz wrote:
> >>	* gnu-v3-abi.c (gnuv3_rtti_type):  Guard that vtable_symbol_name
> >>	isn't NULL, which can happen with some gcj3.0-produced code.
> >
> >OK for now.
> 
> I checked it in.
> 
> >I'll see if we can cope with the vtables that it currently
> >emits, too.
> 
> Well, I have a non-checked-in gcj path that is one step towards
> fixing the vtables, in that it add sthe extra header words "in
> front of" the vtable pointer.  I.e. I've allocated space in
> the vtable for the rtti pointer, though leaving the pointer
> null.  The next step is sctually generating the type_info
> object.  It might be nice to actually *embed* the type_info
> object inside the Class object, possibly reducing some
> duplication.

Go look at gnuv3_rtti_type again.  It's misnamed; it does not use RTTI
at all.  It only looks that the vtable exists and has a name demangled to
'vtable for <Class>'.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: patch to robustify gnuv3_rtti_type

[Per Bothner]

Daniel Jacobowitz wrote:
> Go look at gnuv3_rtti_type again.  It's misnamed; it does not use RTTI
> at all.  It only looks that the vtable exists and has a name demangled to
> 'vtable for <Class>'.

Yes.  With my current patches (gcc and gdb), I get when debugging Java
runtime (written in C++):

(gdb) whatis source
type = Class *
(gdb) p *source
can't find class named `java::lang::Class', as given by C++ RTTI

That is actually an improvement.  The problem at this point is
inconsistent handling of namespaces bwteeen g++ and gcj.  gcj
emits a class named 'java.lang.Class' (including the periods),
while g++ emits plain 'Class'.  So gdb does not realize these are
the same class.  And neither g++ or gcj emits proper namespace
information.  I think this is one of the biggest stumbling-blocks
to proper Java debugging.

What is the current status of support for namepace-handling in gdb?
If we fix gcj so it emits the same debug into as g++ (i.e.
'java.lang.Class' is emitted as plain 'Class'), can gdb "do the
right thing" based on the mangled names?  If not, can gdb handle
dwarf2 namespace information (which g++ currently supresses)?
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: patch to robustify gnuv3_rtti_type

[Daniel Jacobowitz]

On Sun, Jan 20, 2002 at 12:43:45PM -0800, Per Bothner wrote:
> Daniel Jacobowitz wrote:
> >Go look at gnuv3_rtti_type again.  It's misnamed; it does not use RTTI
> >at all.  It only looks that the vtable exists and has a name demangled to
> >'vtable for <Class>'.
> 
> Yes.  With my current patches (gcc and gdb), I get when debugging Java
> runtime (written in C++):
> 
> (gdb) whatis source
> type = Class *
> (gdb) p *source
> can't find class named `java::lang::Class', as given by C++ RTTI
> 
> That is actually an improvement.  The problem at this point is
> inconsistent handling of namespaces bwteeen g++ and gcj.  gcj
> emits a class named 'java.lang.Class' (including the periods),
> while g++ emits plain 'Class'.  So gdb does not realize these are
> the same class.  And neither g++ or gcj emits proper namespace
> information.  I think this is one of the biggest stumbling-blocks
> to proper Java debugging.

Wait a second.  Are you debugging Java or C++ here?  Or are you
debugging a Java program and the C++ runtime, and the same thing is
accessible as java::lang::Class and java.lang.Class?

> What is the current status of support for namepace-handling in gdb?
> If we fix gcj so it emits the same debug into as g++ (i.e.
> 'java.lang.Class' is emitted as plain 'Class'), can gdb "do the
> right thing" based on the mangled names?  If not, can gdb handle
> dwarf2 namespace information (which g++ currently supresses)?

We are not currently ready for dwarf2 namespace information, as I
understand it.  Fixing it should be the work of a few hours, though. 
The state of namespaces through the rest of GDB is a little more
questionable.  I know the v3 support file needs changes.

Why do you currently emit java.lang.Class?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: patch to robustify gnuv3_rtti_type

[Per Bothner]

Daniel Jacobowitz wrote:
> Wait a second.  Are you debugging Java or C++ here?  Or are you
> debugging a Java program and the C++ runtime,

Yes, basically.  The bug I'm currently working on is a bug in the
run-time verifier (libjava/verify.cc).

> and the same thing is
> accessible as java::lang::Class and java.lang.Class?

Yes, basically. The Class and Object classes are handled specially
by the compiler, though I'm not sure that matters to the debugger.
In general, we have gcj create the "definition" of classes; we also
auto-generate C++ header files for the same classes so they can be
accessed by C++, for writing "native" methods  However, the Class
class is special, in that the the C++ version is written by hand.

In either case, we'd like gdb to realize that java::lang::Class
and java.lang.Class are the same, which seems to require namespace
support to do it properly.

> Why do you currently emit java.lang.Class?

Because is seemed the right thing to do, given gdb's lack of proper
namespace support - we just treat "java.lang.Object" as an atomic
name.  This fixes some problems and breaks others.

Also, gcj internally uses the fully-qualfied name "java.lang.Class"
internally.  Changing this will take some work, but if it will
give us proper namespace-aware debugging I'm willing to do it.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: patch to robustify gnuv3_rtti_type

[Daniel Berlin]

>
> What is the current status of support for namepace-handling in gdb?
> If we fix gcj so it emits the same debug into as g++ (i.e.
> 'java.lang.Class' is emitted as plain 'Class'), can gdb "do the
> right thing" based on the mangled names?  If not, can gdb handle
> dwarf2 namespace information (which g++ currently supresses)?
No, it can't, which is why i still haven't committed a patch to add it 
that Jason approved eons ago.
I'm going to just add a -gdwarf-3 switch, and make it dependent on that.

> -- 	--Per Bothner
> per@bothner.com   http://www.bothner.com/per/

Re: patch to robustify gnuv3_rtti_type

[Daniel Jacobowitz]

On Sat, Jan 19, 2002 at 12:41:03PM -0800, Per Bothner wrote:
> Ok to check in?  This doesn't fix the real problem, which is that
> gcj produces vtables that aren't properly abi-compliant.  Hopefully,
> we'll fix that.  But for now, let's at least prevent gdb from crashing.

By the way, with current GDB and gjc 3.0.3, I see a stabs debugging bug
that I mean to fix and a collection of assorted DWARF2 bugs.  I'll be
poking at these soon.


-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer