[Webkit-unassigned] [Bug 18274] New: ResolveNode::emitCode() doesn't make a new temporary when dst is 0, leading to incorrect codegen

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Apr 1 19:35:52 PDT 2008


http://bugs.webkit.org/show_bug.cgi?id=18274

           Summary: ResolveNode::emitCode() doesn't make a new temporary
                    when dst is 0, leading to incorrect codegen
           Product: WebKit
           Version: 526+ (Nightly build)
          Platform: Macintosh
        OS/Version: Mac OS X 10.5
            Status: NEW
          Keywords: SquirrelFish
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: cwzwarich at uwaterloo.ca


This JavaScript

var o = { a: function () { return 1; } };
o.a();
o;

generates the following code:

[   0] load             lr1, undefined(@k0)             
[   3] new_object       lr1
[   5] new_func_exp             tr0, f0
[   8] put_prop_id      lr1, a(@id0), tr0
[  12] get_prop_id      tr0, lr1, a(@id0)
[  16] call             lr1, tr0, lr1, 8, 1
[  22] end              lr1

The end call ends up overwriting the local variable o with 1, which is clearly
incorrect. Obviously, we don't always want ResolveNode::emitCode() to return a
new temporary register if dst is unspecified. However, there are two situations
where this causes a bug:

1) The returned register is reused. This occurs in FunctionCallDotNode and
FunctionCallBracketNode. I have a patch that fixes this particular problem, and
I will post it for review. DoWhileNode and ForNode increment the reference
count of the returned register, but only to return it, not to reuse it.

2) The returned register is ignored, requiring dst to be the actual target.
This occurs in codegen for IfNode, IfElseNode, WhileNode, and ForInNode. It
doesn't cause any realistic problems in any of them, because they are
statements. The first three return 0 as it is, and ForInNode returns dst, which
still isn't a problem if it doesn't contain the correct value, because nothing
will use it once we have completions working.

Should we just accept this behaviour of emitNode and remember to code around
it?


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


More information about the webkit-unassigned mailing list