Dalvik: Ensure that the array length complies with the final specifier

JSR-133, which Android 4 should comply with, "final" fields should be
visible to all threads at the time the constructor exits, regardless of
synchronization. This behaviour should also apply to the array lengths
as they are regarded as equivalent in behaviour to "final" fields.
Non-final fields require explicit synchronization in Java for them to be
accessed correctly.

The Dalvik VM in Android ensures constructors for ordinary object behave
properly by inserting a memory barrier ("DMB") on their return if the
object's class has a "final" field.

The issue, however, is that while Dalivk inserts a barrier in
constructors, it doesn't during array create. A barrier ought to be
inserted in order to ensure an array's length is visible when the array
itself can be observed by other threads.

In order for Dalvik to be correct in respect to JSR-133 and the ARM
memory model, it should be modified to have a memory barrier after an
array is allocated and initialized, before it is visible to other
threads.

Change-Id: I329656139264552bbd7cacd8c743b694ee2e0bb8
Signed-off-by: Stuart Monteith <Stuart.Monteith@arm.com>
Signed-off-by: Serban Constantinescu <serban.constantinescu@arm.com>
Use RETURN_PTR(NULL) instead of RETURN_VOID in newNonMovableArray.

RETURN_VOID doesn't set the return value. This means that we are
returning random garbage when the allocation doesn't succeed.

Bug: 11971220
Change-Id: I570562c7bb9dc573161294916f582709774b35fd
Remove some ARMv5 cruft.

Change-Id: I95dcfd9dff8db25b9419b8ef862e3b9b70927a0c
Remove the sole reference to __ARM_HAVE_BLX.

Every ARM processor we run on has blx.

Change-Id: I633984d208d8a1995b9595521352e0b16413837c
Fix libutils dependencies for dexdump & dexlist.

We should always use a libutils SHARED_LIBRARY on the target &
a STATIC_LIBRARY on the host.

(cherry picked from commit 2ac78805e1b4d80308c5c4a48a997abc3a2ac37b)

Change-Id: I06c9b8f0cf663e00da0eeba54c893d8eec1d8a9f
Dalvik: Add sdiv support in the interpreter

This patch adds hardware divide support in the interpreter side of
dalvik. This operation is supported on new armv7 cpus such as A15 or A7.

Opcodes added:
    OP_DIV_INT
    OP_DIV_INT_2ADDR
    OP_DIV_INT_LIT16
    OP_DIV_INT_LIT8
    OP_REM_INT
    OP_REM_INT_2ADDR
    OP_REM_INT_LIT16
    OP_REM_INT_LIT8

Change-Id: Ib1ec5856d957feadd90807fe53ec34cc0e1fd4a2
Signed-off-by: Serban Constantinescu <serban.constantinescu@arm.com>
Dalvik: Add hardware support for OP_LONG_TO_DOUBLE in the interpreter

The following patch adds hardware vfp support for OP_LONG_TO_DOUBLE
in the interpreter. Previously this opcode was implemented using one of
gcc's builtin helpers.

Change-Id: I7713aa03c0b0bed8df592710dd50ab3d13d4bd9b
Signed-off-by: Serban Constantinescu <serban.constantinescu@arm.com>
Dalvik: Add sdiv support in the JIT

This patch adds hardware divide support in the JIT side of dalvik.
This operation is supported on new armv7 cpus such as A15 or A7.

The following opcodes are enabled and will generate code based using
SDIV instruction:

        OP_DIV_INT
        OP_DIV_INT_2ADDR
        OP_REM_INT
        OP_REM_INT_2ADDR
        OP_DIV_INT_LIT16
        OP_DIV_INT_LIT8
        OP_REM_INT_LIT16
        OP_REM_INT_LIT8

Change-Id: I2b2f9f337f13b5c794df951c4929b6ca0ad583c4
Signed-off-by: Serban Constantinescu <serban.constantinescu@arm.com>

Conflicts:
	vm/compiler/codegen/arm/Thumb2/Factory.cpp
Dalvik: Add hardware vfp support for OP_LONG_TO_DOUBLE in JIT

The following patch adds hardware vfp support for OP_LONG_TO_DOUBLE
in the JIT. Previously this opcode was implemented using one of gcc's
builtin helpers.

Change-Id: I3c88b2a527dea99dcefdb34be6695e75993da73e
Signed-off-by: Serban Constantinescu <serban.constantinescu@arm.com>
Dalvik: Better compatibility with different compilers

This fixes building with clang 3.4, and possibly future versions of gcc:
- Don't error out on unused functions generated by gen-mterp.py even
  when we're using -Werror
- Eliminate some dead code (Word/kWordSize definition) clang warns about

In order to avoid the need for -Wno-error=unused-function, gen-mterp.py
would have to be a lot smarter than it currently is.

Currently, it copies all code from header.cpp and then adds CPU specific
routines.

The code in header.cpp defines all sorts of functions that may or may
not be used by the CPU specific routines, depending on whether or not
the CPU specific bits have a better implementation available.

To fix this without -Wno-error=unused-functions, gen-mterp.py would have
to actually read the CPU specific bits and based on that throw out parts
of header.cpp that aren't needed.

This seems to be too much effort to just avoid having a couple of unused
functions in the code that can be thrown out at compile time anyway,
especially since this is in dalvik which will likely not see another
major revision.

Change-Id: I2874c6f05186721636518e422b0f39a3d8e731cd
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
Don't implicitly cast NULL to a bool

The code is wrong and causes an error when building with clang 3.4
(-Werror,-Wnull-conversion)

Change-Id: If03aa782fa25337802ff906a0d06071fbda93e26
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
Don't implicitly cast NULL to a bool

The code is wrong and causes an error when building with clang 3.4
(-Werror,-Wnull-conversion)

Change-Id: I223649ebcebf6f5df4b1024651bf07e85288f0b8
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
Initialize callTgt variable

This silcences a clang build failure:
dalvik/vm/compiler/codegen/arm/armv7-a-neon/../CodegenDriver.cpp:904:41:
error: variable 'callTgt' is uninitialized when used here
[-Werror,-Wuninitialized]
        LOAD_FUNC_ADDR(cUnit, r2, (int) callTgt);
                                        ^~~~~~~

Change-Id: Ic5b3bb492f19b842743bf7d6214c89301ff524e7
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
Protect JIT Code cache modifications with version check

Required since the JIT CC is asyncronously reset from threads running GC.

Change-Id: Ibc26d33c00c3beab13043838ffe28474d0458bd3