our ppc specific varargs changes

[Kevin Hendricks <khendricks at ivey dot uwo dot ca>]

Hi Michael,

Basically, I don't think how ppc does va_args will ever change .

Using the va_copy macro is considered the "right way" to handle the first case
which I have no problem with (although some recent glibc builds are playing
with __va_copy vs va_copy which is a real hassle).

As Jason's later notes point out, the real problem is passing pointers to
va_list types.  This works on every Linux platform but ours.  Imagine pointers
to pointers to va_list types.  

If we are stuck with this (a very bad choice since there seems to be NO true
underlying reason for this type of va_list) then there really should be
official macros to reference and dereference va_list types and people should be
forced to use them just like va_copy  (such as a va_pointer_to() ...)

Frankly, I would vote strongly to change the va_list type to be the same as
under x86 Linux even if it forced a complete recompile of everything.  We
(the ppc users and distributions) are small enough now that this change (just
like the glibc 2.1 change which was binary incompatible) could actually be
done.  In the future it will be impossible.  

By the way, although Richard holds the sys V abi dear, I have found numerous
places in the passing of doubles and long longs on the outgoing parameter stack
that either fail to meet the sys V abi or flipflop depending on which gcc/egcs
I use. 

The jdk uses a sysInvokeNative routine that dynamically builds a call to
whatever method signature is given and if written according to the abi, it
won't work on doubles passed out on the parameter stack (more fp params than
registers).

Here are some code snippets that illustrate the va_list problems and our macros
to solve them:

Here we could of used __va_copy or va_copy or whatever the powers
that be seem to change it to this week.  Instead we simply did
the following:

#define VA_ASSIGN(VA1,VA2) memcpy((VA1),(VA2),sizeof(va_list))
#else
#define VA_ASSIGN(VA1,VA2) (VA1) = (VA2)
#endif
 
static jobject JNICALL
jni_NewObject(JNIEnv *env, jclass clazz, jmethodID methodID, ...)
{
    jobject result;
    va_list args;
    JNI_PushArgsType a;
    va_start(args, methodID);
    VA_ASSIGN(a.v, args);
    result = jni_Construct(env, clazz, methodID, jni_PushArgumentsVararg, a);
    va_end(args);
    return result;
} 

This one was harder to find since it only occurred when a "va_list args"
was passed in as one of the parameters and then passed out as &args prior
to our change.  So the target expected a pointer to a va_list and 
before our fix we were dereferencing a single element array.

This is an example of what Jason was saying.  

/* fix for varargs differences */
#if defined(__powerpc__)
#define VARGS(x) (x)
#else
#define VARGS(x) (&x)
#endif

static ResultType JNICALL \
jni_Call##Result##MethodV(JNIEnv *env, jobject obj, \
                          jmethodID methodID, va_list args) \
{ \
    ResultType result; \
\
    result = jni_Invoke(env, obj, methodID, \
                        jni_PushArgumentsVararg, VARGS(args), \
                        INVOKE_VIRTUAL | retType).unionType; \
    return result; \
} \


Here is what the target looked like:

static jvalue
jni_Invoke(JNIEnv *env, jobject self, jmethodID methodID,
           JNI_PushArguments_t pushArguments, void *args,
           int info);



My final question is this:

Other than the example in the abi, does it ever clearly state that va_list must
be done this way?  If so, I could not find it.  

Richard says other OS's use this va_list type (I am sure he is right but I have
never seen one, I don't think sparc does or AIX alhtough sparc's is a bit  like
ours).  

Is there any technical justification for this (other than the abi)?  I
felt this way about the default to unsigned-char versus signed-char but David
and Gary Thomas explained there were actual performance differences that
supported the idea of ppc defaulting to unsigned char and that makes everything
okay in my book.

This is my last post on this, since I don't think anything will change, but I
did want to at least get the issues aired.

Sorry to fill up your inboxes.

Kevin