Re: Trampoline jumping problems

[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 <mathias_bauer@gmx.net> 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 <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
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep




-- Sent from my PDP-11