This is the mail archive of the
mailing list for the Java project.
Re: New C++ ABI: patches.
Alexandre Petit-Bianco wrote:
> Alexandre Petit-Bianco writes:
> > For some reasons, the first word of _Jv_intClass points in the
> > middle of the vtbl instead pointing at its beginning.
> I can see that the vtbl is ajusted before being stored:
> * movl _ZTVN4java4lang5ClassE@GOT(%ebx), %eax
> movl $0, 8(%edi)
> movl 56(%esi), %ecx
> movl $0, 20(%edi)
> * addl $8, %eax
> cmpw $86, %dx
> * movl %eax, (%edi)
> $edi contains `this.' I'm trying to understand why this code gets
> generated. Note that if I introduce this in the copy constructor:
> void *p = ((void **)this);
> ((void **)this) = (void *)((char *)p-2*sizeof (void *));
My theory on this:
The new C++ ABI stores extra fields at a negative offset in the vtable.
Given Java's simple inheritence model, there are two fields there: the
RTTI pointer (at -1) and offset-to-top (at -2, which in the case of Java
classes would always be zero because there are no more fields).
In the case of a Java class, gcj, rather than c++, generates the vtable,
but it does not generate these extra two negative-offset fields. Thats
ok (unless you want to use RTTI), because gcj also generates the
constructors, and naturally sets the vtable pointer to point to offset 0
in the vtable symbol (and native constructors arn't allowed in Java).
However, when you pull tricks to static allocate Java objects, as is
done for the primitive type classes, no gcj-generated constructor is
used. The c++ compiler looks at the inheritence of the java class,
calculates how many extra negative-offset fields there should, and
generates a constructor which offsets the vtable pointer by the
appropriate amount from its symbol.
a) adjust gcj so that it generates the extra two fields and offsets its
vtable pointers just like c++ does (this is REQUIRED if we want to
support RTTI and properly conform to the ABI)
b) adjust c++ so that it special-cases "extern "Java"" classes and
doesn't do the vtable pointer adjustment.
c) just use the explicit-setting-of-this hack in this case, because its
the only place where we should ever need to do something like this
> I did a build on Alpha: `Hellow World' crashes, but I'm having a hard
> to time debuging it because of the shared libraries. When built with
> `-static' `Hello World' just misbehaves but doesn't crash :-(
One possibility: there is something hairy going on right now in
natSystem::init_properties. It calls into TimeZone, which has a
System.getProperty() in its static initializer: infinate recursion. What
I can't figure out is why this _doesn't_ crash (for me)!
[ bryce ]