159720 2016-07-13 08:53:55 -0700 [ARM] ASSERTION FAILED: linkBuffer.isValid() in InlineAccess.cpp:291 after r202214 and r203537 2017-06-20 02:15:43 -0700 1 1 1 Unclassified WebKit JavaScriptCore Other Unspecified Unspecified NEW https://bugs.webkit.org/show_bug.cgi?id=160157 P2 Normal --- 159408 159649 1 ossy webkit-unassigned commit-queue fpizlo jbriance keith_miller mark.lam msaboff ossy saam oldest_to_newest 1210454 0 ossy 2016-07-13 08:53:55 -0700 jsc-stress-results/.tests/cdjs-tests.yaml/cdjs$ ./../../.vm/JavaScriptCore.framework/Resources/jsc main.js Program received signal SIGSEGV, Segmentation fault. 0xb64880b4 in WTFCrash () at ../../Source/WTF/wtf/Assertions.cpp:323 323 *(int *)(uintptr_t)0xbbadbeef = 0; (gdb) bt #0 0xb64880b4 in WTFCrash () at ../../Source/WTF/wtf/Assertions.cpp:323 #1 0xb5909240 in JSC::InlineAccess::rewireStubAsJump (vm=..., stubInfo=..., target=...) at ../../Source/JavaScriptCore/bytecode/InlineAccess.cpp:291 #2 0xb5fc087c in JSC::tryCachePutByID (exec=0xbeffe968, baseValue=..., structure=0xb21a7220, ident=..., slot=..., stubInfo=..., putKind=JSC::NotDirect) at ../../Source/JavaScriptCore/jit/Repatch.cpp:452 #3 0xb5fc0a80 in JSC::repatchPutByID (exec=0xbeffe968, baseValue=..., structure=0xb21a7220, propertyName=..., slot=..., stubInfo=..., putKind=JSC::NotDirect) at ../../Source/JavaScriptCore/jit/Repatch.cpp:463 #4 0xb5f88ca8 in JSC::operationPutByIdNonStrictOptimize (exec=0xbeffe968, stubInfo=0xb258dd80, encodedValue=-18486637472, encodedBase=-18486456960, uid=0xb25aedf8) at ../../Source/JavaScriptCore/jit/JITOperations.cpp:421 #5 0xb27ca8ec in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) 1210945 1 ossy 2016-07-14 04:12:00 -0700 InlineAccess.cpp ================= template <typename Function> ALWAYS_INLINE static bool linkCodeInline(const char* name, CCallHelpers& jit, StructureStubInfo& stubInfo, const Function& function) { if (jit.m_assembler.buffer().codeSize() <= stubInfo.patch.inlineSize) { bool needsBranchCompaction = false; LinkBuffer linkBuffer(jit, stubInfo.patch.start.dataLocation(), stubInfo.patch.inlineSize, JITCompilationMustSucceed, needsBranc hCompaction); ASSERT(linkBuffer.isValid()); <=================== BANG! function(linkBuffer); FINALIZE_CODE(linkBuffer, ("InlineAccessType: '%s'", name)); return true; } ... LinkBuffer.h ============= bool didFailToAllocate() const { return !m_didAllocate; } bool isValid() const { return !didFailToAllocate(); } ==== linkBuffer.isValid() is to ensure that LinkBuffer() constructor call sets its m_didAllocate member to true, but it isn't set. - LinkBuffer::LinkBuffer(...) calls LinkBuffer::linkCode(...) - LinkBuffer::linkCode(...) calls LinkBuffer::allocate(...) - LinkBuffer::allocate(...): initialSize = 12 > m_size = 4 and that's why allocate returns at the beginning without allocation and setting m_didAllocate to true. m_code = 0xb27ca808 Dump of assembler code from 0xb27ca808 to 0xb27ca860: 0xb27ca808: b 0xb27ca8b0 0xb27ca80c: nop ; (mov r0, r0) 0xb27ca810: nop ; (mov r0, r0) 0xb27ca814: nop ; (mov r0, r0) 0xb27ca818: nop ; (mov r0, r0) 0xb27ca81c: nop ; (mov r0, r0) 0xb27ca820: nop ; (mov r0, r0) 0xb27ca824: nop ; (mov r0, r0) 0xb27ca828: nop ; (mov r0, r0) 0xb27ca82c: nop ; (mov r0, r0) 0xb27ca830: nop ; (mov r0, r0) 0xb27ca834: nop ; (mov r0, r0) 0xb27ca838: ldr r0, [r11, #32] 0xb27ca83c: ldr r1, [r11, #36] ; 0x24 0xb27ca840: tst sp, #15 0xb27ca844: beq 0xb27ca850 0xb27ca848: mov r6, #100 ; 0x64 0xb27ca84c: bkpt 0x0000 0xb27ca850: mov sp, r11 0xb27ca854: pop {r11} ; (ldr r11, [sp], #4) 0xb27ca858: pop {lr} ; (ldr lr, [sp], #4) 0xb27ca85c: bx lr I think the assertion is simply incorrect in this case and should be removed. But I don't understand exactly the original change, please let me know if I misunderstood this bug. 1210958 2 283634 ossy 2016-07-14 05:39:04 -0700 Created attachment 283634 Patch 1211298 3 283634 saam 2016-07-14 18:40:27 -0700 Comment on attachment 283634 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=283634&action=review > Source/JavaScriptCore/bytecode/InlineAccess.cpp:-291 > - RELEASE_ASSERT(linkBuffer.isValid()); It doesn't make sense why this is failing. We call linkBuffer constructor with initial size equal to jit.m_assembler.buffer().codeSize(). LinkBuffer::allocate() is written like: void LinkBuffer::allocate(MacroAssembler& macroAssembler, void* ownerUID, JITCompilationEffort effort) { size_t initialSize = macroAssembler.m_assembler.codeSize(); if (m_code) { if (initialSize > m_size) return; size_t nopsToFillInBytes = m_size - initialSize; macroAssembler.emitNops(nopsToFillInBytes); m_didAllocate = true; return; } .... -------------------- So this assertion is catching a real bug. I suspect that it's something else that's adding code to the assembler buffer before calling allocate. Look at ::linkCode(): void LinkBuffer::linkCode(MacroAssembler& macroAssembler, void* ownerUID, JITCompilationEffort effort) { #if !ENABLE(BRANCH_COMPACTION) #if defined(ASSEMBLER_HAS_CONSTANT_POOL) && ASSEMBLER_HAS_CONSTANT_POOL macroAssembler.m_assembler.buffer().flushConstantPool(false); #endif allocate(macroAssembler, ownerUID, effort); if (!m_didAllocate) return; ASSERT(m_code); AssemblerBuffer& buffer = macroAssembler.m_assembler.buffer(); #if CPU(ARM_TRADITIONAL) macroAssembler.m_assembler.prepareExecutableCopy(m_code); #endif performJITMemcpy(m_code, buffer.data(), buffer.codeSize()); #if CPU(MIPS) macroAssembler.m_assembler.relocateJumps(buffer.data(), m_code); #endif #elif CPU(ARM_THUMB2) copyCompactAndLinkCode<uint16_t>(macroAssembler, ownerUID, effort); #elif CPU(ARM64) copyCompactAndLinkCode<uint32_t>(macroAssembler, ownerUID, effort); #endif // !ENABLE(BRANCH_COMPACTION) m_linkTasks = WTFMove(macroAssembler.m_linkTasks); } Maybe it's the call to prepareExecutableCopy which looks like it's trying to do some alignment. Or maybe it's the call to flushConstantPool. I suspect it's the alignment. When we're generating code into an already allocated slot of memory, I suspect it's incorrect for the linkBuffer to add more code to it unless it's certain it won't overflow the code size it's inserting into. 1214144 4 ossy 2016-07-25 04:51:03 -0700 (In reply to comment #3) > So this assertion is catching a real bug. > I suspect that it's something else that's adding code to the assembler > buffer before calling allocate. > Look at ::linkCode(): > > void LinkBuffer::linkCode(MacroAssembler& macroAssembler, void* ownerUID, > JITCompilationEffort effort) > { > #if !ENABLE(BRANCH_COMPACTION) > #if defined(ASSEMBLER_HAS_CONSTANT_POOL) && ASSEMBLER_HAS_CONSTANT_POOL > macroAssembler.m_assembler.buffer().flushConstantPool(false); > #endif > allocate(macroAssembler, ownerUID, effort); > if (!m_didAllocate) > return; > ASSERT(m_code); > AssemblerBuffer& buffer = macroAssembler.m_assembler.buffer(); > #if CPU(ARM_TRADITIONAL) > macroAssembler.m_assembler.prepareExecutableCopy(m_code); > #endif > performJITMemcpy(m_code, buffer.data(), buffer.codeSize()); > #if CPU(MIPS) > macroAssembler.m_assembler.relocateJumps(buffer.data(), m_code); > #endif > #elif CPU(ARM_THUMB2) > copyCompactAndLinkCode<uint16_t>(macroAssembler, ownerUID, effort); > #elif CPU(ARM64) > copyCompactAndLinkCode<uint32_t>(macroAssembler, ownerUID, effort); > #endif // !ENABLE(BRANCH_COMPACTION) > > m_linkTasks = WTFMove(macroAssembler.m_linkTasks); > } > > Maybe it's the call to prepareExecutableCopy which looks like it's trying to > do some alignment. Or maybe it's the call to flushConstantPool. > > I suspect it's the alignment. When we're generating code into an already > allocated slot of memory, I suspect it's incorrect for the linkBuffer > to add more code to it unless it's certain it won't overflow the code size > it's inserting into. I started debugging this issue and I can confirm that flushConstantPool flushes one constant in this case. Is it incorrect behavior? If yes, what should we do with this constant? What could be the proper fix? 1214147 5 ossy 2016-07-25 05:12:43 -0700 auto jump = jit.jump(); This line uses constant pool before linkBuffer ctor call. 1214149 6 ossy 2016-07-25 05:15:48 -0700 *** Bug 160157 has been marked as a duplicate of this bug. *** 1214151 7 ossy 2016-07-25 05:28:26 -0700 (In reply to comment #4) > I started debugging this issue and I can confirm that flushConstantPool > flushes one constant in this case. Is it incorrect behavior? If yes, > what should we do with this constant? What could be the proper fix? flushConstantPool call was added here ~ 3 years ago in https://trac.webkit.org/changeset/157796 . 1214180 8 jbriance 2016-07-25 07:59:31 -0700 (In reply to comment #7) > flushConstantPool call was added here ~ 3 years ago in > https://trac.webkit.org/changeset/157796 . Actually, flushConstantPool is there for a long time: https://trac.webkit.org/changeset/46057 In https://trac.webkit.org/changeset/157796, I moved its visibility from private to public. About the assert issue, I have no idea right now. 1214233 9 ossy 2016-07-25 10:10:28 -0700 (In reply to comment #6) > *** Bug 160157 has been marked as a duplicate of this bug. *** This snippet fixes this assertion mentioned in bug160157 (https://trac.webkit.org/changeset/203537) size_t initialSize = macroAssembler.m_assembler.codeSize(); if (m_code) { - if (initialSize > m_size) + if (initialSize > m_size) { + m_didAllocate = true; return; + } Additionally it fixes the assertion caused by r202214 (with enabling ICs again and applying other patches from bug159408). But I noticed some strange crashes (~only 100 tests) when generating IC overwrites unrelated code with zillion nops. 1214244 10 saam 2016-07-25 10:39:07 -0700 (In reply to comment #9) > (In reply to comment #6) > > *** Bug 160157 has been marked as a duplicate of this bug. *** > > This snippet fixes this assertion mentioned in bug160157 > (https://trac.webkit.org/changeset/203537) > > size_t initialSize = macroAssembler.m_assembler.codeSize(); > if (m_code) { > - if (initialSize > m_size) > + if (initialSize > m_size) { > + m_didAllocate = true; > return; > + } Is this a diff you're proposing? If so, this is completely wrong. You're saying that we succeeded even if the memory we're overwriting is not large enough to hold the assembly we generated. > > > Additionally it fixes the assertion caused by r202214 (with enabling ICs > again and applying other patches from bug159408). But I noticed some > strange crashes (~only 100 tests) when generating IC overwrites unrelated > code with zillion nops. 1214252 11 ossy 2016-07-25 10:52:02 -0700 (In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #6) > > > *** Bug 160157 has been marked as a duplicate of this bug. *** > > > > This snippet fixes this assertion mentioned in bug160157 > > (https://trac.webkit.org/changeset/203537) > > > > size_t initialSize = macroAssembler.m_assembler.codeSize(); > > if (m_code) { > > - if (initialSize > m_size) > > + if (initialSize > m_size) { > > + m_didAllocate = true; > > return; > > + } > Is this a diff you're proposing? If so, this is completely wrong. I'm just trying to debug what's wrong here and found that this hack fixed the assertion mentioned in bug160157. Could you explain what is the problem with flushConstantPool call before allocate? Your code generates a jump which is and ldr with a constant pool entry which will contain the address. The flushConstantPool call flushes it which makes initialSize bigger than m_size, which makes the assertion hit. I don't any idea what would be the proper fix here. Could you give me some hints? > You're saying that we succeeded even if the memory we're overwriting is > not large enough to hold the assembly we generated. I haven't investigate this overwrite issue yet. I just noticed zillion generated nops which overwrote a constant pool entry and caused crash. 1214257 12 saam 2016-07-25 10:56:32 -0700 (In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > (In reply to comment #6) > > > > *** Bug 160157 has been marked as a duplicate of this bug. *** > > > > > > This snippet fixes this assertion mentioned in bug160157 > > > (https://trac.webkit.org/changeset/203537) > > > > > > size_t initialSize = macroAssembler.m_assembler.codeSize(); > > > if (m_code) { > > > - if (initialSize > m_size) > > > + if (initialSize > m_size) { > > > + m_didAllocate = true; > > > return; > > > + } > > Is this a diff you're proposing? If so, this is completely wrong. > I'm just trying to debug what's wrong here and found that > this hack fixed the assertion mentioned in bug160157. > > Could you explain what is the problem with flushConstantPool call > before allocate? > > Your code generates a jump which is and ldr with a constant pool entry > which will contain the address. The flushConstantPool call flushes it > which makes initialSize bigger than m_size, which makes the assertion hit. > > I don't any idea what would be the proper fix here. > Could you give me some hints? You need to generate enough code in the inline path so that this is always allowed. The numbers defined in InlineAccess.h should accommodate this. How does the constant pool work? What code do we generate for the jump? Do we plant the jump target in executable memory and do a load relative to PC or something? > > > You're saying that we succeeded even if the memory we're overwriting is > > not large enough to hold the assembly we generated. > I haven't investigate this overwrite issue yet. I just noticed zillion > generated nops which overwrote a constant pool entry and caused crash. Interesting. Maybe it's the fillNops below, though I doubt it. Lets start by fixing things so we always have enough room to plant a jump in the inline path. 1214595 13 ossy 2016-07-26 11:20:55 -0700 Let's start again, I try to describe what happens step-by-step. Source/JavaScriptCore/bytecode/InlineAccess.cpp ================================================ void InlineAccess::rewireStubAsJump(VM& vm, StructureStubInfo& stubInfo, CodeLocationLabel target) { CCallHelpers jit(&vm); auto jump = jit.jump(); // We don't need a nop sled here because nobody should be jumping into the middle of an IC. bool needsBranchCompaction = false; LinkBuffer linkBuffer(jit, stubInfo.patch.start.dataLocation(), jit.m_assembler.buffer().codeSize(), JITCompilationMustSucceed, needsBranchCompaction); RELEASE_ASSERT(linkBuffer.isValid()); <============== BANG !!! linkBuffer.link(jump, target); FINALIZE_CODE(linkBuffer, ("InlineAccess: linking constant jump")); } Source/JavaScriptCore/assembler/LinkBuffer.cpp =============================================== void LinkBuffer::linkCode(MacroAssembler& macroAssembler, void* ownerUID, JITCompilationEffort effort) { #if !ENABLE(BRANCH_COMPACTION) #if defined(ASSEMBLER_HAS_CONSTANT_POOL) && ASSEMBLER_HAS_CONSTANT_POOL macroAssembler.m_assembler.buffer().flushConstantPool(false); #endif allocate(macroAssembler, ownerUID, effort); if (!m_didAllocate) return; ASSERT(m_code); AssemblerBuffer& buffer = macroAssembler.m_assembler.buffer(); #if CPU(ARM_TRADITIONAL) macroAssembler.m_assembler.prepareExecutableCopy(m_code); #endif performJITMemcpy(m_code, buffer.data(), buffer.codeSize()); #if CPU(MIPS) macroAssembler.m_assembler.relocateJumps(buffer.data(), m_code); #endif #elif CPU(ARM_THUMB2) copyCompactAndLinkCode<uint16_t>(macroAssembler, ownerUID, effort); #elif CPU(ARM64) copyCompactAndLinkCode<uint32_t>(macroAssembler, ownerUID, effort); #endif // !ENABLE(BRANCH_COMPACTION) m_linkTasks = WTFMove(macroAssembler.m_linkTasks); } void LinkBuffer::allocate(MacroAssembler& macroAssembler, void* ownerUID, JITCompilationEffort effort) { size_t initialSize = macroAssembler.m_assembler.codeSize(); if (m_code) { if (initialSize > m_size) return; size_t nopsToFillInBytes = m_size - initialSize; macroAssembler.emitNops(nopsToFillInBytes); m_didAllocate = true; return; } step 1: ------- InlineAccess.cpp - InlineAccess::rewireStubAsJump auto jump = jit.jump(); LinkBuffer linkBuffer(jit, stubInfo.patch.start.dataLocation(), jit.m_assembler.buffer().codeSize(), JITCompilationMustSucceed, needsBranchCompaction); - create a jump instruction (4 bytes) + an entry in the constant pool. - call LinkBuffer ctor with codeSize() == 4 step 2: -------- LinkBuffer.cpp - LinkBuffer::linkCode - LinkBuffer ctor calls LinkBuffer::linkCode - flushConstantPool(true) is called The jump looks like after flushConstantPool(true): -------------------------------------------------------------------------- 0xbeffe5c4: ldr pc, [pc] ; 0xbeffe5cc 0xbeffe5c8: b 0xbeffe5d0 0xbeffe5cc: ; <UNDEFINED> instruction: 0xffffffff -------------------------------------------------------------------------- 0xbeffe5c4: load the address from the constant pool and then jump to it 0xbeffe5c8: barrier to jump over the constant pool (true arg of flushConstantPool() ) 0xbeffe5cc: constant pool, the real address will be stored here - allocate is called, where initialSize = 12 (because flushConstantPool added two more instructions) m_size = 4 (because LinkBuffer ctor call get 4 as argument) if (m_code) { if (initialSize > m_size) return; <======== returns, m_didAllocate isn't set! size_t nopsToFillInBytes = m_size - initialSize; macroAssembler.emitNops(nopsToFillInBytes); m_didAllocate = true; return; } step 3: -------- - linkcode returns next to allocate because m_didAllocate is false My previous hack which added "m_didAllocate = true;" before the return let the linkCode continue its work and copy the new IC to the proper place. My question is still open, what do you think, how should we fix this bug properly? There is enough room for the 12 bytes long jump (ldr, b, constant pool), but rewireStubAsJump doesn't respect the fact that the jump will be bigger at the beginning of linkCode() function. We have same problems in all newly added IC generator function. 1214603 14 saam 2016-07-26 11:36:58 -0700 (In reply to comment #13) > Let's start again, I try to describe what happens step-by-step. > > Source/JavaScriptCore/bytecode/InlineAccess.cpp > ================================================ > void InlineAccess::rewireStubAsJump(VM& vm, StructureStubInfo& stubInfo, > CodeLocationLabel target) > { > CCallHelpers jit(&vm); > > auto jump = jit.jump(); > > // We don't need a nop sled here because nobody should be jumping into > the middle of an IC. > bool needsBranchCompaction = false; > LinkBuffer linkBuffer(jit, stubInfo.patch.start.dataLocation(), > jit.m_assembler.buffer().codeSize(), JITCompilationMustSucceed, > needsBranchCompaction); > RELEASE_ASSERT(linkBuffer.isValid()); <============== BANG !!! > linkBuffer.link(jump, target); > > FINALIZE_CODE(linkBuffer, ("InlineAccess: linking constant jump")); > } > > Source/JavaScriptCore/assembler/LinkBuffer.cpp > =============================================== > > void LinkBuffer::linkCode(MacroAssembler& macroAssembler, void* ownerUID, > JITCompilationEffort effort) > { > #if !ENABLE(BRANCH_COMPACTION) > #if defined(ASSEMBLER_HAS_CONSTANT_POOL) && ASSEMBLER_HAS_CONSTANT_POOL > macroAssembler.m_assembler.buffer().flushConstantPool(false); > #endif > allocate(macroAssembler, ownerUID, effort); > if (!m_didAllocate) > return; > ASSERT(m_code); > AssemblerBuffer& buffer = macroAssembler.m_assembler.buffer(); > #if CPU(ARM_TRADITIONAL) > macroAssembler.m_assembler.prepareExecutableCopy(m_code); > #endif > performJITMemcpy(m_code, buffer.data(), buffer.codeSize()); > #if CPU(MIPS) > macroAssembler.m_assembler.relocateJumps(buffer.data(), m_code); > #endif > #elif CPU(ARM_THUMB2) > copyCompactAndLinkCode<uint16_t>(macroAssembler, ownerUID, effort); > #elif CPU(ARM64) > copyCompactAndLinkCode<uint32_t>(macroAssembler, ownerUID, effort); > #endif // !ENABLE(BRANCH_COMPACTION) > > m_linkTasks = WTFMove(macroAssembler.m_linkTasks); > } > > > void LinkBuffer::allocate(MacroAssembler& macroAssembler, void* ownerUID, > JITCompilationEffort effort) > { > size_t initialSize = macroAssembler.m_assembler.codeSize(); > if (m_code) { > if (initialSize > m_size) > return; > > size_t nopsToFillInBytes = m_size - initialSize; > macroAssembler.emitNops(nopsToFillInBytes); > m_didAllocate = true; > return; > } > > > > > step 1: > ------- > InlineAccess.cpp - InlineAccess::rewireStubAsJump > > auto jump = jit.jump(); > LinkBuffer linkBuffer(jit, stubInfo.patch.start.dataLocation(), > jit.m_assembler.buffer().codeSize(), JITCompilationMustSucceed, > needsBranchCompaction); > > - create a jump instruction (4 bytes) + an entry in the constant pool. > - call LinkBuffer ctor with codeSize() == 4 > > step 2: > -------- > LinkBuffer.cpp - LinkBuffer::linkCode > > - LinkBuffer ctor calls LinkBuffer::linkCode > - flushConstantPool(true) is called > > The jump looks like after flushConstantPool(true): > -------------------------------------------------------------------------- > 0xbeffe5c4: ldr pc, [pc] ; 0xbeffe5cc > 0xbeffe5c8: b 0xbeffe5d0 > 0xbeffe5cc: ; <UNDEFINED> instruction: 0xffffffff > -------------------------------------------------------------------------- > 0xbeffe5c4: load the address from the constant pool and then jump to it > 0xbeffe5c8: barrier to jump over the constant pool (true arg of > flushConstantPool() ) > 0xbeffe5cc: constant pool, the real address will be stored here > > - allocate is called, where > initialSize = 12 (because flushConstantPool added two more instructions) > m_size = 4 (because LinkBuffer ctor call get 4 as argument) > > > if (m_code) { > if (initialSize > m_size) > return; <======== returns, m_didAllocate isn't > set! > > size_t nopsToFillInBytes = m_size - initialSize; > macroAssembler.emitNops(nopsToFillInBytes); > m_didAllocate = true; > return; > } > > > step 3: > -------- > - linkcode returns next to allocate because m_didAllocate is false > > My previous hack which added "m_didAllocate = true;" before the return > let the linkCode continue its work and copy the new IC to the proper place. > > My question is still open, what do you think, how should we fix this bug > properly? There is enough room for the 12 bytes long jump (ldr, b, constant > pool), but rewireStubAsJump doesn't respect the fact that the jump will be > bigger at the beginning of linkCode() function. We have same problems in > all newly added IC generator function. I see. I think the problem here is that LinkBuffer will actually grow the code size after it's passed an assembler. What we want, logically, is to have flushConstantPool() to be called before we pass in the assembler to LinkBuffer (the best way to accomplish this I'm not sure). Ans then we want to assert that the assembler buffer size after flushConstantPool() was called is <= the inline size reserved by StructureStubInfo. 1214867 15 284690 ossy 2016-07-27 06:33:34 -0700 Created attachment 284690 Patch It seems it fixes the assertion for me. 1215178 16 ossy 2016-07-28 02:08:14 -0700 ping? 1215214 17 284778 ossy 2016-07-28 05:12:03 -0700 Created attachment 284778 Patch updated after r203786, unfortunately now everything crashes, see bug160291 for details 1215231 18 284778 saam 2016-07-28 08:46:25 -0700 Comment on attachment 284778 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=284778&action=review > Source/JavaScriptCore/jit/JITMathIC.h:127 > + jit.m_assembler.buffer().flushConstantPool(); This is not all you want here. You want to make sure all the fast paths leave enough space for a constant pool flush. If you look elsewhere in this file, you'll see we refer to maxJumpSize (I forget the exact name). We'd want something similar for this. Can we reliably predict the size of the constant pool of a single jump? 1215517 19 ossy 2016-07-29 01:14:19 -0700 (In reply to comment #18) > Comment on attachment 284778 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=284778&action=review > > > Source/JavaScriptCore/jit/JITMathIC.h:127 > > + jit.m_assembler.buffer().flushConstantPool(); > > This is not all you want here. You want to make sure all the fast paths > leave enough space for a constant pool flush. > If you look elsewhere in this file, you'll see we refer to maxJumpSize (I > forget the exact name). > We'd want something similar for this. I found that MacroAssembler::maxJumpReplacementSize() - inlineSize nops are added in generateInline() : https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/jit/JITMathIC.h#L88 But I have no clue how many nops should be added and where. I really don't understand what this generateOutOfLine does and why. :-/ > Can we reliably predict the size of the constant pool of a single jump? I don't think so. Normally a jump could be an ldr + a branch + a constant (3 machine word, 3x4 = 12 bytes) But we can't determine how many constants are flushed. Constant pool are flushed if it is full or if it is triggered explicitly. Sometimes a flush call flushes hundreds constants belong to the previous couple opcodes. It is exactly what happens in bug160295. It seems the existance of constant pool and this new IC generating mechanism aren't compatible fundamentally. It would be great to find a way how to fix these issues. Maybe we should make the ARM traditional assembler somehow not to use constant pool for IC jumps, but movw+mowt+branch. But I don't know if other instructions in IC codes need constant pool or not. Additionally we should force flush the constant pool somehow before all IC generation: bug160295. 283634 2016-07-14 05:39:04 -0700 2016-07-27 06:33:26 -0700 Patch bug-159720-20160714053817.patch text/plain 1643 ossy U3VidmVyc2lvbiBSZXZpc2lvbjogMjAzMjIzCmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlw dENvcmUvQ2hhbmdlTG9nIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwppbmRleCBh ZWM5M2I2MTEyM2IyNzk4NWI2MjNhOTVhOGFhY2JkN2I5NzUwNGIzLi5hZmJlMzQ2ZGRmYTc0NDJi OWM3OTQyYmU5YzI5ODYxZTFiNWU3NmExIDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENv cmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKQEAgLTEs MyArMSwxMyBAQAorMjAxNi0wNy0xNCAgQ3NhYmEgT3N6dHJvZ29uw6FjICA8b3NzeUB3ZWJraXQu b3JnPgorCisgICAgICAgIFtBUk1dIEFTU0VSVElPTiBGQUlMRUQ6IGxpbmtCdWZmZXIuaXNWYWxp ZCgpIGluIElubGluZUFjY2Vzcy5jcHA6MjkxIGFmdGVyIHIyMDIyMTQKKyAgICAgICAgaHR0cHM6 Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTE1OTcyMAorCisgICAgICAgIFJldmll d2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgICogYnl0ZWNvZGUvSW5saW5lQWNjZXNz LmNwcDoKKyAgICAgICAgKEpTQzo6SW5saW5lQWNjZXNzOjpyZXdpcmVTdHViQXNKdW1wKTogUmVt b3ZlZCBpbmNvcnJlY3QgYXNzZXJ0aW9uLgorCiAyMDE2LTA3LTE0ICBZb3Vlbm4gRmFibGV0ICA8 eW91ZW5uQGFwcGxlLmNvbT4KIAogICAgICAgICBET00gdmFsdWUgaXRlcmFibGUgaW50ZXJmYWNl cyBzaG91bGQgdXNlIEFycmF5IHByb3RvdHlwZSBtZXRob2RzCmRpZmYgLS1naXQgYS9Tb3VyY2Uv SmF2YVNjcmlwdENvcmUvYnl0ZWNvZGUvSW5saW5lQWNjZXNzLmNwcCBiL1NvdXJjZS9KYXZhU2Ny aXB0Q29yZS9ieXRlY29kZS9JbmxpbmVBY2Nlc3MuY3BwCmluZGV4IDU0YmY3YjcwMTU1OGVjMDJj OTVlMGY5ODNjMmYyNDFhMTNkYjFhMjMuLjgyYTQ3MTc4MzI5NzQ3NzI0NjU1Yzg0YjE3MWMyZWIz MjQ3ZDZjNDggMTAwNjQ0Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9ieXRlY29kZS9Jbmxp bmVBY2Nlc3MuY3BwCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9ieXRlY29kZS9JbmxpbmVB Y2Nlc3MuY3BwCkBAIC0yODgsNyArMjg4LDYgQEAgdm9pZCBJbmxpbmVBY2Nlc3M6OnJld2lyZVN0 dWJBc0p1bXAoVk0mIHZtLCBTdHJ1Y3R1cmVTdHViSW5mbyYgc3R1YkluZm8sIENvZGVMb2MKICAg ICAvLyBXZSBkb24ndCBuZWVkIGEgbm9wIHNsZWQgaGVyZSBiZWNhdXNlIG5vYm9keSBzaG91bGQg YmUganVtcGluZyBpbnRvIHRoZSBtaWRkbGUgb2YgYW4gSUMuCiAgICAgYm9vbCBuZWVkc0JyYW5j aENvbXBhY3Rpb24gPSBmYWxzZTsKICAgICBMaW5rQnVmZmVyIGxpbmtCdWZmZXIoaml0LCBzdHVi SW5mby5wYXRjaC5zdGFydC5kYXRhTG9jYXRpb24oKSwgaml0Lm1fYXNzZW1ibGVyLmJ1ZmZlcigp LmNvZGVTaXplKCksIEpJVENvbXBpbGF0aW9uTXVzdFN1Y2NlZWQsIG5lZWRzQnJhbmNoQ29tcGFj dGlvbik7Ci0gICAgUkVMRUFTRV9BU1NFUlQobGlua0J1ZmZlci5pc1ZhbGlkKCkpOwogICAgIGxp bmtCdWZmZXIubGluayhqdW1wLCB0YXJnZXQpOwogCiAgICAgRklOQUxJWkVfQ09ERShsaW5rQnVm ZmVyLCAoIklubGluZUFjY2VzczogbGlua2luZyBjb25zdGFudCBqdW1wIikpOwo= 284690 2016-07-27 06:33:34 -0700 2016-07-28 05:11:56 -0700 Patch bug-159720-20160727063223.patch text/plain 3270 ossy U3VidmVyc2lvbiBSZXZpc2lvbjogMjAzNzcyCmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlw dENvcmUvQ2hhbmdlTG9nIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwppbmRleCBk YzZhOTk0N2NmMWExNjVkNGJhOTM4MjllNzVlYzU1N2I2YjU1MmNlLi5jYzhlYjUxODE5ZDQ1ZWY5 ZTViOTM4YmUzMGMyYWVjY2JkMDcwZmJkIDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENv cmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKQEAgLTEs MyArMSwxNyBAQAorMjAxNi0wNy0yNyAgQ3NhYmEgT3N6dHJvZ29uw6FjICA8b3NzeUB3ZWJraXQu b3JnPgorCisgICAgICAgIFtBUk1dIEFTU0VSVElPTiBGQUlMRUQ6IGxpbmtCdWZmZXIuaXNWYWxp ZCgpIGluIElubGluZUFjY2Vzcy5jcHA6MjkxIGFmdGVyIHIyMDIyMTQgYW5kIHIyMDM1MzcKKyAg ICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTE1OTcyMAorCisg ICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgICogYXNzZW1ibGVy L0xpbmtCdWZmZXIuY3BwOgorICAgICAgICAoSlNDOjpMaW5rQnVmZmVyOjpsaW5rQ29kZSk6Cisg ICAgICAgICogYnl0ZWNvZGUvSW5saW5lQWNjZXNzLmNwcDoKKyAgICAgICAgKEpTQzo6SW5saW5l QWNjZXNzOjpyZXdpcmVTdHViQXNKdW1wKToKKyAgICAgICAgKiBqaXQvSklUTWF0aElDLmg6Cisg ICAgICAgIChKU0M6OkpJVE1hdGhJQzo6Z2VuZXJhdGVPdXRPZkxpbmUpOgorCiAyMDE2LTA3LTI2 ICBTYWFtIEJhcmF0aSAgPHNiYXJhdGlAYXBwbGUuY29tPgogCiAgICAgICAgIHJvbGxvdXQgcjIw MzY2NgpkaWZmIC0tZ2l0IGEvU291cmNlL0phdmFTY3JpcHRDb3JlL2Fzc2VtYmxlci9MaW5rQnVm ZmVyLmNwcCBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9hc3NlbWJsZXIvTGlua0J1ZmZlci5jcHAK aW5kZXggMzI2ZDIwZDQ0NzdiYjIwM2U1YWEwOTY3NTdjZjZjZTQwNGFjMWMyNy4uMzI0MmZjODUx NDQ2YjdlZmI2NzQ3NDg1MWUzNzU4ZDk5OTUxZWE3YyAxMDA2NDQKLS0tIGEvU291cmNlL0phdmFT Y3JpcHRDb3JlL2Fzc2VtYmxlci9MaW5rQnVmZmVyLmNwcAorKysgYi9Tb3VyY2UvSmF2YVNjcmlw dENvcmUvYXNzZW1ibGVyL0xpbmtCdWZmZXIuY3BwCkBAIC0xOTgsNyArMTk4LDcgQEAgdm9pZCBM aW5rQnVmZmVyOjpsaW5rQ29kZShNYWNyb0Fzc2VtYmxlciYgbWFjcm9Bc3NlbWJsZXIsIHZvaWQq IG93bmVyVUlELCBKSVRDb20KIHsKICNpZiAhRU5BQkxFKEJSQU5DSF9DT01QQUNUSU9OKQogI2lm IGRlZmluZWQoQVNTRU1CTEVSX0hBU19DT05TVEFOVF9QT09MKSAmJiBBU1NFTUJMRVJfSEFTX0NP TlNUQU5UX1BPT0wKLSAgICBtYWNyb0Fzc2VtYmxlci5tX2Fzc2VtYmxlci5idWZmZXIoKS5mbHVz aENvbnN0YW50UG9vbChmYWxzZSk7CisgICAgbWFjcm9Bc3NlbWJsZXIubV9hc3NlbWJsZXIuYnVm ZmVyKCkuZmx1c2hDb25zdGFudFBvb2woKTsKICNlbmRpZgogICAgIGFsbG9jYXRlKG1hY3JvQXNz ZW1ibGVyLCBvd25lclVJRCwgZWZmb3J0KTsKICAgICBpZiAoIW1fZGlkQWxsb2NhdGUpCmRpZmYg LS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvYnl0ZWNvZGUvSW5saW5lQWNjZXNzLmNwcCBi L1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9ieXRlY29kZS9JbmxpbmVBY2Nlc3MuY3BwCmluZGV4IDU0 YmY3YjcwMTU1OGVjMDJjOTVlMGY5ODNjMmYyNDFhMTNkYjFhMjMuLmQ1Y2ViM2JiMDA3YWZmNThh YjJlZjhhMzgyYTgxMjIwMDEzNjI0NzkgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0Q29y ZS9ieXRlY29kZS9JbmxpbmVBY2Nlc3MuY3BwCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9i eXRlY29kZS9JbmxpbmVBY2Nlc3MuY3BwCkBAIC0yODUsNiArMjg1LDEwIEBAIHZvaWQgSW5saW5l QWNjZXNzOjpyZXdpcmVTdHViQXNKdW1wKFZNJiB2bSwgU3RydWN0dXJlU3R1YkluZm8mIHN0dWJJ bmZvLCBDb2RlTG9jCiAKICAgICBhdXRvIGp1bXAgPSBqaXQuanVtcCgpOwogCisjaWYgZGVmaW5l ZChBU1NFTUJMRVJfSEFTX0NPTlNUQU5UX1BPT0wpICYmIEFTU0VNQkxFUl9IQVNfQ09OU1RBTlRf UE9PTAorICAgIGppdC5tX2Fzc2VtYmxlci5idWZmZXIoKS5mbHVzaENvbnN0YW50UG9vbCgpOwor I2VuZGlmCisKICAgICAvLyBXZSBkb24ndCBuZWVkIGEgbm9wIHNsZWQgaGVyZSBiZWNhdXNlIG5v Ym9keSBzaG91bGQgYmUganVtcGluZyBpbnRvIHRoZSBtaWRkbGUgb2YgYW4gSUMuCiAgICAgYm9v bCBuZWVkc0JyYW5jaENvbXBhY3Rpb24gPSBmYWxzZTsKICAgICBMaW5rQnVmZmVyIGxpbmtCdWZm ZXIoaml0LCBzdHViSW5mby5wYXRjaC5zdGFydC5kYXRhTG9jYXRpb24oKSwgaml0Lm1fYXNzZW1i bGVyLmJ1ZmZlcigpLmNvZGVTaXplKCksIEpJVENvbXBpbGF0aW9uTXVzdFN1Y2NlZWQsIG5lZWRz QnJhbmNoQ29tcGFjdGlvbik7CmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvaml0 L0pJVE1hdGhJQy5oIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL2ppdC9KSVRNYXRoSUMuaAppbmRl eCBiZDU0ZDgzOWQ3MDE3NTBjYjUzYjJkNWU0ZDhjODNlYjZlMDU1Y2M4Li4wOGQ2NWNlYTgwNmU3 ODdhYzM0MDc0MWNkMTEzZDg1YzYyNGM5NzU3IDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlw dENvcmUvaml0L0pJVE1hdGhJQy5oCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9qaXQvSklU TWF0aElDLmgKQEAgLTEzMSw2ICsxMzEsMTEgQEAgcHVibGljOgogICAgICAgICB7CiAgICAgICAg ICAgICBDQ2FsbEhlbHBlcnMgaml0KCZ2bSwgY29kZUJsb2NrKTsKICAgICAgICAgICAgIGF1dG8g anVtcCA9IGppdC5qdW1wKCk7CisKKyNpZiBkZWZpbmVkKEFTU0VNQkxFUl9IQVNfQ09OU1RBTlRf UE9PTCkgJiYgQVNTRU1CTEVSX0hBU19DT05TVEFOVF9QT09MCisgICAgICAgICAgICBqaXQubV9h c3NlbWJsZXIuYnVmZmVyKCkuZmx1c2hDb25zdGFudFBvb2woKTsKKyNlbmRpZgorCiAgICAgICAg ICAgICAvLyBXZSBkb24ndCBuZWVkIGEgbm9wIHNsZWQgaGVyZSBiZWNhdXNlIG5vYm9keSBzaG91 bGQgYmUganVtcGluZyBpbnRvIHRoZSBtaWRkbGUgb2YgYW4gSUMuCiAgICAgICAgICAgICBib29s IG5lZWRzQnJhbmNoQ29tcGFjdGlvbiA9IGZhbHNlOwogICAgICAgICAgICAgUkVMRUFTRV9BU1NF UlQoaml0Lm1fYXNzZW1ibGVyLmJ1ZmZlcigpLmNvZGVTaXplKCkgPD0gc3RhdGljX2Nhc3Q8c2l6 ZV90PihtX2lubGluZVNpemUpKTsK 284778 2016-07-28 05:12:03 -0700 2016-07-28 08:46:25 -0700 Patch bug-159720-20160728051050.patch text/plain 3387 ossy U3VidmVyc2lvbiBSZXZpc2lvbjogMjAzODE3CmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlw dENvcmUvQ2hhbmdlTG9nIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwppbmRleCAw ZTM0Nzk1Mzg4NmNmZGMyNTQwMjEzZDQxOTZmMWVlMTdjMmQzOTYwLi43YTUyYzM2MDUxMTU1ODlk MjRkMzJhMjVhZWRhNzVkNWI3YWZjYmQ4IDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENv cmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKQEAgLTEs NSArMSwxOSBAQAogMjAxNi0wNy0yOCAgQ3NhYmEgT3N6dHJvZ29uw6FjICA8b3NzeUB3ZWJraXQu b3JnPgogCisgICAgICAgIFtBUk1dIEFTU0VSVElPTiBGQUlMRUQ6IGxpbmtCdWZmZXIuaXNWYWxp ZCgpIGluIElubGluZUFjY2Vzcy5jcHA6MjkxIGFmdGVyIHIyMDIyMTQgYW5kIHIyMDM1MzcKKyAg ICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTE1OTcyMAorCisg ICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgICogYXNzZW1ibGVy L0xpbmtCdWZmZXIuY3BwOgorICAgICAgICAoSlNDOjpMaW5rQnVmZmVyOjpsaW5rQ29kZSk6Cisg ICAgICAgICogYnl0ZWNvZGUvSW5saW5lQWNjZXNzLmNwcDoKKyAgICAgICAgKEpTQzo6SW5saW5l QWNjZXNzOjpyZXdpcmVTdHViQXNKdW1wKToKKyAgICAgICAgKiBqaXQvSklUTWF0aElDLmg6Cisg ICAgICAgIChKU0M6OkpJVE1hdGhJQzo6Z2VuZXJhdGVPdXRPZkxpbmUpOgorCisyMDE2LTA3LTI4 ICBDc2FiYSBPc3p0cm9nb27DoWMgIDxvc3N5QHdlYmtpdC5vcmc+CisKICAgICAgICAgW0FSTV0g VHlwbyBmaXggYWZ0ZXIgcjEyMTg4NQogICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9z aG93X2J1Zy5jZ2k/aWQ9MTYwMjg4CiAKZGlmZiAtLWdpdCBhL1NvdXJjZS9KYXZhU2NyaXB0Q29y ZS9hc3NlbWJsZXIvTGlua0J1ZmZlci5jcHAgYi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvYXNzZW1i bGVyL0xpbmtCdWZmZXIuY3BwCmluZGV4IDMyNmQyMGQ0NDc3YmIyMDNlNWFhMDk2NzU3Y2Y2Y2U0 MDRhYzFjMjcuLjMyNDJmYzg1MTQ0NmI3ZWZiNjc0NzQ4NTFlMzc1OGQ5OTk1MWVhN2MgMTAwNjQ0 Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9hc3NlbWJsZXIvTGlua0J1ZmZlci5jcHAKKysr IGIvU291cmNlL0phdmFTY3JpcHRDb3JlL2Fzc2VtYmxlci9MaW5rQnVmZmVyLmNwcApAQCAtMTk4 LDcgKzE5OCw3IEBAIHZvaWQgTGlua0J1ZmZlcjo6bGlua0NvZGUoTWFjcm9Bc3NlbWJsZXImIG1h Y3JvQXNzZW1ibGVyLCB2b2lkKiBvd25lclVJRCwgSklUQ29tCiB7CiAjaWYgIUVOQUJMRShCUkFO Q0hfQ09NUEFDVElPTikKICNpZiBkZWZpbmVkKEFTU0VNQkxFUl9IQVNfQ09OU1RBTlRfUE9PTCkg JiYgQVNTRU1CTEVSX0hBU19DT05TVEFOVF9QT09MCi0gICAgbWFjcm9Bc3NlbWJsZXIubV9hc3Nl bWJsZXIuYnVmZmVyKCkuZmx1c2hDb25zdGFudFBvb2woZmFsc2UpOworICAgIG1hY3JvQXNzZW1i bGVyLm1fYXNzZW1ibGVyLmJ1ZmZlcigpLmZsdXNoQ29uc3RhbnRQb29sKCk7CiAjZW5kaWYKICAg ICBhbGxvY2F0ZShtYWNyb0Fzc2VtYmxlciwgb3duZXJVSUQsIGVmZm9ydCk7CiAgICAgaWYgKCFt X2RpZEFsbG9jYXRlKQpkaWZmIC0tZ2l0IGEvU291cmNlL0phdmFTY3JpcHRDb3JlL2J5dGVjb2Rl L0lubGluZUFjY2Vzcy5jcHAgYi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvYnl0ZWNvZGUvSW5saW5l QWNjZXNzLmNwcAppbmRleCA1NGJmN2I3MDE1NThlYzAyYzk1ZTBmOTgzYzJmMjQxYTEzZGIxYTIz Li5kNWNlYjNiYjAwN2FmZjU4YWIyZWY4YTM4MmE4MTIyMDAxMzYyNDc5IDEwMDY0NAotLS0gYS9T b3VyY2UvSmF2YVNjcmlwdENvcmUvYnl0ZWNvZGUvSW5saW5lQWNjZXNzLmNwcAorKysgYi9Tb3Vy Y2UvSmF2YVNjcmlwdENvcmUvYnl0ZWNvZGUvSW5saW5lQWNjZXNzLmNwcApAQCAtMjg1LDYgKzI4 NSwxMCBAQCB2b2lkIElubGluZUFjY2Vzczo6cmV3aXJlU3R1YkFzSnVtcChWTSYgdm0sIFN0cnVj dHVyZVN0dWJJbmZvJiBzdHViSW5mbywgQ29kZUxvYwogCiAgICAgYXV0byBqdW1wID0gaml0Lmp1 bXAoKTsKIAorI2lmIGRlZmluZWQoQVNTRU1CTEVSX0hBU19DT05TVEFOVF9QT09MKSAmJiBBU1NF TUJMRVJfSEFTX0NPTlNUQU5UX1BPT0wKKyAgICBqaXQubV9hc3NlbWJsZXIuYnVmZmVyKCkuZmx1 c2hDb25zdGFudFBvb2woKTsKKyNlbmRpZgorCiAgICAgLy8gV2UgZG9uJ3QgbmVlZCBhIG5vcCBz bGVkIGhlcmUgYmVjYXVzZSBub2JvZHkgc2hvdWxkIGJlIGp1bXBpbmcgaW50byB0aGUgbWlkZGxl IG9mIGFuIElDLgogICAgIGJvb2wgbmVlZHNCcmFuY2hDb21wYWN0aW9uID0gZmFsc2U7CiAgICAg TGlua0J1ZmZlciBsaW5rQnVmZmVyKGppdCwgc3R1YkluZm8ucGF0Y2guc3RhcnQuZGF0YUxvY2F0 aW9uKCksIGppdC5tX2Fzc2VtYmxlci5idWZmZXIoKS5jb2RlU2l6ZSgpLCBKSVRDb21waWxhdGlv bk11c3RTdWNjZWVkLCBuZWVkc0JyYW5jaENvbXBhY3Rpb24pOwpkaWZmIC0tZ2l0IGEvU291cmNl L0phdmFTY3JpcHRDb3JlL2ppdC9KSVRNYXRoSUMuaCBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9q aXQvSklUTWF0aElDLmgKaW5kZXggMDgyNDk4YjhiYzRhYzAwOTU0NTNhYjBhMTRlYWNkOGFkMTJi NDQ2ZC4uZTZmNjE4MjJjMWM1MjAxYWZjZjM0ZGI3NzdiMWUyNjc2YTA4MzU3NiAxMDA2NDQKLS0t IGEvU291cmNlL0phdmFTY3JpcHRDb3JlL2ppdC9KSVRNYXRoSUMuaAorKysgYi9Tb3VyY2UvSmF2 YVNjcmlwdENvcmUvaml0L0pJVE1hdGhJQy5oCkBAIC0xMjIsNiArMTIyLDExIEBAIHB1YmxpYzoK ICAgICAgICAgYXV0byBsaW5rSnVtcFRvT3V0T2ZMaW5lU25pcHBldCA9IFsmXSAoKSB7CiAgICAg ICAgICAgICBDQ2FsbEhlbHBlcnMgaml0KCZ2bSwgY29kZUJsb2NrKTsKICAgICAgICAgICAgIGF1 dG8ganVtcCA9IGppdC5qdW1wKCk7CisKKyNpZiBkZWZpbmVkKEFTU0VNQkxFUl9IQVNfQ09OU1RB TlRfUE9PTCkgJiYgQVNTRU1CTEVSX0hBU19DT05TVEFOVF9QT09MCisgICAgICAgICAgICBqaXQu bV9hc3NlbWJsZXIuYnVmZmVyKCkuZmx1c2hDb25zdGFudFBvb2woKTsKKyNlbmRpZgorCiAgICAg ICAgICAgICAvLyBXZSBkb24ndCBuZWVkIGEgbm9wIHNsZWQgaGVyZSBiZWNhdXNlIG5vYm9keSBz aG91bGQgYmUganVtcGluZyBpbnRvIHRoZSBtaWRkbGUgb2YgYW4gSUMuCiAgICAgICAgICAgICBi b29sIG5lZWRzQnJhbmNoQ29tcGFjdGlvbiA9IGZhbHNlOwogICAgICAgICAgICAgUkVMRUFTRV9B U1NFUlQoaml0Lm1fYXNzZW1ibGVyLmJ1ZmZlcigpLmNvZGVTaXplKCkgPD0gc3RhdGljX2Nhc3Q8 c2l6ZV90PihtX2lubGluZVNpemUpKTsK