Hi David,
it seems that calling
__clear_cache((char*)out, ((char*)out)+trampolineSize+2*sizeof(void*));
before returning helps.
Regards,
Mathias
Am 10.03.14 11:23, schrieb David Chisnall:
On 10 Mar 2014, at 19:10, Mathias Bauer <mathias_bauer@gmx.net> wrote:
Hi dear list,
the code in libobjc2 that implements imp_ImplementationWithBlock does
not work on at least some ARM platforms.
At least on boards using an Exynos CPU I see random crashes when
using imp_ImplementationWithBlock for dynamically provided
implementations for property getters and setters.
The crash always happens at an address that is a page boundary - it's
the boundary of the current page for trampolines. So it seems that at
the memory of the IMP there is no trampoline code, instead of that
this memory area behaves like a playgound slide that finally lets the
IP move to the page boundary.
The trampoline and its two addresses are written to this memory
through a pointer memory-mapped to a file handle with PROT_WRITE,
while another pointer memory-mapped to the same file handle with
PROT_READ|PROT_EXEC is used to read and execute the data later.
It seems that on the architecture that experiences the crashes there
is a time lag between writing the data and the availability of the
bytes as executable code, because the crash goes away if I add some
delay after writing the data.
It seems that we somehow need to make sure that what was written can
be executed immediately after that.
I think on ARM we need an instruction memory barrier there. We
probably do on MIPS too.
Can you try adding this at the end of the imp_ImplementationWithBlock
function and see if it fixes it on ARM?
volatile __asm__ ("imb")
David
-- Sent from my brain
_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep