In this change we rewrite the Call sample with a few enhancements to
introduce all call types:

- JIT to JIT
- JIT to native
- JIT to computed native
- Native to JIT

The test computation is still the same, i.e. we still compute a double
sum, however we do it in several different ways so as to test calls
both to and from JIT/native to ensure all paths are working as expected.

This is particularly useful for platforms which have special handling
of function pointers, such as AIX and z/OS.

Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>

Now that we have full support for calls on z/OS we can safely enable
all Tril tests which were previously disabled.

Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>

OMR nor any downstream projects support 31-bit XPLINK to OS linkage,
and the support is also not present in the rest of the compiler. This
code block is slated for deprecation as we don't anticipate it being
used.

Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>

The path for loading double arguments for outgoing calls was disabled
within the `J9_PROJECT_SPECIFIC` ifdef, and as such double arguments
were not being loaded for outgoing calls.

We fix this by moving the case label outside of the ifdef. In addition
there is no need to check for `getNumIntegerArgumentRegisters` before
incrementing the GPR index, similarly to the integer cases since the
`getIntegerArgumentRegister` API will already return the default value
if the register index does not participate in the calling convention.

Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>

In addition there are some problems with the CMakeLists.txt definition
for this sample, likely because the sample has been disabled due to
lack of support for passing arguments to tests generated. We also fix
this minor issue as part of this commit.

Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>

The current LinkageTest is geared towards running on x86. Now that we
have full support for calls on z/OS this test can be enhanced. The
current test has implicit assumptions on the number of arguments that
are passed on the stack for a particular calling convention.

To be more exhaustive we greatly expand the scope of the testing here
to the following:

- JIT to {jit|native} calls to functions of different number of
arguments ranging from 1 to 9 with the same argument type
- JIT to {jit|native}calls to functions of different number of
arguments ranging from 1 to 9 with mixed argument types

This ends up running 136 different tests (+ 4 for invalid linkage)
which covers most cases for passing arguments to and from JIT methods.

Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>

System linkage OMR compiled function bodies need to come with a proper
function descriptor to adhere to XPLINK linkage on z/OS. Currently OMR
compiled functions return to the user the entry point of the function
(function's address), however on z/OS we should instead be returning
the Function Descriptor data structure.

This change implements the Function Descriptor as a snippet in the
compiled body, similar to the PPA1 and PPA2 snippets. The descriptor is
then baked into the function literal pool, and when we emit the snippet
we will update the method address which is used by external APIs.

When dispatching to other native methods (JIT or C-native) we must also
call through the function descriptor.

Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>

Some platforms, such as AIX and z/OS, use metadata structures to
represent "pointer to a function" retrieved via the C `&` operator. On
AIX and z/OS these are called Function Descriptors. We need to
disambiguate between the "pointer to a function" and "address of entry
point of a function".

Currently `getCodeStart` API returns the latter, however this is not
what we want when we query for the result of a compilation in Tril and
JitBuilder. We want the former, i.e. the value of the "pointer to a
function" of the JIT compiled method.

We use the method symbol `getAddress` API here to query for such
values, and ensuring this value is set properly after binary encoding.
It is currently set to the result of `getCodeStart` by default, so no
change in value. If platforms have Function Descriptors it is up to
those linkages to update this value once the location of the Function
Descriptor is known.

Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>

Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>

The indentation in it's current state is very confusing [1], and at
first sight one may think the:

```
     if (comp->getCurrentMethod() == NULL)
        {
        comp->getMethodSymbol()->setMethodAddress(cg->getBinaryBufferStart());
        }
```

piece of code is guarded by the `if (cg->getAheadOfTimeCompile() &&`
check, which is what I first thought, but upon a more careful
inspection the indentation was hiding this is not the case.

[1] https://github.com/eclipse/omr/blob/31db81f3d84a431736ac7a9ff1b3980158fae258/compiler/codegen/OMRCodeGenPhase.cpp#L182-L202

Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>

Now that we have full support for calling methods on z/OS we can enable
the full suite of extended JitBuilder tests on the farm.

Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>

This reverts commit eb3b237.

Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>

Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>

Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>

Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>

Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>

Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>

These helper macros will skip tests based on architecture and operating
system combinations.

Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>