Dan Gibson wrote:
> Greg (+list),
> The compiler version issue is a really, really difficult problem.
We
> have seen this problem at various times, on the list and
internally, and
> we invariably get the same response from Virtutech: Upgrade.
>
> My current theory on this is that Simics 2.x (or 3.x) is compiled
> against ABI x, GEMS is compiled to ABI y according to the setup of
the
> host machine, and both GEMS and Simics end up /using/ ABI z at
runtime,
> where in general x!=z and y!=z (though usually y==z). Hence, (at
least)
> two flavors of libc interact, and eventually the heap gets smashed.
> Unfortunately, I don't know why it works for some folks and not for
> others -- memory corruption is a pretty subtle problem as you know.
>
> So why not upgrade? There is no short answer, so here's the long
one.
> 1) GEMS-users (including ourselves) have a lot of scripts that are
not
> forward compatible (though checkpoints ARE from 2.x to 3.x).
> 2) We have had some indication that GEMS+Simics2 is faster than
> GEMS+Simics3 for some workloads
> 3) Upgrading is a big pain and we don't have a lot of free graduate
> students available to make the change
> 4) Changing Simics version has the nasty side effect of changing
> results... and no one wants to admit mid-thesis that results are
> sensitive to something like that.
>
> However, as I said in my earlier post, we are looking into Simics
4.0
> compatibility for GEMS right now. It will not be available for use
in
> classes this semester. In fact, from my 'experience' in porting
GEMS to
> 3.0, I won't guarantee it'll /ever/ be available. But, we're
looking
> into it and we request and appreciate patience from our user
community.
>
> Regards,
> Dan
>
> On Mon, Feb 2, 2009 at 11:18 AM, Greg Byrd <
gbyrd@xxxxxxxx
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}