Description Oleg Smetanin 2006-01-16 07:51:26 EST

Currently, SWT Browser widget (which uses embedded Mozilla browser) does not work properly on Itanium. In fact, it crashes with a core dump. The problem here lies in the fact that SWT Browser widget uses Mozilla code indirectly through XPCOM ABI. Is was OK on 32 bit platforms since C++ compiler generates object code which exactly matches XPCOM binary specification. But things have changed on Itanium because C++ ABI on this platform is not compatible with XPCOM due to introduction of new addressing scheme which uses GP register. 

You can find out more about Itanium C++ ABI here: http://www.codesourcery.com/cxx-abi/abi.html

To enable Browser widget support on Itanium, the following should be done:

1) Java tool from org.eclipse.swt.tool which is used to generate native C code should be modified to generate slighly different code on Itanium. The generated VtblCall*() methods would look like the following:

struct PLABEL_DESCRIPTOR
{
    jlong   func_address;
    jlong   gp_value;
};
JNIEXPORT jint JNICALL XPCOM_NATIVE(VtblCall__IJ_3Z)
    (JNIEnv *env, jclass that, jint arg0, jlong arg1, jbooleanArray arg2)
{
    jboolean *lparg2=NULL;
    jint rc = 0;
    XPCOM_NATIVE_ENTER(env, that, VtblCall__IJ_3Z_FUNC);
    if (arg2) if ((lparg2 = env->GetBooleanArrayElements(arg2, NULL)) == NULL) goto fail;
    rc = (jint)((jint (STDMETHODCALLTYPE *)(jlong, jboolean*))(*(PLABEL_DESCRIPTOR **)arg1 + arg0))(arg1, lparg2);
fail:
    if (arg2 && lparg2) env->ReleaseBooleanArrayElements(arg2, lparg2, 0);
    XPCOM_NATIVE_EXIT(env, that, VtblCall__IJ_3Z_FUNC);
    return rc;
}

2) Since some XPCOM objects are created on SWT side, some modifications in Java code should be made too. This is just an example of how it could look:

public XPCOMObject(int[] argCounts) {
    long /*int*/[] callbackAddresses = new long /*int*/[argCounts.length];
    for (int i = 0, length = argCounts.length; i < length; i++){
        if ((Callbacks[i][argCounts[i]]) == null) {
            Callbacks[i][argCounts[i]] = new Callback(this.getClass(), "callback"+i, argCounts[i] + 1, true); //$NON-NLS-1$
        }
        callbackAddresses[i] = Callbacks[i][argCounts[i]].getAddress();
        if (callbackAddresses[i] == 0) SWT.error (SWT.ERROR_NO_MORE_CALLBACKS);
    }   
    long pVtable = XPCOM.buildVTable(callbackAddresses);
    ppVtable = XPCOM.PR_Malloc(OS.PTR_SIZEOF);
    XPCOM.memmove(ppVtable, new long /*int*/[] {pVtable}, OS.PTR_SIZEOF);
    ObjectMap.put(new LONG(ppVtable), this);
}

... where buildVTable() is a native C func which could look like the following (again, just an example of how it should work on Itanium):

JNIEXPORT jlong JNICALL Java_org_eclipse_swt_internal_mozilla_XPCOM_buildVTable
  (JNIEnv *env, jclass that, jlongArray arg0)
{
    jlong* pArg0 = NULL;
    if (arg0) 
    {
        pArg0 = env->GetLongArrayElements(arg0, NULL);
    }
    int iCount = env->GetArrayLength(arg0);
    jlong* pVTable = new jlong[iCount * 2];
    jlong** ppArg0 = (jlong**)pArg0;
    for (int i = 0, j = 0; i < iCount; i++, j += 2)
    {
        pVTable[j]      = *(ppArg0[i]);
        pVTable[j + 1]  = *(ppArg0[i] + 1);
    }
    if (arg0 && pArg0) 
    {
        env->ReleaseLongArrayElements(arg0, pArg0, JNI_ABORT);
    }
    return (jlong)pVTable;
}

This function would look slightly different on 32-bit and 64-bit platforms (which is easily achieved using macros). Also, there is a possibility to move all vtable logic to Java side, but I think we should avoid unnecessary JNI calls to save perfomance.