157741 2016-05-16 08:54:22 -0700 JSC: DFG::SpeculativeJIT::compile special case for MIPS for PutByValWithThis 2016-05-19 10:26:15 -0700 1 1 1 Unclassified WebKit JavaScriptCore Other Other Linux RESOLVED FIXED P2 Normal --- 1 guijemont webkit-unassigned annulen commit-queue guijemont jbriance keith_miller mark.lam msaboff saam oldest_to_newest 1193392 0 guijemont 2016-05-16 08:54:22 -0700 WebKit does not build on MIPS due to the change in http://trac.webkit.org/changeset/200586 . A special case is needed for MIPS as well as x86 because MIPS doesn't have enough registers either, and the function call ABI is different on MIPS. 1193393 1 guijemont 2016-05-16 08:54:35 -0700 I am working on a patch. 1193407 2 279023 guijemont 2016-05-16 10:32:00 -0700 Created attachment 279023 Patch A patch addressing the issue 1193416 3 guijemont 2016-05-16 10:41:59 -0700 This is the code my patch generates: move a0,s8 move a1,zero sw v1,-12(s8) sw v0,-16(s8) lw t6,-20(s8) lw v0,-24(s8) sw t5,-36(s8) sw t4,-40(s8) lw v1,-12(s8) lw t4,-16(s8) move a2,v0 move a3,t6 sw t2,16(sp) sw t3,20(sp) sw t4,24(sp) sw v1,28(sp) sw t3,-28(s8) sw t2,-32(s8) lw v0,-36(s8) lw v1,-40(s8) sw v1,32(sp) sw v0,36(sp) li t0,2 sw t0,28(s8) lui t9,0x1d3 ori t9,t9,0x33f4 jalr t9 nop I am wondering whether there is a way to have basePayload and baseTag load directly into the right argument registers, which would save these two moves. 1193445 4 279023 saam 2016-05-16 11:31:05 -0700 Comment on attachment 279023 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=279023&action=review > Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp:2931 > + m_jit.move(TrustedImm32(0), GPRInfo::argumentGPR1); Is this because 64-bit values need to be aligned on even registers? 1193452 5 279023 annulen 2016-05-16 11:45:06 -0700 Comment on attachment 279023 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=279023&action=review > Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp:2933 > + { If we won't find a way to avoid excessive moves, I propose to merge this code with X86 code path. Only top 4 lines are different for MIPS, everything else looks like an exact copy of X86 1193487 6 279023 saam 2016-05-16 13:17:15 -0700 Comment on attachment 279023 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=279023&action=review >> Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp:2933 >> + { > > If we won't find a way to avoid excessive moves, I propose to merge this code with X86 code path. Only top 4 lines are different for MIPS, everything else looks like an exact copy of X86 IMO, this will make the code harder to read. > Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp:2947 > + m_jit.move(basePayload, GPRInfo::argumentGPR2); > + m_jit.move(baseTag, GPRInfo::argumentGPR3); This is wrong if basePayload/baseTag are aliased to argument registers w/ each other. i.e, if basePayload is argumentGPR3 and baseTag is argumentGPR2, this code will do the wrong thing. 1193514 7 279023 guijemont 2016-05-16 13:52:49 -0700 Comment on attachment 279023 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=279023&action=review >> Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp:2931 >> + m_jit.move(TrustedImm32(0), GPRInfo::argumentGPR1); > > Is this because 64-bit values need to be aligned on even registers? That was my reasoning. Though looking at the code generated by gcc for operationPutByValWithThisStrict(), even in -O0 it never accesses $a1 or the corresponding address on the stack, so I will remove that one line in a subsequent version of the patch. The next value (which is 64 bits) definitely needs to be on $a2 and $a3 though (and accordingly, 4 stack entries need to be reserved for the values we put in $a0-$a3, though they don't need to be set by the caller. >>> Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp:2933 >>> + { >> >> If we won't find a way to avoid excessive moves, I propose to merge this code with X86 code path. Only top 4 lines are different for MIPS, everything else looks like an exact copy of X86 > > IMO, this will make the code harder to read. Guilty as charged: I copy-pasted the x86 code and worked from there, I think I was expecting more difference in the end. But yeah, I guess it's a matter of avoiding code duplication vs readability. >> Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp:2947 >> + m_jit.move(baseTag, GPRInfo::argumentGPR3); > > This is wrong if basePayload/baseTag are aliased to argument registers w/ each other. > i.e, if basePayload is argumentGPR3 and baseTag is argumentGPR2, this code will do the wrong thing. I thought this was not possible because the argumentGPR's are not in GPRInfo::toRegister() (and not counted in GPRInfo::numberOfRegisters). Including them might be an idea for the future though, as I suspect more registers available might improve performances (and ARM does that so it's probably possible), but I think that's a trickier change, and I'd like to get the build unbroken. 1193519 8 279023 saam 2016-05-16 14:01:38 -0700 Comment on attachment 279023 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=279023&action=review >>> Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp:2947 >>> + m_jit.move(baseTag, GPRInfo::argumentGPR3); >> >> This is wrong if basePayload/baseTag are aliased to argument registers w/ each other. >> i.e, if basePayload is argumentGPR3 and baseTag is argumentGPR2, this code will do the wrong thing. > > I thought this was not possible because the argumentGPR's are not in GPRInfo::toRegister() (and not counted in GPRInfo::numberOfRegisters). Including them might be an idea for the future though, as I suspect more registers available might improve performances (and ARM does that so it's probably possible), but I think that's a trickier change, and I'd like to get the build unbroken. I don't quite understand your response here. Tag/Payload regs will be allocated by the DFG's register allocator. It will happily use argument registers. I don't think this makes the code harder to read. All code we write that sets up a call frame must account for this. 1193566 9 279023 guijemont 2016-05-16 15:40:31 -0700 Comment on attachment 279023 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=279023&action=review >>>> Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp:2947 >>>> + m_jit.move(baseTag, GPRInfo::argumentGPR3); >>> >>> This is wrong if basePayload/baseTag are aliased to argument registers w/ each other. >>> i.e, if basePayload is argumentGPR3 and baseTag is argumentGPR2, this code will do the wrong thing. >> >> I thought this was not possible because the argumentGPR's are not in GPRInfo::toRegister() (and not counted in GPRInfo::numberOfRegisters). Including them might be an idea for the future though, as I suspect more registers available might improve performances (and ARM does that so it's probably possible), but I think that's a trickier change, and I'd like to get the build unbroken. > > I don't quite understand your response here. Tag/Payload regs will be allocated by the DFG's register allocator. It will happily use argument registers. > I don't think this makes the code harder to read. All code we write that sets up a call frame must account for this. Sorry if that wasn't clear, and there is a possibility that I misunderstand something. What I mean is that DFG::RegisterBank<GPRInfo>::allocate() (see ::allocateInternal()) uses GPRInfo::toRegister() (and GPRInfo::numberOfRegisters as RegisterBank::NUM_REGS) as its source of registers. In the case of MIPS, GPRInfo::toRegister() never returns an argumentGPRx. Therefore baseTag and basePayload cannot be an argumentGPRx register. That's my current understanding at least. 1193585 10 saam 2016-05-16 16:05:41 -0700 (In reply to comment #9) > Comment on attachment 279023 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=279023&action=review > > >>>> Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp:2947 > >>>> + m_jit.move(baseTag, GPRInfo::argumentGPR3); > >>> > >>> This is wrong if basePayload/baseTag are aliased to argument registers w/ each other. > >>> i.e, if basePayload is argumentGPR3 and baseTag is argumentGPR2, this code will do the wrong thing. > >> > >> I thought this was not possible because the argumentGPR's are not in GPRInfo::toRegister() (and not counted in GPRInfo::numberOfRegisters). Including them might be an idea for the future though, as I suspect more registers available might improve performances (and ARM does that so it's probably possible), but I think that's a trickier change, and I'd like to get the build unbroken. > > > > I don't quite understand your response here. Tag/Payload regs will be allocated by the DFG's register allocator. It will happily use argument registers. > > I don't think this makes the code harder to read. All code we write that sets up a call frame must account for this. > > Sorry if that wasn't clear, and there is a possibility that I misunderstand > something. What I mean is that DFG::RegisterBank<GPRInfo>::allocate() (see > ::allocateInternal()) uses GPRInfo::toRegister() (and > GPRInfo::numberOfRegisters as RegisterBank::NUM_REGS) as its source of > registers. In the case of MIPS, GPRInfo::toRegister() never returns an > argumentGPRx. Therefore baseTag and basePayload cannot be an argumentGPRx > register. That's my current understanding at least. I see. Makes sense. 1193767 11 279023 jbriance 2016-05-17 00:35:39 -0700 Comment on attachment 279023 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=279023&action=review Looks good to me >>> Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp:2931 >>> + m_jit.move(TrustedImm32(0), GPRInfo::argumentGPR1); >> >> Is this because 64-bit values need to be aligned on even registers? > > That was my reasoning. Though looking at the code generated by gcc for operationPutByValWithThisStrict(), even in -O0 it never accesses $a1 or the corresponding address on the stack, so I will remove that one line in a subsequent version of the patch. The next value (which is 64 bits) definitely needs to be on $a2 and $a3 though (and accordingly, 4 stack entries need to be reserved for the values we put in $a0-$a3, though they don't need to be set by the caller. I agree, there is no need to set $a1 to 0 here. 1194793 12 279395 guijemont 2016-05-19 09:54:58 -0700 Created attachment 279395 Patch New patch, not setting up $a1 and explaining the "alignment". 1194795 13 guijemont 2016-05-19 09:58:20 -0700 I spent some time trying to avoid the move, doing the following instead of setting up a JSValueOperand and moving its registers to $a2/$a3: VirtualRegister virtualRegister = m_jit.graph().varArgChild(node, 0)->virtualRegister(); m_jit.load32(JITCompiler::payloadFor(virtualRegister), GPRInfo::argumentGPR2); m_jit.load32(JITCompiler::tagFor(virtualRegister), GPRInfo::argumentGPR3); But then, when I run super-property-access.js, I get this: # jsc super-property-access.js Exception: TypeError: Attempted to assign to readonly property. baz@super-property-access.js:442:23 super-property-access.js:450:16 test@super-property-access.js:9:10 global code@super-property-access.js:429:5 # I spent some time investigating that but could not really understand what's wrong with that approach. So for now I think we can stick with the latest patch I posted. 1194814 14 279395 commit-queue 2016-05-19 10:26:11 -0700 Comment on attachment 279395 Patch Clearing flags on attachment: 279395 Committed r201170: <http://trac.webkit.org/changeset/201170> 1194815 15 commit-queue 2016-05-19 10:26:15 -0700 All reviewed patches have been landed. Closing bug. 279023 2016-05-16 10:32:00 -0700 2016-05-19 09:54:52 -0700 Patch bug-157741-20160516123256.patch text/plain 3387 guijemont U3VidmVyc2lvbiBSZXZpc2lvbjogMjAwOTQyCmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlw dENvcmUvQ2hhbmdlTG9nIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwppbmRleCAw MDc5Y2I4NjNhM2IzMzFkMDQxYjFmMjlmNzYzYTU5NjEwZWRmODMwLi4xOTY0NzIxZGRlNWU5NWUy YjIzMjM5YWFjZWI0MzM5OWUyNmVmNGIwIDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENv cmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKQEAgLTEs MyArMSwxNyBAQAorMjAxNi0wNS0xNiAgR3VpbGxhdW1lIEVtb250ICA8Z3VpamVtb250QGlnYWxp YS5jb20+CisKKyAgICAgICAgSlNDOiBERkc6OlNwZWN1bGF0aXZlSklUOjpjb21waWxlIHNwZWNp YWwgY2FzZSBmb3IgTUlQUyBmb3IgUHV0QnlWYWxXaXRoVGhpcworICAgICAgICBodHRwczovL2J1 Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTU3NzQxCisKKyAgICAgICAgUmV2aWV3ZWQg YnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgVGhlIFB1dEJ5VmFsV2l0aFRoaXMgY2FzZSBu ZWVkcyBhIHNwZWNpYWwgY2FzZSBmb3IgTUlQUyBiZWNhdXNlIHdlCisgICAgICAgIGRvbid0IGhh dmUgZW5vdWdoIHJlZ2lzdGVycy4gVGhlIHNwZWNpYWwgY2FzZSBuZWVkcyB0byBiZSBkaWZmZXJl bnQKKyAgICAgICAgZnJvbSB0aGUgeDg2IG9uZSBiZWNhdXNlIHdlIGhhdmUgYSBkaWZmZXJlbnQg QUJJLgorCisgICAgICAgICogZGZnL0RGR1NwZWN1bGF0aXZlSklUMzJfNjQuY3BwOgorICAgICAg ICAoSlNDOjpERkc6OlNwZWN1bGF0aXZlSklUOjpjb21waWxlKToKKwogMjAxNi0wNS0xNSAgRmls aXAgUGl6bG8gIDxmcGl6bG9AYXBwbGUuY29tPgogCiAgICAgICAgIERGRzo6UGxhbiBzaG91bGRu J3QgcmVhZCBmcm9tIGl0cyBWTSBvbmNlIGl0J3MgYmVlbiBjYW5jZWxsZWQKZGlmZiAtLWdpdCBh L1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9kZmcvREZHU3BlY3VsYXRpdmVKSVQzMl82NC5jcHAgYi9T b3VyY2UvSmF2YVNjcmlwdENvcmUvZGZnL0RGR1NwZWN1bGF0aXZlSklUMzJfNjQuY3BwCmluZGV4 IDMzOGFiYTcyMWRlMGM1OTRhNzc0ZmMyYjViOTM4MzYyYzQ2MjMxOGYuLmIxZGRmZjhmZGJhYThk ZTY0NjBlYWRjNzFmY2NiMzA0Y2M4ZjIwY2UgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0 Q29yZS9kZmcvREZHU3BlY3VsYXRpdmVKSVQzMl82NC5jcHAKKysrIGIvU291cmNlL0phdmFTY3Jp cHRDb3JlL2RmZy9ERkdTcGVjdWxhdGl2ZUpJVDMyXzY0LmNwcApAQCAtMjkyNCw2ICsyOTI0LDQ2 IEBAIHZvaWQgU3BlY3VsYXRpdmVKSVQ6OmNvbXBpbGUoTm9kZSogbm9kZSkKICAgICAgICAgZmx1 c2hSZWdpc3RlcnMoKTsKICAgICAgICAgYXBwZW5kQ2FsbChtX2ppdC5pc1N0cmljdE1vZGVGb3Io bm9kZS0+b3JpZ2luLnNlbWFudGljKSA/IG9wZXJhdGlvblB1dEJ5VmFsV2l0aFRoaXNTdHJpY3Qg OiBvcGVyYXRpb25QdXRCeVZhbFdpdGhUaGlzKTsKICAgICAgICAgbV9qaXQuZXhjZXB0aW9uQ2hl Y2soKTsKKyNlbGlmIENQVShNSVBTKQorICAgICAgICAvLyBXZSBkb24ndCBoYXZlIGVub3VnaCBy ZWdpc3RlcnMgb24gTUlQUyBlaXRoZXIgYnV0IHRoZSBBQkkgaXMgYSBsaXR0bGUgZGlmZmVyZW50 LgorICAgICAgICB1bnNpZ25lZCBpbmRleCA9IDQ7CisgICAgICAgIG1faml0Lm1vdmUoR1BSSW5m bzo6Y2FsbEZyYW1lUmVnaXN0ZXIsIEdQUkluZm86OmFyZ3VtZW50R1BSMCk7CisgICAgICAgIG1f aml0Lm1vdmUoVHJ1c3RlZEltbTMyKDApLCBHUFJJbmZvOjphcmd1bWVudEdQUjEpOworCisgICAg ICAgIHsKKyAgICAgICAgICAgIEpTVmFsdWVPcGVyYW5kIGJhc2UodGhpcywgbV9qaXQuZ3JhcGgo KS52YXJBcmdDaGlsZChub2RlLCAwKSk7CisgICAgICAgICAgICBHUFJSZWcgYmFzZVRhZyA9IGJh c2UudGFnR1BSKCk7CisgICAgICAgICAgICBHUFJSZWcgYmFzZVBheWxvYWQgPSBiYXNlLnBheWxv YWRHUFIoKTsKKworICAgICAgICAgICAgSlNWYWx1ZU9wZXJhbmQgdGhpc1ZhbHVlKHRoaXMsIG1f aml0LmdyYXBoKCkudmFyQXJnQ2hpbGQobm9kZSwgMSkpOworICAgICAgICAgICAgR1BSUmVnIHRo aXNWYWx1ZVRhZyA9IHRoaXNWYWx1ZS50YWdHUFIoKTsKKyAgICAgICAgICAgIEdQUlJlZyB0aGlz VmFsdWVQYXlsb2FkID0gdGhpc1ZhbHVlLnBheWxvYWRHUFIoKTsKKworICAgICAgICAgICAgSlNW YWx1ZU9wZXJhbmQgcHJvcGVydHkodGhpcywgbV9qaXQuZ3JhcGgoKS52YXJBcmdDaGlsZChub2Rl LCAyKSk7CisgICAgICAgICAgICBHUFJSZWcgcHJvcGVydHlUYWcgPSBwcm9wZXJ0eS50YWdHUFIo KTsKKyAgICAgICAgICAgIEdQUlJlZyBwcm9wZXJ0eVBheWxvYWQgPSBwcm9wZXJ0eS5wYXlsb2Fk R1BSKCk7CisKKyAgICAgICAgICAgIG1faml0Lm1vdmUoYmFzZVBheWxvYWQsIEdQUkluZm86OmFy Z3VtZW50R1BSMik7CisgICAgICAgICAgICBtX2ppdC5tb3ZlKGJhc2VUYWcsIEdQUkluZm86OmFy Z3VtZW50R1BSMyk7CisKKyAgICAgICAgICAgIG1faml0LnBva2UodGhpc1ZhbHVlUGF5bG9hZCwg aW5kZXgrKyk7CisgICAgICAgICAgICBtX2ppdC5wb2tlKHRoaXNWYWx1ZVRhZywgaW5kZXgrKyk7 CisKKyAgICAgICAgICAgIG1faml0LnBva2UocHJvcGVydHlQYXlsb2FkLCBpbmRleCsrKTsKKyAg ICAgICAgICAgIG1faml0LnBva2UocHJvcGVydHlUYWcsIGluZGV4KyspOworCisgICAgICAgICAg ICBmbHVzaFJlZ2lzdGVycygpOworICAgICAgICB9CisKKyAgICAgICAgSlNWYWx1ZU9wZXJhbmQg dmFsdWUodGhpcywgbV9qaXQuZ3JhcGgoKS52YXJBcmdDaGlsZChub2RlLCAzKSk7CisgICAgICAg IEdQUlJlZyB2YWx1ZVRhZyA9IHZhbHVlLnRhZ0dQUigpOworICAgICAgICBHUFJSZWcgdmFsdWVQ YXlsb2FkID0gdmFsdWUucGF5bG9hZEdQUigpOworICAgICAgICBtX2ppdC5wb2tlKHZhbHVlUGF5 bG9hZCwgaW5kZXgrKyk7CisgICAgICAgIG1faml0LnBva2UodmFsdWVUYWcsIGluZGV4KyspOwor CisgICAgICAgIGZsdXNoUmVnaXN0ZXJzKCk7CisgICAgICAgIGFwcGVuZENhbGwobV9qaXQuaXNT dHJpY3RNb2RlRm9yKG5vZGUtPm9yaWdpbi5zZW1hbnRpYykgPyBvcGVyYXRpb25QdXRCeVZhbFdp dGhUaGlzU3RyaWN0IDogb3BlcmF0aW9uUHV0QnlWYWxXaXRoVGhpcyk7CisgICAgICAgIG1faml0 LmV4Y2VwdGlvbkNoZWNrKCk7CiAjZWxzZQogICAgICAgICBzdGF0aWNfYXNzZXJ0KEdQUkluZm86 Om51bWJlck9mUmVnaXN0ZXJzID49IDgsICJXZSBhcmUgYXNzdW1pbmcgd2UgaGF2ZSBlbm91Z2gg cmVnaXN0ZXJzIHRvIG1ha2UgdGhpcyBjYWxsIHdpdGhvdXQgaW5jcmVtZW50YWxseSBzZXR0aW5n IHVwIHRoZSBhcmd1bWVudHMuIik7CiAK 279395 2016-05-19 09:54:58 -0700 2016-05-19 10:26:11 -0700 Patch bug-157741-20160519115557.patch text/plain 3595 guijemont U3VidmVyc2lvbiBSZXZpc2lvbjogMjAwOTQyCmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlw dENvcmUvQ2hhbmdlTG9nIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwppbmRleCAw MDc5Y2I4NjNhM2IzMzFkMDQxYjFmMjlmNzYzYTU5NjEwZWRmODMwLi42YzNiNmEzOGIzODFiZjI3 MjdlZWFmOWM2NjkzOTYwNjdhMjI0MjQ1IDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENv cmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKQEAgLTEs MyArMSwxNyBAQAorMjAxNi0wNS0xOSAgR3VpbGxhdW1lIEVtb250ICA8Z3VpamVtb250QGlnYWxp YS5jb20+CisKKyAgICAgICAgSlNDOiBERkc6OlNwZWN1bGF0aXZlSklUOjpjb21waWxlIHNwZWNp YWwgY2FzZSBmb3IgTUlQUyBmb3IgUHV0QnlWYWxXaXRoVGhpcworICAgICAgICBodHRwczovL2J1 Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTU3NzQxCisKKyAgICAgICAgUmV2aWV3ZWQg YnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgVGhlIFB1dEJ5VmFsV2l0aFRoaXMgY2FzZSBu ZWVkcyBhIHNwZWNpYWwgY2FzZSBmb3IgTUlQUyBiZWNhdXNlIHdlCisgICAgICAgIGRvbid0IGhh dmUgZW5vdWdoIHJlZ2lzdGVycy4gVGhlIHNwZWNpYWwgY2FzZSBuZWVkcyB0byBiZSBkaWZmZXJl bnQKKyAgICAgICAgZnJvbSB0aGUgeDg2IG9uZSBiZWNhdXNlIHdlIGhhdmUgYSBkaWZmZXJlbnQg QUJJLgorCisgICAgICAgICogZGZnL0RGR1NwZWN1bGF0aXZlSklUMzJfNjQuY3BwOgorICAgICAg ICAoSlNDOjpERkc6OlNwZWN1bGF0aXZlSklUOjpjb21waWxlKToKKwogMjAxNi0wNS0xNSAgRmls aXAgUGl6bG8gIDxmcGl6bG9AYXBwbGUuY29tPgogCiAgICAgICAgIERGRzo6UGxhbiBzaG91bGRu J3QgcmVhZCBmcm9tIGl0cyBWTSBvbmNlIGl0J3MgYmVlbiBjYW5jZWxsZWQKZGlmZiAtLWdpdCBh L1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9kZmcvREZHU3BlY3VsYXRpdmVKSVQzMl82NC5jcHAgYi9T b3VyY2UvSmF2YVNjcmlwdENvcmUvZGZnL0RGR1NwZWN1bGF0aXZlSklUMzJfNjQuY3BwCmluZGV4 IDMzOGFiYTcyMWRlMGM1OTRhNzc0ZmMyYjViOTM4MzYyYzQ2MjMxOGYuLmEwMDA5NjczYThjODg1 MTkyZjJhZmFmYjIzNmU3ZTNkMmZhOTFlMDIgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0 Q29yZS9kZmcvREZHU3BlY3VsYXRpdmVKSVQzMl82NC5jcHAKKysrIGIvU291cmNlL0phdmFTY3Jp cHRDb3JlL2RmZy9ERkdTcGVjdWxhdGl2ZUpJVDMyXzY0LmNwcApAQCAtMjkyNCw2ICsyOTI0LDQ4 IEBAIHZvaWQgU3BlY3VsYXRpdmVKSVQ6OmNvbXBpbGUoTm9kZSogbm9kZSkKICAgICAgICAgZmx1 c2hSZWdpc3RlcnMoKTsKICAgICAgICAgYXBwZW5kQ2FsbChtX2ppdC5pc1N0cmljdE1vZGVGb3Io bm9kZS0+b3JpZ2luLnNlbWFudGljKSA/IG9wZXJhdGlvblB1dEJ5VmFsV2l0aFRoaXNTdHJpY3Qg OiBvcGVyYXRpb25QdXRCeVZhbFdpdGhUaGlzKTsKICAgICAgICAgbV9qaXQuZXhjZXB0aW9uQ2hl Y2soKTsKKyNlbGlmIENQVShNSVBTKQorICAgICAgICAvLyBXZSBkb24ndCBoYXZlIGVub3VnaCBy ZWdpc3RlcnMgb24gTUlQUyBlaXRoZXIgYnV0IHRoZSBBQkkgaXMgYSBsaXR0bGUgZGlmZmVyZW50 LgorICAgICAgICB1bnNpZ25lZCBpbmRleCA9IDQ7CisgICAgICAgIG1faml0Lm1vdmUoR1BSSW5m bzo6Y2FsbEZyYW1lUmVnaXN0ZXIsIEdQUkluZm86OmFyZ3VtZW50R1BSMCk7CisgICAgICAgIHsK KyAgICAgICAgICAgIEpTVmFsdWVPcGVyYW5kIGJhc2UodGhpcywgbV9qaXQuZ3JhcGgoKS52YXJB cmdDaGlsZChub2RlLCAwKSk7CisgICAgICAgICAgICBHUFJSZWcgYmFzZVRhZyA9IGJhc2UudGFn R1BSKCk7CisgICAgICAgICAgICBHUFJSZWcgYmFzZVBheWxvYWQgPSBiYXNlLnBheWxvYWRHUFIo KTsKKworICAgICAgICAgICAgSlNWYWx1ZU9wZXJhbmQgdGhpc1ZhbHVlKHRoaXMsIG1faml0Lmdy YXBoKCkudmFyQXJnQ2hpbGQobm9kZSwgMSkpOworICAgICAgICAgICAgR1BSUmVnIHRoaXNWYWx1 ZVRhZyA9IHRoaXNWYWx1ZS50YWdHUFIoKTsKKyAgICAgICAgICAgIEdQUlJlZyB0aGlzVmFsdWVQ YXlsb2FkID0gdGhpc1ZhbHVlLnBheWxvYWRHUFIoKTsKKworICAgICAgICAgICAgSlNWYWx1ZU9w ZXJhbmQgcHJvcGVydHkodGhpcywgbV9qaXQuZ3JhcGgoKS52YXJBcmdDaGlsZChub2RlLCAyKSk7 CisgICAgICAgICAgICBHUFJSZWcgcHJvcGVydHlUYWcgPSBwcm9wZXJ0eS50YWdHUFIoKTsKKyAg ICAgICAgICAgIEdQUlJlZyBwcm9wZXJ0eVBheWxvYWQgPSBwcm9wZXJ0eS5wYXlsb2FkR1BSKCk7 CisKKyAgICAgICAgICAgIC8vIGZvciBvcGVyYXRpb25QdXRCeVZhbFdpdGhUaGlzW1N0cmljdF0o KSwgYmFzZSBpcyBhIDY0IGJpdHMKKyAgICAgICAgICAgIC8vIGFyZ3VtZW50LCBzbyBpdCBzaG91 bGQgYmUgZG91YmxlIHdvcmQgYWxpZ25lZCBvbiB0aGUgc3RhY2suCisgICAgICAgICAgICAvLyBU aGlzIHJlcXVpcmVtZW50IHN0aWxsIGFwcGxpZXMgd2hlbiBpdCdzIGluIGFyZ3VtZW50IHJlZ2lz dGVycworICAgICAgICAgICAgLy8gaW5zdGVhZCBvZiBvbiB0aGUgc3RhY2suCisgICAgICAgICAg ICBtX2ppdC5tb3ZlKGJhc2VQYXlsb2FkLCBHUFJJbmZvOjphcmd1bWVudEdQUjIpOworICAgICAg ICAgICAgbV9qaXQubW92ZShiYXNlVGFnLCBHUFJJbmZvOjphcmd1bWVudEdQUjMpOworCisgICAg ICAgICAgICBtX2ppdC5wb2tlKHRoaXNWYWx1ZVBheWxvYWQsIGluZGV4KyspOworICAgICAgICAg ICAgbV9qaXQucG9rZSh0aGlzVmFsdWVUYWcsIGluZGV4KyspOworCisgICAgICAgICAgICBtX2pp dC5wb2tlKHByb3BlcnR5UGF5bG9hZCwgaW5kZXgrKyk7CisgICAgICAgICAgICBtX2ppdC5wb2tl KHByb3BlcnR5VGFnLCBpbmRleCsrKTsKKworICAgICAgICAgICAgZmx1c2hSZWdpc3RlcnMoKTsK KyAgICAgICAgfQorCisgICAgICAgIEpTVmFsdWVPcGVyYW5kIHZhbHVlKHRoaXMsIG1faml0Lmdy YXBoKCkudmFyQXJnQ2hpbGQobm9kZSwgMykpOworICAgICAgICBHUFJSZWcgdmFsdWVUYWcgPSB2 YWx1ZS50YWdHUFIoKTsKKyAgICAgICAgR1BSUmVnIHZhbHVlUGF5bG9hZCA9IHZhbHVlLnBheWxv YWRHUFIoKTsKKyAgICAgICAgbV9qaXQucG9rZSh2YWx1ZVBheWxvYWQsIGluZGV4KyspOworICAg ICAgICBtX2ppdC5wb2tlKHZhbHVlVGFnLCBpbmRleCsrKTsKKworICAgICAgICBmbHVzaFJlZ2lz dGVycygpOworICAgICAgICBhcHBlbmRDYWxsKG1faml0LmlzU3RyaWN0TW9kZUZvcihub2RlLT5v cmlnaW4uc2VtYW50aWMpID8gb3BlcmF0aW9uUHV0QnlWYWxXaXRoVGhpc1N0cmljdCA6IG9wZXJh dGlvblB1dEJ5VmFsV2l0aFRoaXMpOworICAgICAgICBtX2ppdC5leGNlcHRpb25DaGVjaygpOwog I2Vsc2UKICAgICAgICAgc3RhdGljX2Fzc2VydChHUFJJbmZvOjpudW1iZXJPZlJlZ2lzdGVycyA+ PSA4LCAiV2UgYXJlIGFzc3VtaW5nIHdlIGhhdmUgZW5vdWdoIHJlZ2lzdGVycyB0byBtYWtlIHRo aXMgY2FsbCB3aXRob3V0IGluY3JlbWVudGFsbHkgc2V0dGluZyB1cCB0aGUgYXJndW1lbnRzLiIp OwogCg==