Re: New C++ ABI: patches.

[Bryce McKinlay <bryce at albatross dot co dot nz>]

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)[0];
>     ((void **)this)[0] = (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.

Possible solutions:

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)

or

b) adjust c++ so that it special-cases "extern "Java"" classes and
doesn't do the vtable pointer adjustment.

or

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
anyway?

> 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)!

regards

  [ bryce ]