Re: objc_msgSend problems on x86

FROM : Greg Parker
DATE : Sun Feb 12 00:15:00 2006

Rosyna wrote:
> bool isEqual=objc_msgSend(string, NSSelectorFromString(CFSTR
> ("isEqualToString:")), otherString);
>
> On the PPC will work just fine 100% of the time. If I run the same 
> code on the ICBMs it'll return true even when the strings weren't 
> equal at all in some rare cases. It also shows an error in GCC
>
> Even worse was trying something like:
>
> if (objc_msgSend(string, NSSelectorFromString(CFSTR
> ("isEqualToString:")), otherString))
>
> which returns true the far majority of the time even when it the 
> strings are not equal. However, if I change the code to read:
>
> if ((signed char(*)(id, SEL, id)objc_msgSend)(string, 
> NSSelectorFromString(CFSTR("isEqualToString:")), otherString))
>
> it always returns the correct value. Is there a reason for this 
> change between the PPC and the x86?


The problem is that this code is sloppy with its types, and in this 
case the PPC instruction set is more forgiving than i386.

Executive summary:
If you want to call objc_msgSend() directly for a method that doesn't 
return `id`, you should always use an appropriately-typed function 
pointer instead of objc_msgSend() itself. If you don't, your code 
might work on PPC, but is likely to fail on i386 or PPC64.

Bonus tips:
* Using an appropriately-typed function pointer is equally important 
for calling IMPs directly as it is for objc_msgSend().
* Using an appropriately-typed function pointer is especially 
important for objc_msgSend_stret(). The function pointer must return 
the struct type, rather than pass the address of the struct as the 
first parameter.
* For floating-point return values on i386, use objc_msgSend_fpret() 
instead of objc_msgSend() itself.


Consider this simple method:

    @implementation Test
    +(BOOL) returnFalse { return (self == (id)_cmd); }
    @end

This method always returns NO, because `self` and `_cmd` are never 
equal.


The PPC assembly (at -O3) looks like this:

    "+[Test returnFalse]":
        xor r3,r4,r3
        subfic r0,r3,0
        adde r3,r0,r3
        blr

The compiler optimizer is being clever here, using some arithmetic to 
do the comparison without any branches. Suffice to say that the return 
value is in register r3, and that a NO return sets all of register r3 
to zero. In general, the instructions used to compute a one-byte BOOL 
value also set the rest of the register to zero when returning NO.


On i386, the assembly looks like this:

    "+[Test returnFalse]":
        pushl  %ebp
        movl    %esp, %ebp
        movl    12(%ebp), %eax
        cmpl    8(%ebp), %eax
        sete    %al
        popl    %ebp
        ret

Here, the return value is placed in register al, which is another name 
for the first byte of the four-byte register eax. Importantly, the 
other three bytes of eax are left as random garbage, which is 
different from the PPC case. This is usually ok because BOOL is only 
one byte, but in this case it causes trouble, as we'll see below.


Now let's call the +returnFalse method using objc_msgSend() directly.

    // BAD version
    if (objc_msgSend([Test class], @selector(returnFalse))) {
        printf("YES\n");
    } else {
        printf("NO\n");
    }

As far as the compiler can see, objc_msgSend() returns a four-byte 
`id` value in register r3 or eax. The `if` check therefore uses the 
entire four bytes of that register. On PPC that's ok, because all of 
r3 is zero. But on i386, the other three bytes of eax are random 
garbage, so the `if` check comes out true even though the method 
returned NO.


If you call +returnFalse using a function pointer cast to the right 
type, it works better.

    // GOOD version
    BOOL (*fn)(id, SEL) = (BOOL (*)(id, SEL)) objc_msgSend;
    if ((*fn)([Test class], @selector(returnFalse))) {
        printf("YES\n");
    } else {
        printf("NO\n");
    }

Now the compiler knows that the return value is only one byte of 
register r3 or eax. The `if` check ignores the other three bytes, so 
you get the value you expected on both PPC and i386.


You might think that you could get away with this:

    // RISKY version
    if ((BOOL) objc_msgSend([Test class, @selector(returnFalse))) {
        printf("YES\n");
    } else {
        printf("NO\n");
    }

Don't do this. In the BOOL case it works, I think. In other cases it 
fails (for example, if you cast to double instead of BOOL). Using an 
appropriately-typed function pointer always works.


--
Greg Parker    <email_removed>    Runtime Wrangler