This patch reduces the size of all tools by about 2MB of text
(depending on the arch).
This has as advantages:
1. somewhat faster build/link time (very probably neglectible)
2. somewhat faster tool startup (probably neglectible for most users,
but regression tests are helped by this)
3. a gain in memory of about 10MB
The valgrind tools are making the assumption that host and guest
are the same. So, no need to drag the full set of archs when
linking a tool.
The VEX library is nicely split in arch independent and arch dependent
objects. Only main_main.c is dragging the various arch specific files.
So, main_main.c (the main entry point of the VEX library) is compiled
only for the current guest/host arch.
The disadvantage of the above is that the VEX lib cannot be used
anymore with host and guest different, while VEX is able to do that
(i.e. does not make the assumption that host and guest are the same).
So, to still allow a VEX user to use the VEX lib in a multi arch setup,
main_main.c is compiled twice:
1. in 'single arch mode', going in the libvex-<arch>-<os>
2. in 'multi arch mode', going in a new lib libvexmultiarch-<arch>-<os>
A VEX user can choose at link time to link with the main_main
that is multi-arch, by linking with both libs (the multi arch being
the first one).
Here is a small (rubbish crashing) standalone usage of the VEX lib,
first linked in single arch, then linked in multi-arch:
// file t1.c
$ gcc -I Inst/include/valgrind -c -g t1.c
$ gcc -o t1 t1.o -LInst/lib/valgrind -lvex-x86-linux -lgcc
$ gcc -o t1multi t1.o -LInst/lib/valgrind -lvexmultiarch-x86-linux -lvex-x86-linux -lgcc
$ size t1 t1multi
text data bss dec hex filename
519393 556 5012188 5532137 5469e9 t1
2295717 1740 5015144 7312601 6f94d9 t1multi
In a next commit, some regtests will be added to validate that the two libs
are working properly (and that no arch specific symbol is missing when
git-svn-id: svn://svn.valgrind.org/vex/trunk@3113 8f6e269a-dfd6-0310-a8e1-e2731360e62c
3 files changed