|
From: Philippe W. <phi...@sk...> - 2015-03-29 17:03:14
|
When linking a tool for a certain architecture (e.g. x86), the resulting
executable contains a significant proportion of the VEX library for
other architectures (amd64, arm, ppc, mips, s390).
After looking at the dependencies, the other architectures object
files are dragged in by various 'switch (arch)' in main_main.c.
For example,
case VexArchPPC64:
mode64 = True;
rRegUniv = getRRegUniverse_PPC(mode64);
isMove = (__typeof__(isMove)) isMove_PPCInstr;
getRegUsage = (__typeof__(getRegUsage)) getRegUsage_PPCInstr;
will drag various ppc64 objects.
I have quickly done a trial to see how much we can gain by having
main_main.c only dragging one architecture.
On x86, the text size of memcheck-x86-linux decreases
from about 3.8 MB to about 2MB.
The startup of a tool is also slightly faster : valgrind reads its own
debug info, and smaller executable means smaller debug info to read.
The mmap-ed size of the "dinfo" arena also decreases by about 9MB
(peak mmaped decreases by 14MB).
So, it looks interesting to avoid dragging all the other archs VEX
objects.
I see 3 ways to do the above:
1. Using a few conditional macros in main_main.c, ensure only
the functions needed for the compiled architecture
are referenced
This is easy to do.
However, this means the compile VEX library can only be used with
one single architecture : host and guest will be the same, and
will be the one for which the VEX lib is compîled.
I do not know if VEX lib is supposed to be usable to have
host and guest different.
If VEX host and guest are in any case supposed to be the same,
then solution 1 is the easiest.
2. Same as 1, but allow a configure option to still allow all
architectures to be compiled in.
A little bit more work than 1.
Advantage: if someone needs a multi-arch VEX lib, it can be
decided at configure time.
3. Decouple main_main.c from the 'backend VEX' by extending VexArchInfo
and/or adding a VexBackEndInfo structure, containing pointers to the
arch specific functions.
I have started doing this (half done patch attached, only works
for x86, as the decoupling infrastructure is incomplete).
All that is not very straightforward/is a lot more work.
And of course, the VEX user will have to call a 'arch dependent'
initialise procedure (one of the things not yet done in the patch).
Personally, 1 (or maybe 2) looks good enough to me,
but that assumes there is no (significant) need for a multi-arch VEX
lib.
Feedback/comments/suggestions ?
Philippe
|