Bug 104085

Summary: Fix broken WinCE build due to call to add64 in JIT.cpp
Product: WebKit Reporter: Vivek Galatage <vivek.vg>
Component: JavaScriptCoreAssignee: Vivek Galatage <vivek.vg>
Status: CLOSED DUPLICATE    
Severity: Normal CC: andersca, barraclough, fpizlo, gaborb, ggaren, laszlo.gombos, oliver, paroga, zherczeg
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch paroga: review-

Vivek Galatage
Reported 2012-12-04 21:43:33 PST
The method add64() is called inside JIT::privateCompileMainPass(). This call should be under the #if USE(JSVALUE64) guard as its not implemented in WinCE MacroAssemblerARM.cpp Patch follows.
Attachments
Patch (1.73 KB, patch)
2012-12-04 21:46 PST, Vivek Galatage
paroga: review-
Vivek Galatage
Comment 1 2012-12-04 21:46:44 PST
Patrick R. Gansterer
Comment 2 2012-12-06 01:36:27 PST
Comment on attachment 177666 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=177666&action=review > Source/JavaScriptCore/ChangeLog:9 > + This call should be under the #if USE(JSVALUE64) guard as its not implemented in WinCE MacroAssemblerARM.cpp This has _nothing_ to do with WinCE. It's a "problem" of the traditional ARM MacroAssembler. Correct way to fix this is to implement add64() in the MacroAssembler. Usually the szeged guys maintain the traditional ARM (e.g. https://trac.webkit.org/changeset/135610).
Vivek Galatage
Comment 3 2012-12-06 04:00:28 PST
(In reply to comment #2) > (From update of attachment 177666 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=177666&action=review > > > Source/JavaScriptCore/ChangeLog:9 > > + This call should be under the #if USE(JSVALUE64) guard as its not implemented in WinCE MacroAssemblerARM.cpp > > This has _nothing_ to do with WinCE. It's a "problem" of the traditional ARM MacroAssembler. Thank you Patrick, I wasn't aware of this. > Correct way to fix this is to implement add64() in the MacroAssembler. > Usually the szeged guys maintain the traditional ARM (e.g. https://trac.webkit.org/changeset/135610). I added the macro guard as currently all the calls to add64 are under the #if USE(JSVALUE64) except this one. Hence thought this would fix the issue for the time being until a real add64 is implemented. But may be I am wrong with the approach. Thanks for pointing this.
Filip Pizlo
Comment 4 2012-12-06 09:10:58 PST
(In reply to comment #3) > (In reply to comment #2) > > (From update of attachment 177666 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=177666&action=review > > > > > Source/JavaScriptCore/ChangeLog:9 > > > + This call should be under the #if USE(JSVALUE64) guard as its not implemented in WinCE MacroAssemblerARM.cpp > > > > This has _nothing_ to do with WinCE. It's a "problem" of the traditional ARM MacroAssembler. > > Thank you Patrick, I wasn't aware of this. > > > Correct way to fix this is to implement add64() in the MacroAssembler. > > Usually the szeged guys maintain the traditional ARM (e.g. https://trac.webkit.org/changeset/135610). > > I added the macro guard as currently all the calls to add64 are under the #if USE(JSVALUE64) except this one. Hence thought this would fix the issue for the time being until a real add64 is implemented. But may be I am wrong with the approach. Thanks for pointing this. I don't recommend using this kind of thinking in the future. Your change breaks a new JSC feature on all 32-bit platforms just because one particular kind of 32-bit platform has a broken assembler. We don't usually like to fix bugs by introducing new ones.
Vivek Galatage
Comment 5 2012-12-06 14:40:02 PST
(In reply to comment #4) > I don't recommend using this kind of thinking in the future. Your change breaks a new JSC feature on all 32-bit platforms just because one particular kind of 32-bit platform has a broken assembler. We don't usually like to fix bugs by introducing new ones. I apologize for not considering the consequences of my changes. I will make sure to consider all these scenarios before submitting the patches going forward. Thanks for your feedback, really appreciated.
Vivek Galatage
Comment 6 2012-12-11 19:37:03 PST
*** This bug has been marked as a duplicate of bug 104103 ***
Note You need to log in before you can comment on or make changes to this bug.