GCMole now comes with the long forgotten use-after-free detection
enabled by default. The CL also improves error logging when test
expectations mismatch with the actual output and updates the hash
of GCMole to be used with the newly built version with enabled UAF
detection.
The CL also contains an ignore for isolate.cc due to inability to
fix a warning there and fixes a couple of UAF warnings.
Bug: v8:9680
Change-Id: I7a009ffd5f67b1b5437567691ca4235ea873de70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2257236
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68505}
We can't attach a meaningful stack trace to the AggregateError
Promise.any rejects with, but we can augment the individual errors'
stack traces with Promise.any and the index of the corresponding
Promise in the input.
Bug: v8:9808
Change-Id: I7ba754c9b043594decaac8b3a23be74f05c3dffd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198983
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67778}
Most dead variable warnings in GCMole are false positives, either from
failing to detect that TryEvacuateObject returning false means it didn't
allocate, or a regex error thinking that GarbageCollectionReasonToString
causes garbage collection (because the mangled version is something like
GarbageCollectionReasonToString[...]GarbageCollectionReason, and that
matches /Collect.*Garbage/).
Update the whitelist and fix the "Collect.*Garbage" regex to only look
at the function name.
Bug: v8:9985
Change-Id: I62284e97e4975a6a87616d1d535b2ac7958d17bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1989829
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65622}
This should help reduce the number of false positives detected
by dead variable analysis.
Bug: v8:9680, chromium:1000635
Change-Id: Id2893dd5f26cad230dede96930a5caacc0272b64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924359
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65186}
This CL ensures we care only about our internal pointer types and not
about raw C++ pointers, because normally special care is taken when
storing raw pointers to the managed heap. Furthermore, checking for raw
pointers produces too many false positives in the dead variable
analysis.
Bug: v8:9680, chromium:1000635
Change-Id: Ica9ea1fe09b7456c011910a6886149b6dfdda1f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924357
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65174}
The bot that runs gcmole was failing before
https://crrev.com/c/1789707 because the test file was missing.
It returned with exit status 0 anyway though. After fixing the
original fault, this CL ensures that the gcmole tests also
trigger an error on the bot(s) if they fail.
R=mstarzinger@chromium.org
CC=mslekova@chromium.org
Change-Id: I29ae40301062baadfcd38b26c336c5749924b0d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789702
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63612}
The bots currently fail to run the gcmole self tests, because the file
is not contained in the generated archive.
This CL fixes that.
R=mstarzinger@chromium.orgCC=mslekova@chromium.org
Change-Id: I691c207be1809516a5cc5e250287427674146a7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789707
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63608}
Since we do not support gcc < 5 any more, we can switch to C++14 now.
Gcmole is the only tool preventing this currently.
R=mstarzinger@chromium.org
Bug: v8:9687, v8:9690
Change-Id: Ie7fee25061bdf6f1e7f156bc150b7142c824f5d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787426
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63595}
Since this produces a few false positives, also implemented a whitelist
mechanism to not report them.
Also, add a couple of tests and implemented automated testing against
test-expectations file.
Bug: v8:9321
Change-Id: I2915a29fe1891e8bbc51118bbd95ae072c8de023
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773243
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63456}
This is a reland of 517ab73fd7
Updates since original: now compressed pointers passed to the function
GetObjectProperties are required to be sign-extended. Previously, the
function allowed zero-extended values, but that led to ambiguity on
pointers like 0x88044919: is it compressed or is the heap range actually
centered on 0x100000000?
Original change's description:
> Add postmortem debugging helper library
>
> This change begins to implement the functionality described in
> https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
> for investigating V8 state in crash dumps.
>
> This change adds a new library, v8_debug_helper, for providing platform-
> agnostic assistance with postmortem debugging. This library can be used
> by extensions built for debuggers such as WinDbg or lldb. Its public API
> is described by debug-helper.h; currently the only method it exposes is
> GetObjectProperties, but we'd like to add more functionality over time.
> The API surface is restricted to plain C-style structs and pointers, so
> that it's easy to link from a debugger extension built with a different
> toolchain.
>
> This change also adds a new cctest file to exercise some basic
> interaction with the new library.
>
> The API function GetObjectProperties takes an object pointer (which
> could be compressed, or weak, or a SMI), and returns a string
> description of the object and a list of properties the object contains.
> For now, the list of properties is entirely based on Torque object
> definitions, but we expect to add custom properties in future updates so
> that it can be easier to make sense of complex data structures such as
> dictionaries.
>
> GetObjectProperties does several things that are intended to generate
> somewhat useful results even in cases where memory may be corrupt or
> unavailable:
> - The caller may optionally provide a type string which will be used if
> the memory for the object's Map is inaccessible.
> - All object pointers are compared against the list of known objects
> generated by mkgrokdump. The caller may optionally provide the
> pointers for the first pages of various heap spaces, to avoid spurious
> matches. If those pointers are not provided, then any matches are
> prefixed with "maybe" in the resulting description string, such as
> "maybe UndefinedValue (0x4288000341 <Oddball>)".
>
> Bug: v8:9376
>
> Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62882}
Bug: v8:9376
Change-Id: I866a1cc9d4c34bfe10c7b98462451fe69763cf3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717090
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#63008}
This reverts commit 517ab73fd7.
Reason for revert: Test failures https://bugs.chromium.org/p/v8/issues/detail?id=9538
Original change's description:
> Add postmortem debugging helper library
>
> This change begins to implement the functionality described in
> https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
> for investigating V8 state in crash dumps.
>
> This change adds a new library, v8_debug_helper, for providing platform-
> agnostic assistance with postmortem debugging. This library can be used
> by extensions built for debuggers such as WinDbg or lldb. Its public API
> is described by debug-helper.h; currently the only method it exposes is
> GetObjectProperties, but we'd like to add more functionality over time.
> The API surface is restricted to plain C-style structs and pointers, so
> that it's easy to link from a debugger extension built with a different
> toolchain.
>
> This change also adds a new cctest file to exercise some basic
> interaction with the new library.
>
> The API function GetObjectProperties takes an object pointer (which
> could be compressed, or weak, or a SMI), and returns a string
> description of the object and a list of properties the object contains.
> For now, the list of properties is entirely based on Torque object
> definitions, but we expect to add custom properties in future updates so
> that it can be easier to make sense of complex data structures such as
> dictionaries.
>
> GetObjectProperties does several things that are intended to generate
> somewhat useful results even in cases where memory may be corrupt or
> unavailable:
> - The caller may optionally provide a type string which will be used if
> the memory for the object's Map is inaccessible.
> - All object pointers are compared against the list of known objects
> generated by mkgrokdump. The caller may optionally provide the
> pointers for the first pages of various heap spaces, to avoid spurious
> matches. If those pointers are not provided, then any matches are
> prefixed with "maybe" in the resulting description string, such as
> "maybe UndefinedValue (0x4288000341 <Oddball>)".
>
> Bug: v8:9376
>
> Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62882}
TBR=yangguo@chromium.org,mvstanton@chromium.org,jgruber@chromium.org,tebbi@chromium.org,seth.brenith@microsoft.com
Change-Id: Ia078f2e8d101d2375b5db88021b2d65d28f1b075
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9376
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1716033
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62899}
This change begins to implement the functionality described in
https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
for investigating V8 state in crash dumps.
This change adds a new library, v8_debug_helper, for providing platform-
agnostic assistance with postmortem debugging. This library can be used
by extensions built for debuggers such as WinDbg or lldb. Its public API
is described by debug-helper.h; currently the only method it exposes is
GetObjectProperties, but we'd like to add more functionality over time.
The API surface is restricted to plain C-style structs and pointers, so
that it's easy to link from a debugger extension built with a different
toolchain.
This change also adds a new cctest file to exercise some basic
interaction with the new library.
The API function GetObjectProperties takes an object pointer (which
could be compressed, or weak, or a SMI), and returns a string
description of the object and a list of properties the object contains.
For now, the list of properties is entirely based on Torque object
definitions, but we expect to add custom properties in future updates so
that it can be easier to make sense of complex data structures such as
dictionaries.
GetObjectProperties does several things that are intended to generate
somewhat useful results even in cases where memory may be corrupt or
unavailable:
- The caller may optionally provide a type string which will be used if
the memory for the object's Map is inaccessible.
- All object pointers are compared against the list of known objects
generated by mkgrokdump. The caller may optionally provide the
pointers for the first pages of various heap spaces, to avoid spurious
matches. If those pointers are not provided, then any matches are
prefixed with "maybe" in the resulting description string, such as
"maybe UndefinedValue (0x4288000341 <Oddball>)".
Bug: v8:9376
Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62882}
New Revision: 8b7ea912e516a6daa61487c700687a9426e3a396
Update v8 files / build config accordingly.
- There's now a new library in third_party/inspector_protocol,
bindings/bindings.h, which is configured much like encoding/encoding.h.
It doesn't have much stuff in it yet, but will soon get more code
that would otherwise need to go into jinja templates.
It also comes with a new test, only a smoke test thus far.
Change-Id: I9c00a54a840c214b4bb744a3b272e5ce221954fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1678273
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Johannes Henkel <johannes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62442}
This CL introduces the new suffix '-tq' for Torque generated files,
and replaces the infix 'FromDSL' in type names with a prefix
'TorqueGenerated'.
Change-Id: I1e90460cc0c666da6cf5017e8b3cb7c39c6ac668
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609798
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61490}
For faster calls from Wasm to C-API functions, passing parameter
values directly instead of through JavaScript wrapper objects.
Change-Id: I31e7d1622dedaf3154483306ab159427ac167663
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591601
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61338}
This changes gcmole's bootstrapping script so that it always creates
binaries that link libstdc++ statically (both plugin and Clang) and do
not link against unneeded libraries (only Clang). For deployment of
gcmole on our infrastructure, it is much easier to have fewer external
dependencies.
R=machenbach@chromium.org
BUG=v8:8813
Change-Id: If6f2f3cc3b1f661f7dafbb406eaaf2e639981640
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526002
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60262}
This is a minimalistic script usable for creating packages of gcmole
together with the corresponding Clang. Such packages are used on V8's
infrastructure.
R=machenbach@chromium.org
BUG=v8:8813
Change-Id: Iee3594a3acdc7a4e5b5d5628e5557725d27d9ced
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1523068
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60237}
This updates the existing special casing of assignment operators by
gcmole to match for assignments of {HeapObject} instead of {HeapObject*}
variables. The former now uses the implicit C++ assignment operator call
instead of a primitive assignment binary operation.
Also removes the dead {handle_decl_name} field as a drive-by-fix.
R=mslekova@chromium.org
BUG=v8:8813
Change-Id: I0b48254e7ca1544bc064707a8ca1f204366ddbe4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1517879
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60212}
This updates the existing bootstrap.sh script for gcmole to work against
LLVM and Clang version 8.0 releases. This is a follow-up to a previous
change which adapted the gcmole plugin to compile against those same
versions.
R=mslekova@chromium.org
BUG=v8:8813
Change-Id: Id6052fb9a7ec8a63d205eab2d4e233e2121c733d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511275
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60116}
After introducing the new pointer-containing Object class in V8 (see
https://docs.google.com/document/d/1_w49sakC1XM1OptjTurBDqO86NE16FH8LwbeUAtrbCo/edit),
gcmole stopped finding errorneous usage of raw pointers in functions that could
trigger GC. This CL modifies the heuristics of the tool to classify Object and
MaybeObject instances as raw pointers, thus giving back the missing warnings.
Updated the gcmole implementation to support modern llvm (tested with llvm 8.0)
for which additional support for MaterializeTemporaryExpr, ExprWithCleanups and
UnaryExprOrTypeTraitExpr was needed.
Basic tests are added to make it harder to introduce such errors without
noticing in the future.
This version gives a lot of false positives when ran on the whole project, see
https://docs.google.com/document/d/1K7eJ0f6m9QX6FZIjZnt_GFtUsjEOC_LpiAwZbcAA3f8/editR=jkummerow@chromium.org,mstarzinger@chromium.org
Bug: v8:8813
Change-Id: Ic0190a4bc2642eda8880d9f7b30b5145a76a7d89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1494754
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60099}
There are now less that 400 days until the end of life
of Python 2(aka _legacy_ Python) https://pythonclock.org/ .
The code compatibility check for python2 and python3
used the following tools: futurize, flake8
You can see the reports here: https://travis-ci.com/bmsdave/v8/builds
This CL was uploaded by git cl split.
Bug: v8:8594
Change-Id: I661c52a70527e8ddde841fee6d4dcba282b4a938
Reviewed-on: https://chromium-review.googlesource.com/c/1470123
Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org>
Reviewed-by: Sergiy Belozorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59675}
This is a reland of a462a7854a
Original change's description:
> [turboassembler] Introduce hard-abort mode
>
> For checks and assertions (mostly for debug code, like stack alignment
> or zero extension), we had two modes: Emit a call to the {Abort}
> runtime function (the default), and emit a debug break (used for
> testing, enabled via --trap-on-abort).
> In wasm, where we cannot just call a runtime function because code must
> be isolate independent, we always used the trap-on-abort behaviour.
> This causes problems for our fuzzers, which do not catch SIGTRAP, and
> hence do not detect debug code failures.
>
> This CL introduces a third mode ("hard abort"), which calls a C
> function via {ExternalReference}. The C function still outputs the
> abort reason, but does not print the stack trace. It then aborts via
> "OS::Abort", just like the runtime function.
> This will allow fuzzers to detect the crash and even find a nice error
> message.
>
> Even though this looks like a lot of code churn, it is actually not.
> Most added lines are new tests, and other changes are minimal.
>
> R=mstarzinger@chromium.org
>
> Bug: chromium:863799
> Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
> Reviewed-on: https://chromium-review.googlesource.com/1142163
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54592}
Bug: chromium:863799
Change-Id: I7729a47b4823a982a8e201df36520aa2b6ef5326
Reviewed-on: https://chromium-review.googlesource.com/1146100
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54656}
This reverts commit a462a7854a.
Reason for revert: Breaks a TurboAssembler test:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Arm/7726
Original change's description:
> [turboassembler] Introduce hard-abort mode
>
> For checks and assertions (mostly for debug code, like stack alignment
> or zero extension), we had two modes: Emit a call to the {Abort}
> runtime function (the default), and emit a debug break (used for
> testing, enabled via --trap-on-abort).
> In wasm, where we cannot just call a runtime function because code must
> be isolate independent, we always used the trap-on-abort behaviour.
> This causes problems for our fuzzers, which do not catch SIGTRAP, and
> hence do not detect debug code failures.
>
> This CL introduces a third mode ("hard abort"), which calls a C
> function via {ExternalReference}. The C function still outputs the
> abort reason, but does not print the stack trace. It then aborts via
> "OS::Abort", just like the runtime function.
> This will allow fuzzers to detect the crash and even find a nice error
> message.
>
> Even though this looks like a lot of code churn, it is actually not.
> Most added lines are new tests, and other changes are minimal.
>
> R=mstarzinger@chromium.org
>
> Bug: chromium:863799
> Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
> Reviewed-on: https://chromium-review.googlesource.com/1142163
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54592}
TBR=mstarzinger@chromium.org,clemensh@chromium.org
Change-Id: I60c011cfe262ccebbb9abf32699a9fe17e72a3c8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:863799
Reviewed-on: https://chromium-review.googlesource.com/1145431
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54597}
For checks and assertions (mostly for debug code, like stack alignment
or zero extension), we had two modes: Emit a call to the {Abort}
runtime function (the default), and emit a debug break (used for
testing, enabled via --trap-on-abort).
In wasm, where we cannot just call a runtime function because code must
be isolate independent, we always used the trap-on-abort behaviour.
This causes problems for our fuzzers, which do not catch SIGTRAP, and
hence do not detect debug code failures.
This CL introduces a third mode ("hard abort"), which calls a C
function via {ExternalReference}. The C function still outputs the
abort reason, but does not print the stack trace. It then aborts via
"OS::Abort", just like the runtime function.
This will allow fuzzers to detect the crash and even find a nice error
message.
Even though this looks like a lot of code churn, it is actually not.
Most added lines are new tests, and other changes are minimal.
R=mstarzinger@chromium.org
Bug: chromium:863799
Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
Reviewed-on: https://chromium-review.googlesource.com/1142163
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54592}
DevTools may process another protocol message during API interrupt this
API may lead to createInjectedScript reentrance and will fail.
Let's postpone interrupts.
Bug: chromium:846099
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ia06e034a6287087e4674559d8911d2f4a0b1b459
Reviewed-on: https://chromium-review.googlesource.com/1086372
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53531}
This CL implements TypedArray.p.sort in Torque. The Torque
version works basically the same as the existing JS builtin:
When no comparison function is provided, the C++ fast path builtin
is used. Otherwise a quicksort written in Torque is used, with
a InsertionSort fallback for smaller arrays.
The JS quicksort implementation also containes a more elaborate
third pivot calculation for larger arrays. This is currently not done.
Reported benchmark results are only for those, where a custom
comparison function is provided. The numbers for the C++ path stayed
the same.
Benchmark Current (JS) Torque Speedup
IntTypes 83.9 263.7 3.1
BigIntTypes 32.1 54.6 1.7
FloatTypes 99.3 138.7 1.4
R=danno@chromium.org, jgruber@chromium.org
Bug: v8:7382
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I7abe7ceff525bab24f302d2f06b5961cca770d24
Reviewed-on: https://chromium-review.googlesource.com/1021691
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52776}
An overview of motivation behind Torque and some of its principles
can be found here: https://bit.ly/2qAI5Ep
Note that there is quite a bit of work left to do in order to get
Torque production-ready for any non-trivial amount of code, but
landing the prototype as-is will allow for much faster iteration.
Bugs will be filed for all of the big-ticket items that are not
landing blockers but called out in this patch as important to fix.
Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73
Reviewed-on: https://chromium-review.googlesource.com/845682
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52618}
This is the V8 equivalent to https://crrev.com/2779193002 and must be landed
before //build/secondary/{gtest,gmock} are removed from Chromium. This started
out as https://crrev.com/2847693002
The changes in tools/ were authored by yangguo@chromium.org and
initially shared in http://crrev.com/2849783003.
GoogleTest (gtest) and GoogleMock (gmock) are now hosted into the same
googletest repository. In order to cope with this, the googletest
repository is now sourced at third_party/googletest.
The file/directory layout of Google Test is not yet considered stable.
To minimize disruption while Google Test stabilizes, Chromium code will
be insulated from third_party/googletest.
* testing/gtest/include/gtest/ and testing/gmock/include/gmock have
been populated with headers that forward into the appropriate
locations of third_party/googletest
* testing/BUILD.gn has been populated with the targets
//testing/gtest(:gtest_main) and //testing/gmock(:gmock_main),
which depend on the appropriate //third_party/googletest targets.
All Chromium code should keep depending on the targets and
headers in testing/{gtest,gmock} for now.
BUG=chromium:630705
Change-Id: I12b07ae78c8039aeff6ada7a3335e4e2b5d308ab
Reviewed-on: https://chromium-review.googlesource.com/639953
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52170}
The corresponding gclient variables are set now via:
https://crrev.com/c/913368
Bug: chromium:772804
Change-Id: I9c96bde3e6cc88d84a320c00d3316a91c48749f7
Reviewed-on: https://chromium-review.googlesource.com/913351
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51240}
Now that gclient is much quieter about its output (see crbug.com/772741),
these always-emitted messages make it louder than necessary.
Change-Id: I864676c4ca57d4c060f7f58bc770d8d670695639
Reviewed-on: https://chromium-review.googlesource.com/731118
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48808}
Deletes the now unused Full-codegen compiler. Also removes some macro
assembler instructions which are no longer used.
Note: there is still additional cleanup work to do after this lands
(e.g., remove support for FCG frames support and FCG
debugger support, etc.), but this will be done in followup CLs to keep
this patch managable.
BUG=v8:6409
Change-Id: I8d828fe7a64d29f2c1252d5fda968a630a2e9ef2
Reviewed-on: https://chromium-review.googlesource.com/584773
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47307}
