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@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
