You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During the lowering process we encounter pointers (object locations) which are to be encoded into the instruction stream (if we want to conform with what v8 already expects). For each of them a proper relocation info is created and attached to the Code object. The problem is in order to generate relocation info we have to know where in the instruction stream our pointer ends up. Which we only get to know after the code has been generated.
Our current implementation is OK for a proof-of-concept, but is not OK for production. We disassemle the code and search for mov imm64 and look if the immediate is in our map. This can cause bugs if we somehow end up having some constant (say, a bit mask coming from JS) equal to one of our addresses. The probability is very low. And this makes it really dangerous.
The proper approach is to use the patchpoint llvm intrinsic (or a similar new intrinsic just for that). Alternatively we can modify the format and parsing of Reloc info (stop having the pointer constatns in the instruction stream). See comments to this question.
The text was updated successfully, but these errors were encountered:
During the lowering process we encounter pointers (object locations) which are to be encoded into the instruction stream (if we want to conform with what v8 already expects). For each of them a proper relocation info is created and attached to the Code object. The problem is in order to generate relocation info we have to know where in the instruction stream our pointer ends up. Which we only get to know after the code has been generated.
Our current implementation is OK for a proof-of-concept, but is not OK for production. We disassemle the code and search for
mov imm64
and look if the immediate is in our map. This can cause bugs if we somehow end up having some constant (say, a bit mask coming from JS) equal to one of our addresses. The probability is very low. And this makes it really dangerous.The proper approach is to use the
patchpoint
llvm intrinsic (or a similar new intrinsic just for that). Alternatively we can modify the format and parsing of Reloc info (stop having the pointer constatns in the instruction stream). See comments to this question.The text was updated successfully, but these errors were encountered: