<br><br><div class="gmail_quote">On Wed, Jul 27, 2011 at 10:59 AM, Brian Luczkiewicz <span dir="ltr">&lt;<a href="mailto:brian@sooloos.com">brian@sooloos.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
This code (duplicated below, from gc_locks.h) is a little bit troublesome. I&#39;m not sure what the best way to resolve is, but I figured I&#39;d raise the issue anyways.<div><br></div><div>On most architectures, building for an old CPU then running on a newer one is safe. For example, running code compiled for i386 on a modern intel cpu generally turns out ok. </div>

<div><br></div><div>With mono+arm this is not the case. If I use gcc to build for arm with no -march/etc flags, gcc builds for armv5. If I run this mono on an SMP armv7a machine, I get deadlocks and terribleness, because test+set is broken. The comments seems to suggest that someone anticipated this issue, but never followed up.</div>

<div><br></div><div>Any ideas how we can make this experience better? If it&#39;s truly not possible to write a single code path that is suitable for both CPUs when building for armv5, maybe code built for armv5 should force mono into a single cpu or assert at boot if run on an SMP arm machine.</div>

<div></div></blockquote></div><br><div>Support SMP on armv5 binaries would require some very nasty hacks to enable runtime detection of v6+ and use the correct and safe paths (in about a dozen places). I not sure if such approach is manageable.</div>
<div><br></div><div>So, I believe forcing armv5 binaries to be bound to a single cpu is reasonable enough.</div>