|
From: Florian K. <fl...@ei...> - 2015-03-29 20:46:58
|
On 29.03.2015 18:03, Philippe Waroquiers wrote: > > So, it looks interesting to avoid dragging all the other archs VEX > objects. > Yes, please. +10 > 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. Julian can give the full history. There is plenty of evidence that the original VEX design goal was to support host != guest. But when I began looking at V code in 2006 the code wasn't clean in that respect. And it hasn't gone any better. Here is a quote from Julian from Dec 2014 clarifying: This guest-vs-host stuff is still partly alive as a result of a hope I had that someone might want to do a cross-valgrind one day, eg ARM32 guest on AMD64 host. But it's been 12+ years and I've never once heard any mention of such a thing. So perhaps it's time to give up on that one. I think that settles your question :) > If VEX host and guest are in any case supposed to be the same, > then solution 1 is the easiest. Yes. It's funny.. I looked at this very same issue a few weeks back but could not figure out the autotools stuff. Note, though, that we still want to compile all VEX sources and not just the ones pertaining to the current architecture. Florian |