123799 2013-11-05 04:49:41 -0800 REGRESSION(r158315): register mixup in JIT::compileOpCall 2013-11-05 09:09:26 -0800 1 1 1 Unclassified WebKit JavaScriptCore 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 1 jbriance webkit-unassigned commit-queue fpizlo gergely kilvadyb mark.lam msaboff oldest_to_newest 947117 0 jbriance 2013-11-05 04:49:41 -0800 Changeset 158315 (http://trac.webkit.org/changeset/158315) is crashing architectures where JSInterfaceJIT::regT3 is different from GPRInfo::regT3, like in mips. 947120 1 216026 jbriance 2013-11-05 04:54:33 -0800 Created attachment 216026 Use regT3 instead of GPRInfo::regT3 in JIT::compileOpCall 947153 2 216026 mark.lam 2013-11-05 07:16:41 -0800 Comment on attachment 216026 Use regT3 instead of GPRInfo::regT3 in JIT::compileOpCall r=me 947167 3 216026 commit-queue 2013-11-05 07:32:07 -0800 Comment on attachment 216026 Use regT3 instead of GPRInfo::regT3 in JIT::compileOpCall Clearing flags on attachment: 216026 Committed r158672: <http://trac.webkit.org/changeset/158672> 947168 4 commit-queue 2013-11-05 07:32:10 -0800 All reviewed patches have been landed. Closing bug. 947180 5 fpizlo 2013-11-05 08:23:11 -0800 Why does MIPS use a different definition of regT3? Why not fix that problem? 947182 6 mark.lam 2013-11-05 08:25:56 -0800 (In reply to comment #5) > Why does MIPS use a different definition of regT3? > > Why not fix that problem? I agree that we should make the register assignments consistent. However, MIPS isn't the only CPU port that has this issue. For now, I r+ the change to resolve the immediate action. Longer term, we should look into unifying the register assignments in GPRInfo.h and JSInterfaceJIT.h. 947183 7 fpizlo 2013-11-05 08:27:25 -0800 (In reply to comment #6) > (In reply to comment #5) > > Why does MIPS use a different definition of regT3? > > > > Why not fix that problem? > > I agree that we should make the register assignments consistent. However, MIPS isn't the only CPU port that has this issue. For now, I r+ the change to resolve the immediate action. Longer term, we should look into unifying the register assignments in GPRInfo.h and JSInterfaceJIT.h. Which others have this problem? 947184 8 jbriance 2013-11-05 08:27:47 -0800 (In reply to comment #5) > Why does MIPS use a different definition of regT3? Good question, I don't know why MIPS backend has been designed like this. > Why not fix that problem? I can try if you think it's worth to do so. 947185 9 mark.lam 2013-11-05 08:36:44 -0800 (In reply to comment #7) > Which others have this problem? Apart from MIPS, at a glance ... For this exact problem: CPU(ARM64): regT3: x23 vs x3 For other discrepancies between GPRInfo.h and JSInterfaceJIT.h: CPU(X86_86): regT4: r10 vs edi CPU(ARM): regT4: r7 vs r8 CPU(ARM64): regT4: x24 vs x4 947200 10 fpizlo 2013-11-05 08:59:15 -0800 (In reply to comment #9) > (In reply to comment #7) > > Which others have this problem? > > Apart from MIPS, at a glance ... > > For this exact problem: > > CPU(ARM64): regT3: x23 vs x3 > > For other discrepancies between GPRInfo.h and JSInterfaceJIT.h: > > CPU(X86_86): regT4: r10 vs edi > CPU(ARM): regT4: r7 vs r8 > CPU(ARM64): regT4: x24 vs x4 We should fix that by getting rid of the regT* definitions in JSInterfaceJIT.h If some backend can't handle it then that's a separate problem. 947208 11 mark.lam 2013-11-05 09:05:15 -0800 (In reply to comment #10) > We should fix that by getting rid of the regT* definitions in JSInterfaceJIT.h I'll work on it in https://bugs.webkit.org/show_bug.cgi?id=123806. 947216 12 jbriance 2013-11-05 09:09:26 -0800 As discussed with Mark on IRC, I'll submit a patch soon to fix MIPS backend in https://bugs.webkit.org/show_bug.cgi?id=123807 216026 2013-11-05 04:54:33 -0800 2013-11-05 07:32:07 -0800 Use regT3 instead of GPRInfo::regT3 in JIT::compileOpCall bug-123799.patch text/plain 1678 jbriance SW5kZXg6IFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291 cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwkocmV2aXNpb24gMTU4NjYxKQorKysgU291cmNl L0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE2IEBA CisyMDEzLTExLTA1ICBKdWxpZW4gQnJpYW5jZWF1ICA8amJyaWFuY2VAY2lzY28uY29tPgorCisg ICAgICAgIFJFR1JFU1NJT04ocjE1ODMxNSk6IEZpeCByZWdpc3RlciBtaXh1cCBpbiBKSVQ6OmNv bXBpbGVPcENhbGwuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNn aT9pZD0xMjM3OTkKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAg ICAgICBDaGFuZ2VzZXQgcjE1ODMxNSBpcyBjcmFzaGluZyBhcmNoaXRlY3R1cmVzIHdoZXJlIEpT SW50ZXJmYWNlSklUOjpyZWdUMyBpcworICAgICAgICBkaWZmZXJlbnQgZnJvbSBHUFJJbmZvOjpy ZWdUMy4gVGhpcyBpcyB0aGUgY2FzZSBmb3IgTUlQUyBhcmNoaXRlY3R1cmUuCisKKyAgICAgICAg KiBqaXQvSklUQ2FsbDMyXzY0LmNwcDoKKyAgICAgICAgKEpTQzo6SklUOjpjb21waWxlT3BDYWxs KToKKwogMjAxMy0xMS0wNCAgRmlsaXAgUGl6bG8gIDxmcGl6bG9AYXBwbGUuY29tPgogCiAgICAg ICAgIGludGVybmFsLWpzLXRlc3RzLnlhbWwvT2N0YW5lL3N0cmVzcy10ZXN0cy9wZGZqcy5qcy5k ZWZhdWx0OiBBU1NFUlRJT04gRkFJTEVEOiBtX3N0YXRlLmZvck5vZGUoY2hpbGQpLm1fZnV0dXJl UG9zc2libGVTdHJ1Y3R1cmUuaXNTdWJzZXRPZihTdHJ1Y3R1cmVTZXQoc3RydWN0dXJlKSkgYXQg REZHQ29uc3RhbnRGb2xkaW5nUGhhc2UuY3BwOjI0OQpJbmRleDogU291cmNlL0phdmFTY3JpcHRD b3JlL2ppdC9KSVRDYWxsMzJfNjQuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9KYXZhU2NyaXB0 Q29yZS9qaXQvSklUQ2FsbDMyXzY0LmNwcAkocmV2aXNpb24gMTU4NjU0KQorKysgU291cmNlL0ph dmFTY3JpcHRDb3JlL2ppdC9KSVRDYWxsMzJfNjQuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC0yNjIs NyArMjYyLDcgQEAgdm9pZCBKSVQ6OmNvbXBpbGVPcENhbGwoT3Bjb2RlSUQgb3Bjb2RlSQogICAg IHN0b3JlMzIoVHJ1c3RlZEltbTMyKGxvY2F0aW9uQml0cyksIHRhZ0ZvcihKU1N0YWNrOjpBcmd1 bWVudENvdW50LCBjYWxsRnJhbWVSZWdpc3RlcikpOwogICAgIGVtaXRMb2FkKGNhbGxlZSwgcmVn VDEsIHJlZ1QwKTsgLy8gcmVnVDEsIHJlZ1QwIGhvbGRzIGNhbGxlZS4KIAotICAgIHN0b3JlUHRy KGNhbGxGcmFtZVJlZ2lzdGVyLCBBZGRyZXNzKEdQUkluZm86OnJlZ1QzLCBDYWxsRnJhbWU6OmNh bGxlckZyYW1lT2Zmc2V0KCkpKTsKKyAgICBzdG9yZVB0cihjYWxsRnJhbWVSZWdpc3RlciwgQWRk cmVzcyhyZWdUMywgQ2FsbEZyYW1lOjpjYWxsZXJGcmFtZU9mZnNldCgpKSk7CiAgICAgZW1pdFN0 b3JlKEpTU3RhY2s6OkNhbGxlZSwgcmVnVDEsIHJlZ1QwLCByZWdUMyk7CiAgICAgbW92ZShyZWdU MywgY2FsbEZyYW1lUmVnaXN0ZXIpOwogCg==