Re: OS X and gnustep-base 1.21.1

[Owen Shepherd]

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/
address@hidden (general) / address@hidden (university)