tree 2398b07b80b81fdee0533866b47aa641f023abfd
parent 40648e2927dae10d81b1a1b68aad750e810c83e9
author philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> 1428762745 +0000
committer philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> 1428762745 +0000

Add 2 tests none/tests/libvex_test and libvexmultiarch_test

The objective of libvex_test is to verify that the VEX lib
can be used in 'single arch mode' (host == guest).

The objective of libvexmultiarch_test is to verify that the VEX lib
can be used in 'multi arch mode' (freely choose host and guest).
(but not many combinations are working: if wordsize or endianess
differs, then libVEX quickly asserts somewhere).

libvex_test.c is somewhat bizarre, as it uses the architecture
for which we have compiled as the guest, and use a 'foreign' arch
as the host.
That allows to avoid having to define in the test a bunch
of arch specific asm instructions : the test just decode a part
of its own code, and translate it to other archs.

By default, only the combination host == guest is run.
Arguments must be given to run other combinations.
See libvex_test.c for a description on how to specify which combinations
to run.

LibVEX host != guest does not (yet?) work when endianess or word size differs
between host and guest.

Also, currently, TILEGX host is not working properly (unless guest is also
TILEGX), as the evcheck instructions generated differs according to
the offset of the host_EvC_{FAILADDR,COUNTER}.

So, using TILEGX as host is only done when guest is also TILEGX.

Note that it is possible to specify a specific host arch to use.
For example, to force TILEGX to be used, do:
./none/tests/libvexmultiarch_test 1034
(where 1034 is the decimal value corresponding to the enum VexArchTILEGX.
This currently aborts with:
...
------------------------ Assembly ------------------------

EvCheck   (evCheck) ld r11, 8(r50); addli r11, r11, -1; st r11, 8(r50); bgez r11, nofail; jalr *(r50); nofail:

vex: priv/host_tilegx_defs.c:2353 (emit_TILEGXInstr): Assertion `evCheckSzB_TILEGX() == (UChar*)p - (UChar*)p0' failed.
//// failure exit called by libVEX
Whe TILEGX is fixed, we can remove the specific condition that avoids using
TILEGX as host.


Small changes have been done on VEX to allow more combinations
to work:
* host_mips_defs.c : when not compiled on mips,
  a lot of mips specific code is not compiled at all, because
  one of _MIPSEL or _MIPSEB must be defined to have either the
  little endian code or big endian code.
  emit32 function must however work to use mips as host.
  So, for this function, if _MIPSEL is not defined, then
  the big endian code is compiled in by default.
  (the mips endianess should probably be handled like the ppc
   endianess, for which the endianness to use is decided at runtime).

* host_arm64_isel.c : addition of a 'do not emit anything' for
   ABI HINT (avoid an assert e.g. for amd64 guest, arm64 host)

* libvex_guest_amd64.h : when I was still hoping mixing amd64 and x86,
  a first assert was firing up due to size/alignment
  of VexGuestAMD64State when compiled in 32 bits.
  => addition of pad elements to ensure the size and alignment
  of VexGuestAMD64State stays the same when compiled in 32 and
  64 bits (the 64 bits layout is unchanged).


The new tests have been run on x86/amd64/ppc64/s390x.
It is very well possible that the tests will fail on untested archs
(ppc32 or mips* or arm* or tilegx)
(e.g. because the hardcoded hwcaps in libvex_test.c are not ok).
It should be relatively trivial to fix these hwcaps problems.
Some other problems might be less easy to understand and fix 
(e.g. similar to the TILEGX evcheck or mips emit32 problem).


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15084 a5019735-40e9-0310-863c-91ae7b9d1cf9