1. 24 Jul, 2020 1 commit
  2. 23 Jul, 2020 1 commit
  3. 26 May, 2020 1 commit
  4. 24 Apr, 2020 1 commit
  5. 09 Mar, 2020 1 commit
    • Dan Elphick's avatar
      [api] Create v8::String::NewFromLiteral that returns Local<String> · b097a8e5
      Dan Elphick authored
      String::NewFromLiteral is a templated function that takes a char[N]
      argument that can be used as an alternative to String::NewFromUtf8 and
      returns a Local<String> rather than a MaybeLocal<String> reducing the
      number of ToLocalChecked() or other checks.
      
      Since the string length is known at compile time, it can statically
      assert that the length is less than String::kMaxLength, which means that
      it can never fail at runtime.
      
      This also converts all found uses of NewFromUtf8 taking a string literal
      or a variable initialized from a string literal to use the new API. In
      some cases the types of stored string literals are changed from const
      char* to const char[] to ensure the size is retained.
      
      This API does introduce a small difference compared to NewFromUtf8. For
      a case like "abc\0def", NewFromUtf8 (using length -1 to infer length)
      would treat this as a 3 character string, whereas the new API will treat
      it as a 7 character string.
      
      As a drive-by fix, this also fixes all redundant uses of
      v8::NewStringType::kNormal when passed to any of the String::New*
      functions.
      
      Change-Id: Id96a44bc068d9c4eaa634aea688e024675a0e5b3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089935
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarMathias Bynens <mathias@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66622}
      b097a8e5
  6. 13 Feb, 2020 1 commit
    • Georgia Kouveli's avatar
      Reland "[arm64] Protect return addresses stored on stack" · 73f88b5f
      Georgia Kouveli authored
      This is a reland of 137bfe47
      
      Original change's description:
      > [arm64] Protect return addresses stored on stack
      > 
      > This change uses the Arm v8.3 pointer authentication instructions in
      > order to protect return addresses stored on the stack.  The generated
      > code signs the return address before storing on the stack and
      > authenticates it after loading it. This also changes the stack frame
      > iterator in order to authenticate stored return addresses and re-sign
      > them when needed, as well as the deoptimizer in order to sign saved
      > return addresses when creating new frames. This offers a level of
      > protection against ROP attacks.
      > 
      > This functionality is enabled with the v8_control_flow_integrity flag
      > that this CL introduces.
      > 
      > The code size effect of this change is small for Octane (up to 2% in
      > some cases but mostly much lower) and negligible for larger benchmarks,
      > however code size measurements are rather noisy. The performance impact
      > on current cores (where the instructions are NOPs) is single digit,
      > around 1-2% for ARES-6 and Octane, and tends to be smaller for big
      > cores than for little cores.
      > 
      > Bug: v8:10026
      > Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
      > Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66239}
      
      Bug: v8:10026
      Change-Id: Id1adfa2e6c713f6977d69aa467986e48fe67b3c2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051958Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Cr-Commit-Position: refs/heads/master@{#66254}
      73f88b5f
  7. 12 Feb, 2020 2 commits
    • Nico Hartmann's avatar
      Revert "[arm64] Protect return addresses stored on stack" · 6a9a67d9
      Nico Hartmann authored
      This reverts commit 137bfe47.
      
      Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/13072
      
      Original change's description:
      > [arm64] Protect return addresses stored on stack
      > 
      > This change uses the Arm v8.3 pointer authentication instructions in
      > order to protect return addresses stored on the stack.  The generated
      > code signs the return address before storing on the stack and
      > authenticates it after loading it. This also changes the stack frame
      > iterator in order to authenticate stored return addresses and re-sign
      > them when needed, as well as the deoptimizer in order to sign saved
      > return addresses when creating new frames. This offers a level of
      > protection against ROP attacks.
      > 
      > This functionality is enabled with the v8_control_flow_integrity flag
      > that this CL introduces.
      > 
      > The code size effect of this change is small for Octane (up to 2% in
      > some cases but mostly much lower) and negligible for larger benchmarks,
      > however code size measurements are rather noisy. The performance impact
      > on current cores (where the instructions are NOPs) is single digit,
      > around 1-2% for ARES-6 and Octane, and tends to be smaller for big
      > cores than for little cores.
      > 
      > Bug: v8:10026
      > Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
      > Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66239}
      
      TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,neis@chromium.org,georgia.kouveli@arm.com
      
      Change-Id: I57d5928949b0d403774550b9bf7dc0b08ce4e703
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10026
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051952Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66242}
      6a9a67d9
    • Georgia Kouveli's avatar
      [arm64] Protect return addresses stored on stack · 137bfe47
      Georgia Kouveli authored
      This change uses the Arm v8.3 pointer authentication instructions in
      order to protect return addresses stored on the stack.  The generated
      code signs the return address before storing on the stack and
      authenticates it after loading it. This also changes the stack frame
      iterator in order to authenticate stored return addresses and re-sign
      them when needed, as well as the deoptimizer in order to sign saved
      return addresses when creating new frames. This offers a level of
      protection against ROP attacks.
      
      This functionality is enabled with the v8_control_flow_integrity flag
      that this CL introduces.
      
      The code size effect of this change is small for Octane (up to 2% in
      some cases but mostly much lower) and negligible for larger benchmarks,
      however code size measurements are rather noisy. The performance impact
      on current cores (where the instructions are NOPs) is single digit,
      around 1-2% for ARES-6 and Octane, and tends to be smaller for big
      cores than for little cores.
      
      Bug: v8:10026
      Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66239}
      137bfe47
  8. 08 Jan, 2020 1 commit
  9. 29 Nov, 2019 1 commit
    • Sigurd Schneider's avatar
      [cctest] Check compilation result in v8_compile · 88f8d801
      Sigurd Schneider authored
      This CL introduces a CHECK in v8_compile that compilation succeedes.
      Previously, a failed compilation would lead to undefined behavior or
      a crash in CompileRun, because it would call Script::Run on a nullptr.
      This CL introduced v8_try_compile that returns a MaybeLocal and supports
      test-cases that want to ensure that a compilation fails.
      
      Bug: chromium:1014415
      Change-Id: I559190da6049f325e8650e4a29c6e387d8ff7af5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1943154
      Auto-Submit: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65266}
      88f8d801
  10. 26 Nov, 2019 1 commit
  11. 28 May, 2019 1 commit
  12. 24 May, 2019 1 commit
  13. 23 May, 2019 1 commit
  14. 22 May, 2019 1 commit
  15. 21 May, 2019 1 commit
  16. 02 May, 2019 2 commits
    • Maciej Goszczycki's avatar
      Reland "[heap] Skip ro-space from heap iterators, add CombinedHeapIterator." · 9c062093
      Maciej Goszczycki authored
      Code relocation info is now always allocated in old-space. Before relocation
      info allocated for placeholders and builtins (which get replaced with
      trampolines in nosnap builds) would become unreachable. Since read-only space
      is not GCed and ReadOnlyHeapIterator doesn't check for reachability,
      ValidateSnapshot would fail finding unreachable objects returned by
      ReadOnlyHeapIterator.
      
      Because trampoline relocation info gets replaced with canonical one, this only
      affects no-embdded-builtins nosnap builds, which don't get much benefit from
      read-only relocation info anyway.
      
      A new check has been added to the read-only deserializer to verify that every
      read-only object is reachable at mksnapshot-time.
      
      The CombinedHeapIterator iteration order was changed to iterate over
      read-only space first, because that's how HeapIterator worked.
      
      This is a reland of 3d1d8eae
      
      Original change's description:
      > [heap] Skip ro-space from heap iterators, add CombinedHeapIterator.
      >
      > Read-only space sharing requires an iterator independent of heap. This
      > also enables future removal of read-only space from heap.
      >
      > Bug: v8:7464
      > Change-Id: Ia07a9369494ea2c547d12c01ffa1d7b8b6bbeabc
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552795
      > Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Dan Elphick <delphick@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#60819}
      
      Bug: v8:7464
      Change-Id: I49ae070955b77956962334a84f762ab29052d5ff
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1566513Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
      Cr-Commit-Position: refs/heads/master@{#61185}
      9c062093
    • Georg Neis's avatar
      [turbofan] Don't allocate JSHeapBroker in the zone · 611a0d19
      Georg Neis authored
      This fixes a memory leak.
      
      Bug: v8:9191, v8:7790
      Change-Id: I0df49cd3a6791600638a67b4b7ad9687562e500b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588426
      Commit-Queue: Georg Neis <neis@chromium.org>
      Auto-Submit: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61166}
      611a0d19
  17. 29 Apr, 2019 1 commit
  18. 12 Apr, 2019 2 commits
  19. 13 Mar, 2019 1 commit
  20. 29 Jan, 2019 3 commits
  21. 16 Jan, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Clean up base::EnumSet · 4064757c
      Clemens Hammacher authored
      After moving to its own header, this CL cleans up some parts of the
      interface. It fixes names and const-declarations of simple accessors,
      and adds a named constructor to make it explicit that an EnumSet should
      be constructed from an integral value.
      Also refactor the use in cctest.h to have less statically declared
      constants. Instead, just create the set of extensions in the individual
      tests.
      
      R=titzer@chromium.org
      
      Bug: v8:8562
      Change-Id: I6178d1aba25afa1d7f54c29ccf81505c165e7cd3
      Reviewed-on: https://chromium-review.googlesource.com/c/1409366
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58862}
      4064757c
  22. 15 Jan, 2019 1 commit
  23. 26 Oct, 2018 1 commit
  24. 25 Oct, 2018 1 commit
    • Jakob Gruber's avatar
      Reland "[ia32] Remove poisoning logic on ia32" · ff6138ad
      Jakob Gruber authored
      This is a reland of a31a6230
      
      Original change's description:
      > [ia32] Remove poisoning logic on ia32
      >
      > Poisoning has been disabled by default on ia32 a while ago. This CL
      > removes its logic from ia32 code generation, which will let us move
      > towards fuller (and unconditional) root register support.
      >
      > Bug: chromium:860429, v8:8254
      > Change-Id: I8f672cf48a6ffc7bf21e7794c1b7463d7f8b9594
      > Reviewed-on: https://chromium-review.googlesource.com/c/1296131
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#56978}
      
      Tbr: mstarzinger@chromium.org,jarin@chromium.org
      Bug: chromium:860429, v8:8254
      Change-Id: Ia65ac57fdc6b9a0f59cc64455d6a000005e9be3b
      Reviewed-on: https://chromium-review.googlesource.com/c/1299080Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56984}
      ff6138ad
  25. 05 Oct, 2018 1 commit
    • Andreas Haas's avatar
      [api][cleanup] Mark Call*OnForegroundThread as V8_DEPRECATE_SOON · 3f8c6e01
      Andreas Haas authored
      These functions got replaced the the taskrunner API. The new way to
      post tasks is as follows:
      
      v8::Platform* platform = ...; // e.g. V8::GetCurrentPlatform();
      v8::Isolate* = ...;
      
      std::shared_ptr<v8::TaskRunner> taskrunner = platform->GetForegroundTaskRunner(isolate);
      std::unique_ptr<v8::Task> task = ...;
      
      taskrunner->PostTask(std::move(task));
      
      R=ulan@chromium.org
      
      Bug: v8:8238
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: I44a70fc530daae581ee31e54fd09e776ba648406
      Reviewed-on: https://chromium-review.googlesource.com/c/1261936Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56400}
      3f8c6e01
  26. 02 Oct, 2018 1 commit
  27. 24 Sep, 2018 1 commit
    • Dan Elphick's avatar
      [deprecation] Deprecate ToBoolean(Local<Context>) · d235f550
      Dan Elphick authored
      ToBoolean and BooleanValue cannot throw exceptions so the Maybe versions
      of the functions don't make sense. As such this deprecates the Maybe
      versions and undeprecates ToBoolean(Isolate*). It also adds
      BooleanValue(Isolate*).
      
      Fix up all of the v8 code to not use the deprecated functions.
      
      Bug: v8:7279, v8:8015
      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: I50e7474d205c75baa153f0dea7f02dcf60232d1d
      Reviewed-on: https://chromium-review.googlesource.com/1238476
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56163}
      d235f550
  28. 21 Sep, 2018 1 commit
  29. 19 Sep, 2018 1 commit
  30. 17 Sep, 2018 2 commits
  31. 14 Sep, 2018 2 commits
  32. 17 Aug, 2018 1 commit
  33. 24 Jul, 2018 1 commit
    • Clemens Hammacher's avatar
      Reland "[turboassembler] Introduce hard-abort mode" · d324382e
      Clemens Hammacher authored
      This is a reland of a462a785
      
      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/1146100Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54656}
      d324382e