I've committed something similar to this now. David
On 19 Mar 2014, at 09:32, Mathias Bauer <[email protected]> wrote: > No, I don't have commit access. > > Regards, > Mathias > > Am 19.03.14 07:05, schrieb David Chisnall: >> Yup, that looks like the correct fix. I'm reviewing your other runtime >> patches and they all look fine at first glance. I'll try to apply them all >> today (or you can if you have commit access?) >> >> David >> >> On 18 Mar 2014, at 18:09, Mathias Bauer <[email protected]> wrote: >> >>> Hi, >>> >>> would that be an acceptable change that we can apply to >>> imp_ImplementationWithBlock? >>> >>> Regards, >>> Mathias >>> >>> Am 10.03.14 17:39, schrieb Mathias Bauer: >>>> 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 <[email protected]> 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 >>>> [email protected] >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >>> >>> _______________________________________________ >>> Discuss-gnustep mailing list >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >> >> >> >> >> -- Sent from my PDP-11 >> -- Sent from my IBM 1620 _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
