Re: Small change in NSObject.m ASM needed for PowerPC build

[Fred Kiefer]

David,

now this is very strange. Your tiny program works perfectly here, even
when I change it into an Objective-C fragment. I get the expected ASM
code (or even more so). And it gives the right result.
So why is it failing in NSObject.m?

I ran this file through the preprocessor and get the following line:
  result =
__sync_fetch_and_sub(((gsatomic_t)&(((obj)anObject)[-1].retained)), 1);

This looks a bit complicated but quite sensible.
Converting this into assembler gives

        .loc 1 380 0
        movl    8(%ebp), %eax
        subl    $8, %eax
        movl    $1, 4(%esp)
        movl    %eax, (%esp)
        call    address@hidden
        movl    %eax, -16(%ebp)

Sorry, no clue what gcc is doing here.
Next I tried to make your example more similar to the code above,
resulting in this:

#include <stdlib.h>

typedef int32_t volatile *gsatomic_t;
volatile int a;
int main(void)
{
    __sync_fetch_and_add((gsatomic_t)&a, 1);
    return a;
}

But that still compiles well.

        .file   "sync1.m"
        .text
.globl main
        .type   main, @function
main:
        leal    4(%esp), %ecx
        andl    $-16, %esp
        pushl   -4(%ecx)
        pushl   %ebp
        movl    %esp, %ebp
        pushl   %ecx
        lock addl       $1, a
        movl    a, %eax
        popl    %ecx
        popl    %ebp
        leal    -4(%ecx), %esp
        ret
        .size   main, .-main
        .local  _OBJC_SELECTOR_TABLE
        .comm   _OBJC_SELECTOR_TABLE,8,4
        .comm   a,4,4
        .ident  "GCC: (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]"
        .section        .comment.SUSE.OPTs,"MS",@progbits,1
        .ascii  "ospwg"
        .section        .note.GNU-stack,"",@progbits


Any idea, what I could test next?

Fred


David Chisnall wrote:
> Can you try compiling this short C program:
> 
> volatile int a;
> int main(void)
> {
>     __sync_fetch_and_add(&a, 1);
>     return a;
> }
> 
> For me, with GCC 4.2.1, this Just Works™.  If it doesn't for you, can
> you try compiling it with gcc -S and take a look at the generated .s
> file?  It should contain this short sequence:
> 
>     lock
>     addl    $1, a
> 
> If instead it contains:
> 
>     call __sync_fetch_and_add
> 
> Then something weird is going on - the compiler is generating a call to
> the implementation in libgcc_s, which should only be used for non-x86
> platforms.
> 
> If we can't manage to get this working in the general case, then you can
> use this little program in the configure script - if it runs and exits
> then the compiler supports this extension (both recent gcc and clang do,
> so it should become increasingly-well supported over time).
> 
> I'm still surprised that it doesn't work for you - I've not had any
> problems with it for a couple of years on FreeBSD, and I was under the
> impression GCC supported Linux better than FreeBSD.