|
From: Patrick S. <ps...@ci...> - 2007-12-11 18:17:42
|
Hi all, > Sorry not to have been very inputful on this so far. > > I can't claim to have great insight into the robustness aspects > of the NON_SIMD_CALL mechanism. However, looking at your original message, > it occurs to me your prospects of that working are improved if you > ensure that the NON_SIMD_CALL'd code (test_func) does not refer to any > global variables, and certainly does not refer to any libc or other > functions (printf et al). Any kind of entanglement with libc or > dynamic linking is likely to have a bad outcome, for gnarly reasons > which we've grappled with a lot in the distant past. > > If you simply make test_func be a wrapper around a LOCK-prefixed > instruction and literally nothing else, your prospects might improve > (or not, YMMV :-) Worth a try, I'd say. > > AIUI the lock-prefixed insns (etc) are actually the only things that > you absolutely can't run on the simulator, right? That's certainly my understanding. The LOCK instructions are buried several function layers down from where they'd most conveniently be wrapped, amongst a number of libc calls, so extracting them isn't trivial (alas), but certainly possible. I'll put my thinking cap on about this and the other suggestions - thanks to all who have responded! - and try to figure out what will work best for this particular situation. If I come up with anything that might be of general use, I'll report back... Thanks again, Patrick |