[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Trampoline jumping problems
From: |
David Chisnall |
Subject: |
Re: Trampoline jumping problems |
Date: |
Wed, 19 Mar 2014 09:52:25 +0000 |
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