Fixed the step in handling for function.apply.
authorsgjesse@chromium.org <sgjesse@chromium.org@ce2b1a6d-e550-0410-aec6-3dcde31c8c00>
Tue, 7 Apr 2009 09:54:53 +0000 (09:54 +0000)
committersgjesse@chromium.org <sgjesse@chromium.org@ce2b1a6d-e550-0410-aec6-3dcde31c8c00>
Tue, 7 Apr 2009 09:54:53 +0000 (09:54 +0000)
commita74fcf458ccf3a803901151ad65c84e256a1fa72
tree1f9fca0a31fdb2591c3c3605a60e4da16be279db
parent2336579a11eba707cf328712a55bad1e43430242
Fixed the step in handling for function.apply.

The generic step-in mechanism floods the function called with break points to ensure a break is hit when entering the function. This generic mechanism was also used for function.apply. The code for function.apply contains a keyed load IC which was patched when stepping into function.apply. However function.apply enteres an internal frame not a JavaScript frame. This caused the logic for returning from the break in function.apply to fail as it forced a jump to the IC on the top JavaScript frame. The top JavaScript frame was the frame for the function calling function.apply not the frame for the apply function. Now returning from the break point in the keyed load IC in the apply code caused a jump to the code for the call IC for the function calling function.apply in the first place. Not a pretty sight.

Step-in now handles function.apply as a separate case where the actual JavaScript function called through apply is flodded with breakpoints instead of the function.apply function.

BUG=269
BUG=8210@chromium.org
Review URL: http://codereview.chromium.org/63055

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1683 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
src/debug.cc
test/cctest/test-debug.cc
test/mjsunit/mjsunit.status
test/mjsunit/regress/regress-269.js [moved from test/mjsunit/bugs/bug-269.js with 100% similarity]