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

[Jonas Maebe]

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