Thanks Alon :)
On Wednesday, September 16, 2015 at 1:45:49 AM UTC+8, Alon Zakai wrote:
>
> In tools/emterpretify.py, there is the code that implements the opcodes.
> For example
>
> CASES[ROPCODES['LOAD8']] = get_access('lx') + ' = ' + 'HEAP8[' +
> get_access('ly') + ' >> 0];'
>
> is the LOAD8 opcode, to load an 8 bit value. get_access accesses a
> register. So it is using the ly register as a pointer, loading from HEAP8,
> then storing in the lx register. You could just add some code like
>
> CASES[ROPCODES['LOAD8']] = 'assert(' + get_access('ly') + ' < LIMIT); ' +
> get_access('lx') + ' = ' + 'HEAP8[' + get_access('ly') + ' >> 0];'
>
> which would check that the pointer is less than some limit.
>
>
>
> On Mon, Sep 14, 2015 at 11:44 PM, awt <[email protected] <javascript:>>
> wrote:
>
>> Thanks Alon, I guess I will just ignore the memory access violation
>> checks for now. But I'm just curious, how do we add checks for memory
>> access violations into emterpreted code?
>>
>> On Tuesday, September 15, 2015 at 12:11:23 PM UTC+8, Alon Zakai wrote:
>>>
>>> That's all we have right now. But anything that checks for null derefs
>>> is going to have a large runtime penalty, probably similar to (the new
>>> optimized) safe heap, and more complicated checks would be costlier.
>>>
>>> Unless you really limit it to code you don't need to be fast. In which
>>> case, you might run the code in the emterpreter, adding memory access
>>> violations there is easy, and it has the option to just emterpret part of a
>>> codebase already, so doing this would be just a few lines of code.
>>>
>>> On Mon, Sep 14, 2015 at 9:04 PM, awt <[email protected]> wrote:
>>>
>>>> Thanks, but other than SAFE_HEAP, do we have other means of catching
>>>> memory access violations? The issue is that we would like to catch memory
>>>> access violations even in production code and only for specific functions
>>>> so SAFE_HEAP is not really suitable here.
>>>>
>>>> On Tuesday, September 15, 2015 at 10:42:07 AM UTC+8, Alon Zakai wrote:
>>>>>
>>>>> Yeah, SAFE_HEAP mode is still here, and in fact today I landed a pull
>>>>> that makes it much faster. Still a big slowdown though, but it does allow
>>>>> you to catch memory access violations and in general run arbitrary code
>>>>> on
>>>>> each memory access.
>>>>>
>>>>> On Mon, Sep 14, 2015 at 7:16 PM, Bruce Mitchener <[email protected]
>>>>> > wrote:
>>>>>
>>>>>> It isn't without a massive slow down (and maybe not even with that,
>>>>>> do the safe heap modes still work?).
>>>>>>
>>>>>> - Bruce
>>>>>>
>>>>>>
>>>>>> On Tue, Sep 15, 2015 at 9:13 AM, awt <[email protected]> wrote:
>>>>>>
>>>>>>> Thanks Alon. I was actually trying to emulate Window's Structured
>>>>>>> Exception Handling with signals and my implementation requires the use
>>>>>>> of
>>>>>>> signals. Other than signals, do you know if its actually possible to
>>>>>>> catch
>>>>>>> any memory access violation in Emscripten, perhaps at the Javascript
>>>>>>> level?
>>>>>>>
>>>>>>> On Tuesday, September 15, 2015 at 1:51:40 AM UTC+8, Alon Zakai wrote:
>>>>>>>>
>>>>>>>> We don't have signals support (although we might get it eventually
>>>>>>>> with threads), so the signal versions of setjmp/longjmp are not
>>>>>>>> supported.
>>>>>>>> However, regular setjmp/longjmp do work.
>>>>>>>>
>>>>>>>> On Mon, Sep 14, 2015 at 2:56 AM, awt <[email protected]> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I was trying to compile a piece of code with the sigsetjmp and
>>>>>>>>> siglongjmp functions and observed the 'warning: unresolved symbol:'
>>>>>>>>> error
>>>>>>>>> for both of them. Can I check if these two functions are implemented
>>>>>>>>> in
>>>>>>>>> Emscripten?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>>> Groups "emscripten-discuss" group.
>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>> send an email to [email protected].
>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "emscripten-discuss" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to [email protected].
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "emscripten-discuss" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to [email protected].
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "emscripten-discuss" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
