Re: Trampoline jumping problems

[David Chisnall]

I've committed something similar to this now.

David

On 19 Mar 2014, at 09:32, Mathias Bauer <mathias_bauer@gmx.net> 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 <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
>> 


-- Sent from my IBM 1620