http://codereview.chromium.org/11037023/diff/25001/src/arm/assembler-arm-inl.h File src/arm/assembler-arm-inl.h (right):
http://codereview.chromium.org/11037023/diff/25001/src/arm/assembler-arm-inl.h#newcode367 src/arm/assembler-arm-inl.h:367: ASSERT(IsMovT(Memory::int32_at(pc + 4))); + kInstrSize http://codereview.chromium.org/11037023/diff/25001/src/arm/assembler-arm-inl.h#newcode369 src/arm/assembler-arm-inl.h:369: Instruction* next_instr = Instruction::At(pc + 4); + kInstrSize http://codereview.chromium.org/11037023/diff/25001/src/arm/assembler-arm-inl.h#newcode372 src/arm/assembler-arm-inl.h:372: instr->ImmedMovwMovtValue()); The bottom two bits should be zero, which might be an easy JIT-hardening. If the bottom bit isn't zero and we pass the address to BX or BLX then we're switching to Thumb, which is a nice exploit vector. I'd just & ~3 http://codereview.chromium.org/11037023/diff/25001/src/arm/assembler-arm-inl.h#newcode387 src/arm/assembler-arm-inl.h:387: // Or pre v8: Pre v8? http://codereview.chromium.org/11037023/diff/25001/src/arm/assembler-arm-inl.h#newcode398 src/arm/assembler-arm-inl.h:398: IsMovT(Memory::int32_at(candidate + 4))); + kInstrSize http://codereview.chromium.org/11037023/diff/25001/src/arm/assembler-arm-inl.h#newcode443 src/arm/assembler-arm-inl.h:443: void Assembler::set_target_address_at(Address pc, Address target) { As noted above: target &= ~3; http://codereview.chromium.org/11037023/diff/25001/src/arm/assembler-arm-inl.h#newcode445 src/arm/assembler-arm-inl.h:445: ASSERT(IsMovT(Memory::int32_at(pc + 4))); + kInstrSize http://codereview.chromium.org/11037023/diff/25001/src/arm/assembler-arm-inl.h#newcode457 src/arm/assembler-arm-inl.h:457: ASSERT(IsMovT(Memory::int32_at(pc + 4))); + kInstrSize http://codereview.chromium.org/11037023/diff/25001/src/arm/assembler-arm-inl.h#newcode467 src/arm/assembler-arm-inl.h:467: // accessing this address in the constant pool remains unchanged. Is this actually true? I can't find a reference to that effect. http://codereview.chromium.org/11037023/diff/25001/src/arm/assembler-arm.cc File src/arm/assembler-arm.cc (right): http://codereview.chromium.org/11037023/diff/25001/src/arm/assembler-arm.cc#newcode842 src/arm/assembler-arm.cc:842: s == LeaveCC) { In this case we're emitting 2 instructions, and when doing GC we need to flush the I$ for those two instructions. Would it be worth it to prevent MOVW/MOVT from straddling a cacheline? If at this point it would straddle then we can just emit a NOP, and then MOVW/MOVT together on the next cacheline. I'm assuming JIT function's code always starts at a cacheline boundary. http://codereview.chromium.org/11037023/diff/25001/src/arm/assembler-arm.cc#newcode844 src/arm/assembler-arm.cc:844: RecordRelocInfo(x.rmode_, x.imm32_, DONT_USE_CONSTANT_POOL); As before, if there's relocinfo then it's code (right?) so & ~3 http://codereview.chromium.org/11037023/diff/25001/src/arm/macro-assembler-arm.cc File src/arm/macro-assembler-arm.cc (right): http://codereview.chromium.org/11037023/diff/25001/src/arm/macro-assembler-arm.cc#newcode300 src/arm/macro-assembler-arm.cc:300: IsPowerOf2(src2.immediate() + 1)) { It would be kind of silly, but if src2 == 0xffffffff then this is undefined. In that case it should just be a MVN Rd, 0, which can be handled before this else_if. http://codereview.chromium.org/11037023/ -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
