[fpc-devel] OSX: Setting up parameters to objc_msgSend()

[David Jenkins]

Thanks.  I'll get a bug report in tomorrow morning.

On 10/11/18 3:16 PM, Jonas Maebe wrote:
> On 11/10/18 21:41, David Jenkins wrote:
>
>> Here is the assembly code generated by fpc (3.1.1) for just the 
>> section where .setEnabled(Enabled) is called
>>
>> ->  0x1001ba68d <+61>:  movq   -0x8(%rbp), %rdi
>>      0x1001ba691 <+65>:  callq  0x1002016d0 ; GETHANDLE at 
>> menuitem.inc:515
>>      0x1001ba696 <+70>:  movq   %rax, %rbx
>>      0x1001ba699 <+73>:  movq   0x329ee0(%rip), %rsi ; "setEnabled:"
>>      0x1001ba6a0 <+80>:  movb   -0x10(%rbp), %dl
>>      0x1001ba6a3 <+83>:  movq   %rbx, %rdi
>>      0x1001ba6a6 <+86>:  callq  0x1002d23da ; symbol stub for: 
>> objc_msgSend
>>
>> Notice the the value of Enabled (a BOOL) is treated as 8bit (which 
>> BOOL is) and placed into the lowest 8 bits of edx with the line 'movb 
>> -0x10(%rbp), %dl'.  Which means that the upper 24 bits of edx are not 
>> changed (not cleared, not signed extended, nothing, just left alone).
>
> That's because the x86-64 ABI says 
> (https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf 
> ):
>
> ***
> When a value of type _Bool is returned or passed in a register or on 
> the stack, bit 0 contains the truth value and bits 1 to 7 shall be 
> zero. (14)
>
> ...
>
> (14) Other bits are left unspecified, hence the consumer side of those 
> values can rely on it being 0 or 1 when truncated to 8 bit
> ***
>
> However, the Objective-C BOOL type does not map to _Bool on x86-64, 
> but to signed char. And values of that type indeed do need to (sign) 
> extended. So this needs to be fixed in the compiler. Please file a bug 
> report, and thanks for the analysis.
>
>
> Jonas
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel