Skip to content

V
V8
Switch branch/tag
  1. 03 Nov, 2016 1 commit
  3. 19 Oct, 2016 1 commit
  5. 18 Oct, 2016 1 commit
  7. 13 Oct, 2016 2 commits
    • mythria's avatar
      [Interpreter] Print information about interpreted functions when tracing ics. · 6fa76d46
      mythria authored 
      With --trace-ic flag, the function names and the source positions are
not shown for interpreted functions. Interpreted functions have an extra
frame built by bytecode handlers which has to be skipped to get the
interpreted function's frame. Also the code offsets are computed differently
for interpreted functions.

BUG=v8:4280

Review-Url: https://codereview.chromium.org/2405173007
Cr-Commit-Position: refs/heads/master@{#40274}
      6fa76d46
    • clemensh's avatar
      [wasm] Stack inspection support for asm.js frames · e902b69d
      clemensh authored 
      This CL fixes the debugger interface to provide correct (high-level)
information for asm.js frames.
It moves the computation of the source position from the FrameInspector
to the individual StackFrame implementations, such that we can easily
specualize it for certain frame types, and can potentially reuse this
in other locations.

Also, we are finalizing the setup of the wasm module earlier, before
executing the start function. This is required for correct stack traces
during the execution of the start function.

R=titzer@chromium.org, yangguo@chromium.org
BUG=v8:4203

Review-Url: https://codereview.chromium.org/2413693003
Cr-Commit-Position: refs/heads/master@{#40268}
      e902b69d
  9. 30 Sep, 2016 1 commit
  11. 29 Sep, 2016 2 commits
  13. 25 Aug, 2016 1 commit
  15. 02 Aug, 2016 1 commit
  17. 27 Jul, 2016 1 commit
    • mstarzinger's avatar
      [interpreter] Implement OSR graph construction from bytecode. · 1314406c
      mstarzinger authored 
      This implements graph construction for entry via on-stack replacement
within the {BytecodeGraphBuilder}. Entry points are at loop headers
similar to previous OSR implementations. All interpreter registers are
addressable via {OsrValue} nodes in the graph. Currently we rely on
{OsrPoll} bytecodes to be placed right after loop headers (i.e. at the
targets of back edges).

R=jarin@chromium.org
BUG=v8:4764

Review-Url: https://codereview.chromium.org/2171083004
Cr-Commit-Position: refs/heads/master@{#38083}
      1314406c
  19. 11 Jul, 2016 1 commit
  21. 04 Jul, 2016 1 commit
    • jgruber's avatar
      [builtins] Add receiver to builtin exit frames · f59a2335
      jgruber authored 
      Stack trace generation requires access to the receiver; and while the
receiver is already on the stack, we cannot determine its position
during stack trace generation (it's stored in argv[0], and argc is only
stored in a callee-saved register).

This patch grants access to the receiver by pushing argc onto builtin
exit frames as an extra argument. Compared to simply pushing the
receiver, this requires an additional dereference during stack trace
generation, but one fewer during builtin calls.

BUG=v8:4815

Review-Url: https://codereview.chromium.org/2106883003
Cr-Commit-Position: refs/heads/master@{#37500}
      f59a2335
  23. 30 Jun, 2016 1 commit
    • jgruber's avatar
      [builtins] New frame type for exits to C++ builtins · 5febc27b
      jgruber authored 
      Prior to this commit, calls to C++ builtins created standard exit
frames, which are skipped when constructing JS stack traces. In order to
show these calls on traces, we introduce a new builtin exit frame type.

Builtin exit frames contain target and new.target on the stack and are
not skipped during stack trace construction.

BUG=v8:4815
R=bmeurer@chromium.org, yangguo@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel;tryserver.v8:v8_linux_nosnap_dbg

Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a
Review-Url: https://codereview.chromium.org/2090723005
Cr-Original-Commit-Position: refs/heads/master@{#37384}
Cr-Commit-Position: refs/heads/master@{#37416}
      5febc27b
  25. 29 Jun, 2016 3 commits
  27. 17 Jun, 2016 1 commit
    • jgruber's avatar
      [builtins] Introduce a proper BUILTIN frame type. · f47b9e98
      jgruber authored 
      This adds a new BUILTIN frame type, which supports variable number of
arguments for builtins implemented in hand-written native code (we will
extend this mechanism to TurboFan builtins at some point). Convert the
Math.max and Math.min builtins to construct a BUILTIN frame if required.

This does not yet work for C++ builtins, but that'll be the next step.

R=bmeurer@chromium.org, jarin@chromium.org
BUG=v8:4815
LOG=n

Review-Url: https://codereview.chromium.org/2069423002
Cr-Commit-Position: refs/heads/master@{#37051}
      f47b9e98
  29. 27 May, 2016 1 commit
  31. 19 May, 2016 1 commit
  33. 06 May, 2016 1 commit
    • clemensh's avatar
      [wasm] Make wasm info available on the stack trace · a4cd1eef
      clemensh authored 
      This changes different locations to extract the reference to the wasm
object and the function index from the stack trace, and make it
available through all the APIs which process stack traces.
The javascript CallSite object now has the new methods isWasm(),
getWasmObject() and getWasmFunctionIndex(); the byte offset is
available via getPosition().

Function names of wasm frames should be fully functional with this
commit, position information works reliably for calls, but not for
traps like unreachable or out-of-bounds accesses.

R=titzer@chromium.org, yangguo@chromium.org

Review-Url: https://codereview.chromium.org/1909353002
Cr-Commit-Position: refs/heads/master@{#36067}
      a4cd1eef
  35. 22 Apr, 2016 1 commit
    • jarin's avatar
      Introduce approximate mode for StandardFrame::Summarize. · fcbe95c8
      jarin authored 
      The approximate mode enables taking an approximate stack trace from GC,
where the top frames might be missing if inlined. Note that in that case,
the frame summary will refer to optimized code, so it will not be possible
to take source position. (The user of the summary will have to handle the
case frame_summary.abstract_code()->kind() == AbstractCode::OPTIMIZED_CODE
specially.)

Review URL: https://codereview.chromium.org/1907443002

Cr-Commit-Position: refs/heads/master@{#35728}
      fcbe95c8
  37. 19 Apr, 2016 2 commits
  39. 18 Apr, 2016 2 commits
  41. 14 Apr, 2016 2 commits
  43. 06 Apr, 2016 2 commits
    • clemensh's avatar
      Prepare StackFrame hierarchy & iterators for WASM · 08454486
      clemensh authored 
      This particularly changes the StackTraceFrameIterator such that is not
only returs JavaScriptFrames, but also WasmFrames. Because of that,
some methods (Summarize, function, receiver) were pulled up to the
StandardFrame, with specializations in JavaScriptFrame and WasmFrame.

R=jfb@chromium.org, titzer@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1861283002

Cr-Commit-Position: refs/heads/master@{#35293}
      08454486
    • bmeurer's avatar
      [generators] Decouple generator resume from fullcodegen. · 974721c6
      bmeurer authored 
      Introduce a ResumeGeneratorTrampoline, which does the actual stack state
reconstruction (currently always restores a fullcodegen frame), and
introduce appropriate TurboFan builtins for %GeneratorPrototype%.next,
%GeneratorPrototype%.return and %GeneratorPrototype%.throw based on
this native builtin.

Also unify the flooding in case of step-in to always work based on
JSFunction and remove the special casing for JSGeneratorObject.

R=mstarzinger@chromium.org, neis@chromium.org
TBR=rossberg@chromium.org
BUG=chromium:513471
LOG=n

Review URL: https://codereview.chromium.org/1865833002

Cr-Commit-Position: refs/heads/master@{#35283}
      974721c6
  45. 05 Apr, 2016 2 commits
  47. 29 Mar, 2016 1 commit
  49. 08 Mar, 2016 1 commit
    • danno's avatar
      [runtime] Unify and simplify how frames are marked · 9dcd0857
      danno authored 
      Before this CL, various code stubs used different techniques
for marking their frames to enable stack-crawling and other
access to data in the frame. All of them were based on a abuse
of the "standard" frame representation, e.g. storing the a
context pointer immediately below the frame's fp, and a
function pointer after that. Although functional, this approach
tends to make stubs and builtins do an awkward, unnecessary
dance to appear like standard frames, even if they have
nothing to do with JavaScript execution.

This CL attempts to improve this by:

* Ensuring that there are only two fundamentally different
  types of frames, a "standard" frame and a "typed" frame.
  Standard frames, as before, contain both a context and
  function pointer. Typed frames contain only a minimum
  of a smi marker in the position immediately below the fp
  where the context is in standard frames.
* Only interpreted, full codegen, and optimized Crankshaft and
  TurboFan JavaScript frames use the "standard" format. All
  other frames use the type frame format with an explicit
  marker.
* Typed frames can contain one or more values below the
  type marker. There is new magic macro machinery in
  frames.h that simplifies defining the offsets of these fields
  in typed frames.
* A new flag in the CallDescriptor enables specifying whether
  a frame is a standard frame or a typed frame. Secondary
  register location spilling is now only enabled for standard
  frames.
* A zillion places in the code have been updated to deal with
  the fact that most code stubs and internal frames use the
  typed frame format. This includes changes in the
  deoptimizer, debugger, and liveedit.
* StandardFrameConstants::kMarkerOffset is deprecated,
  (CommonFrameConstants::kContextOrFrameTypeOffset
  and StandardFrameConstants::kFrameOffset are now used
  in its stead).

LOG=N

Review URL: https://codereview.chromium.org/1696043002

Cr-Commit-Position: refs/heads/master@{#34571}
      9dcd0857
  51. 04 Mar, 2016 1 commit
  53. 23 Feb, 2016 3 commits
  55. 18 Feb, 2016 1 commit
  57. 17 Feb, 2016 1 commit