2011年8月3日 星期三

segmentation fault:
1' where?
0x00007fffe0000158
0x00007fffe8000168
0x00007fffe8000078
0x00007fffe0000158

This address seems strange
jit_event_listener

try debug version

turn off AddShackPush in trace, wait and see...
still seg fault, re-implement
should always try both single thread version, multi-thread version

Reason:
timing plus inappropriate block_map
when translating a block, the block info is inserted into block_map
at beginning of translation process, which violates the assumption of block map.
We assume all infos in block map are valid, which means they have host code address where the translated code at. However, at the beginning of translation, we didn't know the exact address of the translated block. As a result, when the trace builder doing AddShackPush, it found the incomplete block in the block map, and uses its address.
Therefore, we modified the code as the following:
1. block info is added immoderately after the location of the translated block is known, which is in NotifyFunctionEmitted of jit_event_listener.h.
2. the query is delayed until we are going to patch the shack point.

However, in this experiment, I found shadow stack is quietly in-effect to performance,
plus it consumes more memory, and makes code complex. It seems more reasonable not to use shack when trace is available.

沒有留言:

張貼留言