- 05 Nov, 2019 1 commit
-
-
Eric Leese authored
Currently there are two ways wasm locations are represented in the inspector. This remains unchanged for now. Also, currently there are multiple ways location is represented within V8, with the line number sometimes being a function index and sometimes being 0, and the column number being a byte offset which is sometimes function relative and sometimes module relative. With this change, the line number is never used within V8 (it is always 0), and the column number is always a byte offset from the beginning of the module. This simplifies translation logic and keeps it in one place, and will simplify future changes to wasm location representation in the inspector API. Bug: chromium:1013527 Change-Id: I8813d47c881988f9ab49d7529fb81fe10dbbccff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886915 Commit-Queue: Eric Leese <leese@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64774}
-
- 10 Sep, 2019 1 commit
-
-
Bill Budge authored
- Eliminates non-const reference parameters in src/objects. Bug: v8:9429 Change-Id: Ic39a59d54bda26c622db29f07143055c3cc6c7a0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1794683Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#63650}
-
- 08 Aug, 2019 1 commit
-
-
Jakob Kummerow authored
Change-Id: Ic5145b7ba15ae58d15e2cc4511afc2f8c6d42ea0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741654 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#63132}
-
- 08 Jul, 2019 2 commits
-
-
Clemens Hammacher authored
Due to a rebase, those annotations were missing in https://crrev.com/c/1687891. TBR=mlippautz@chromium.org Bug: v8:9429 Change-Id: I78ff2903dbbe1054499d4768e9ff5fb0c5f4b708 No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690826Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62552}
-
Simon Zünd authored
This CL mitigates the worst performance regressions for stack trace symbolization. The first fix is to hold the StackFrameBase instance in a local variable. The instance is produced by an iterator but newly created everytime FrameArrayIterator::Frame is called. The second fix is to skip symbolization of "MethodName" and "TypeName" for non-method calls. R=ulan@chromium.org Bug: chromium:981541,v8:8742 Change-Id: I58b2e0c87693c3914cf1946ce56341fbd4a797ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1688927 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#62549}
-
- 04 Jul, 2019 1 commit
-
-
Simon Zünd authored
This CL moves the code responsible for serializing a stack trace frame into a string, out of messages.cc and into stack-frame-info.cc. Instead of symbolizing the stack trace frame while serializing, the code is changed to work on top of StackTraceFrame and StackFrameInfo objects. The result is that the serialization code no longer cares when a stack trace frame is symbolized. Symbolization could happen eagerly during capturing, or lazily the first time any of StackFrameInfo fields are accessed. Drive-by: Existing users of StackFrameBase::ToString are adapted to the new SerializeStackTraceFrame API. This includes Isolate::PrintCurrentStackTrace, which is changed to re-use the existing capturing and serializing mechanism. Bug: v8:8742 Change-Id: Ic7fd80668c9d993e99d586ef7fe022850104c34f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631414 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#62522}
-
- 11 Jun, 2019 1 commit
-
-
Simon Zünd authored
This CL is the starting point to convert all FrameArray users to use StackTraceFrame objects instead. Bug: v8:8742 Change-Id: I7bd0081dfd428e9914dedebd5065ac262aacec0b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627332Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#62076}
-
- 06 Jun, 2019 1 commit
-
-
Simon Zünd authored
This CL adds the last fields needed to stringify all stack frames from StackFrameInfo objects instead of accessing the FrameArray directly. Drive-by-change: The factory method that creates StackFrameInfo is refactored to: 1. collect all values for the fields 2. allocate a StackFrameInfo 3. set all the values on the allocated info object. This fixes undefined evaluation order bugs that GCMole failed to spot, as well as make one factory method unnecessary. Note: More precise types on the fields that are currently "Object" will happen in a follow up CL. Bug: v8:8742 Change-Id: Ia8c55fc128434f27aadeba78e8483d90296abe3a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1641242Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#62010}
-
- 23 May, 2019 2 commits
-
-
Simon Zünd authored
This CL adds all fields to StackFrameInfo that are necessary to stringify a stack trace frame. This is another step towards disentangling symbolizing and serializing: - Symbolization collects all the necessary strings, numbers and flags for a stack trace frame. - Serialization turns the symbolized stack trace frame into a string. Drive-by: Moves the lazy initialization of StackFrameInfo into the private getter. Bug: v8:8742 Change-Id: Ic3e0fb6b3d0f0e260014af44380f1f30216b1b26 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627346Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#61784}
-
Clemens Hammacher authored
This CL was generated by an automatic clang AST rewriter using this matcher expression: callExpr( callee( cxxMethodDecl( hasName("operator->"), ofClass(isSameOrDerivedFrom("v8::internal::Object")) ) ), argumentCountIs(1) ) The "->" at the expression location was then rewritten to ".". R=jkummerow@chromium.org TBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org Bug: v8:9183, v8:3770 No-Try: true No-Tree-Checks: true Change-Id: I0a7ecabdeafe51d0cf427f5280af0c7cab96869e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624209Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61764}
-
- 06 May, 2019 1 commit
-
-
Simon Zünd authored
This CL extends the stack frame API to include a flag to distinguish between user and V8 builtin frames. The intention is to extend the API in a later CL, so stack traces include builtin frames. This flag gives embedders more control what to do with builtin frames. R=jgruber@chromium.org, yangguo@chromium.org Bug: v8:8742 Change-Id: Ieda5782dd2073c1e7fd49492bfdfa829a43dc710 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1583723Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#61233}
-
- 13 Feb, 2019 1 commit
-
-
Simon Zünd authored
The StackTraceFrame object will be used in a future CL to replace StackFrameInfo as the object returned by the inspector API, as well as the object used in the stack_frame_cache. The object itself is a simple wrapper around a reference to a FrameArray plus an index, as well as a reference to a StackFrameInfo object that will get lazily initialized. This is the first step towards unifying stack trace representation and collection. R=jgruber@chromium.org Bug: v8:8742 Change-Id: Iefc7d734fd274ffd164ddf6f43c226531aa26d4c Reviewed-on: https://chromium-review.googlesource.com/c/1458017 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#59544}
-