Bug 159408

Created attachment 282721 [details] Patch WIP patch. It builds, but tests crashes now, still debugging.

Comment on attachment 282721 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=282721&action=review > Source/JavaScriptCore/bytecode/InlineAccess.h:56 > - return 50; > + return 64; WIP: Return dummy but valid values, until we can calculate the proper value somehow. I hope more nops won't cause problems. > Source/JavaScriptCore/bytecode/InlineAccess.h:75 > - return 50; > + return 64; ditto > Source/JavaScriptCore/bytecode/InlineAccess.h:94 > - return 50; > + return 64; ditto

infos about the crash I notice: sunspider-1.0/3d-cube.js.dfg-maximal-flush-validate-no-cjit: [1470] get_by_id loc9, loc8, NumPx(@id22) llint(struct = 0xb29a7ae0 (offset = 103)) predicting Nonboolint32 sunspider-1.0/3d-cube.js.dfg-maximal-flush-validate-no-cjit: disassembly not available for range 0xb2f13da4...0xb2f13e0c (gdb) disas 0xb2f13da4,0xb2f13e0c Dump of assembler code from 0xb2f13da4 to 0xb2f13e0c: 0xb2f13da4: ldr r0, [r11, #-72] ; 0x48 0xb2f13da8: ldr r1, [r11, #-68] ; 0x44 0xb2f13dac: cmn r1, #5 0xb2f13db0: bne 0xb2f18c48 0xb2f13db4: ldr r12, [r0] 0xb2f13db8: movw r6, #31456 ; 0x7ae0 0xb2f13dbc: movt r6, #45722 ; 0xb29a 0xb2f13dc0: cmp r12, r6 0xb2f13dc4: ldrne r12, [pc, #16] ; 0xb2f13ddc 0xb2f13dc8: bxne r12 0xb2f13dcc: ldr r0, [r0, #8] 0xb2f13dd0: ldr r1, [r0, #-36] ; 0x24 0xb2f13dd4: ldr r0, [r0, #-40] ; 0x28 => 0xb2f13dd8: bkpt 0xffff 0xb2f13ddc: rscslt r8, r1, #72, 24 ; 0x4800 0xb2f13de0: nop ; (mov r0, r0) 0xb2f13de4: nop ; (mov r0, r0) 0xb2f13de8: nop ; (mov r0, r0) 0xb2f13dec: nop ; (mov r0, r0) 0xb2f13df0: nop ; (mov r0, r0) 0xb2f13df4: ldr r6, [pc, #1848] ; 0xb2f14534 0xb2f13df8: str r0, [r6] 0xb2f13dfc: ldr r6, [pc, #1844] ; 0xb2f14538 0xb2f13e00: str r1, [r6] 0xb2f13e04: str r0, [r11, #-80] ; 0x50 0xb2f13e08: str r1, [r11, #-76] ; 0x4c End of assembler dump. (gdb) info registers r0 0x168 360 r1 0xffffffff 4294967295 r2 0x0 0 r3 0xbed44828 3201583144 r4 0xffffffff 4294967295 r5 0x0 0 r6 0xb29a7ae0 2996468448 r7 0x0 0 r8 0xb29c71e0 2996597216 r9 0xfffffffb 4294967291 r10 0x1 1 r11 0xbed44968 3201583464 r12 0xb29a7ae0 2996468448 sp 0xbed448a0 0xbed448a0 lr 0xb2f13d1c -1292813028 pc 0xb2f13dd8 0xb2f13dd8 cpsr 0x600f0010 1611595792

Created attachment 282767 [details] Patch Still WIP patch, updated magic numbers, still have crashes.

Comment on attachment 282767 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=282767&action=review > Source/JavaScriptCore/assembler/MacroAssemblerARM.h:1550 > + m_assembler.cmp(ARMRegisters::S1, m_assembler.getImm(right.m_value, ARMRegisters::S0)); Are S0 and S1 always scratch? As in it will never be a register that DFG allocates?

(In reply to comment #5) > Comment on attachment 282767 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=282767&action=review > > > Source/JavaScriptCore/assembler/MacroAssemblerARM.h:1550 > > + m_assembler.cmp(ARMRegisters::S1, m_assembler.getImm(right.m_value, ARMRegisters::S0)); > > Are S0 and S1 always scratch? As in it will never be a register that DFG > allocates? As far as I know we can use scratch registers in MacroAssembler without any restriction. But I might be wrong. note: I'll update magic number based on https://bugs.webkit.org/show_bug.cgi?id=158719#c29

I found more bugs here, I'm going to fix them one by one in separated bugs.