On 12 Apr 2011, at 14:46, David Chisnall wrote: > On 11 Apr 2011, at 20:34, Ivan Vučica wrote: > >> Regarding 3, this looks like the most technical one to me. It doesn't seem >> like blocks_runtime is conditionally trying to use x86_64 assembler. Could >> someone (David?) comment on this one? > > > There's no assembly in blocks_runtime.c, but it is using atomic ops. GCC, > for some braindead reason, decides that if you use these on x86 then it just > emits calls to some runtime support code to emulate them using non-atomic > ops[1], but doesn't actually bother linking them, so you end up with linker > errors from atomic ops.
GCC will insert the atomic ops, or an emulation of them, inline whenever possible (i.e. whenever directly supported by the processor*) else invoke a method in libgcc. I find it hard to believe that you've accidentally convinced GCC not to link against libgcc! Saying that, I can potentially see those methods not being included if e.g. you have libgcc built for i586 which doesn't need them (Though I wonder if thats ever the case? It certainly seems like a dangerous proposition from a binary compatibility point of view). * Not quite true. if my memory serves, GCC will never emit atomic instructions directly on ARM; though I would say someone probably ought to teach it to start emitting them directly on CPUs which support LDREX/STREX (i.e. modern ones). On older processors, things are slightly problematic as the only atomic instructions are SWP and SWPB... so you need to get the OS involved to help out for most things. And even when you can use SWP to implement your primitive... SWP is broken on multiprocessor ARMs, and so the OS has to disable it, trap it and emulate it, so you're better off calling libgcc anyway! -- Owen Shepherd http://www.owenshepherd.net/ [email protected] (general) / [email protected] (university) _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
