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]> 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].
> 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.
