1. 06 Jul, 2022 1 commit
  2. 09 Mar, 2022 1 commit
    • Camillo Bruni's avatar
      [runtime] Clean up runtime function Arguments accesses · cead6573
      Camillo Bruni authored
      Replace all CONVERT_XXX_ARG_XXX() macros from runtime-util.h with direct
      calls to Arguments or the fully expanded equivalent.
      
      - This replaces many of the hard CHECKs with DCHECK (as is common
        practice in most V8 code)
      - Instead of relying on verbose comments we now have readable code
      - Rename Arguments.::xxx_at with Arguments::xxx_value_at since these
        methods don't return the Object but rather their double/int value
      
      - Add Oddball::ToBool helper
      - Add and use v8::internal::PropertyAttributesFromInt helper
      - Add stronger DCHECK for PropertyAttributes returned in
        GetPropertyAttributesWithInterceptorInternal
      
      
      
      Bug: v8:11263
      Change-Id: I8d531857e05d19f3198753b05af28d993a391854
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497768Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79418}
      cead6573
  3. 04 Mar, 2020 1 commit
  4. 27 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored
      This replaces all typedefs that define types and not functions by the
      equivalent "using" declaration.
      
      This was done mostly automatically using this command:
      ag -l '\btypedef\b' src test | xargs -L1 \
           perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'
      
      Patchset 2 then adds some manual changes for typedefs for pointer types,
      where the regular expression did not match.
      
      R=mstarzinger@chromium.org
      TBR=yangguo@chromium.org, jarin@chromium.org
      
      Bug: v8:9183
      Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae
  5. 24 May, 2019 1 commit
  6. 23 May, 2019 2 commits
  7. 08 Jan, 2019 1 commit
  8. 26 Dec, 2018 1 commit
  9. 18 Dec, 2018 1 commit
  10. 05 Nov, 2018 1 commit
  11. 23 Aug, 2018 1 commit
  12. 18 Oct, 2017 1 commit
  13. 09 Oct, 2017 1 commit
  14. 19 Dec, 2016 1 commit
  15. 16 Dec, 2016 1 commit
  16. 26 Oct, 2016 3 commits
    • bmeurer's avatar
      [compiler] Properly validate stable map assumption for globals. · 2bd7464e
      bmeurer authored
      For global object property cells, we did not check that the map on the
      previous object is still the same for which we actually optimized. So
      the optimized code was not in sync with the actual state of the property
      cell. When loading from such a global object property cell, Crankshaft
      optimizes away any map checks (based on the stable map assumption),
      leading to arbitrary memory access in the worst case.
      
      TurboFan has the same bug for stores, but is safe on loads because we
      do appropriate map checks there. However mixing TurboFan and Crankshaft
      still exposes the bug.
      
      R=yangguo@chromium.org
      BUG=chromium:659475
      
      Review-Url: https://codereview.chromium.org/2444233004
      Cr-Commit-Position: refs/heads/master@{#40592}
      2bd7464e
    • bmeurer's avatar
      Revert of [compiler] Properly validate stable map assumption for globals.... · d0a047d4
      bmeurer authored
      Revert of [compiler] Properly validate stable map assumption for globals. (patchset #3 id:40001 of https://codereview.chromium.org/2444233004/ )
      
      Reason for revert:
      Breaks tree: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/8789
      
      Original issue's description:
      > [compiler] Properly validate stable map assumption for globals.
      >
      > For global object property cells, we did not check that the map on the
      > previous object is still the same for which we actually optimized. So
      > the optimized code was not in sync with the actual state of the property
      > cell. When loading from such a global object property cell, Crankshaft
      > optimizes away any map checks (based on the stable map assumption),
      > leading to arbitrary memory access in the worst case.
      >
      > TurboFan has the same bug for stores, but is safe on loads because we
      > do appropriate map checks there. However mixing TurboFan and Crankshaft
      > still exposes the bug.
      >
      > R=yangguo@chromium.org
      > BUG=chromium:659475
      
      TBR=yangguo@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:659475
      
      Review-Url: https://codereview.chromium.org/2454513003
      Cr-Commit-Position: refs/heads/master@{#40582}
      d0a047d4
    • bmeurer's avatar
      [compiler] Properly validate stable map assumption for globals. · 3aa57eb9
      bmeurer authored
      For global object property cells, we did not check that the map on the
      previous object is still the same for which we actually optimized. So
      the optimized code was not in sync with the actual state of the property
      cell. When loading from such a global object property cell, Crankshaft
      optimizes away any map checks (based on the stable map assumption),
      leading to arbitrary memory access in the worst case.
      
      TurboFan has the same bug for stores, but is safe on loads because we
      do appropriate map checks there. However mixing TurboFan and Crankshaft
      still exposes the bug.
      
      R=yangguo@chromium.org
      BUG=chromium:659475
      
      Review-Url: https://codereview.chromium.org/2444233004
      Cr-Commit-Position: refs/heads/master@{#40578}
      3aa57eb9
  17. 08 Aug, 2016 1 commit
  18. 14 Jul, 2016 1 commit
  19. 13 Jul, 2016 1 commit
    • mstarzinger's avatar
      [runtime] Fully remove RUNTIME_ASSERT for good. · 04062e92
      mstarzinger authored
      This fully deprecates all uses of the RUNTIME_ASSERT macro and removes
      the macro and underlying logging function in question. All uses have
      been replaces with CHECK macros which crash safely even in production.
      
      It makes sure we discover abuse of runtime functions in the wild early
      and also abort the process safely. Breaking assumptions in any runtime
      function can no longer accidentally be caught by JavaScript.
      
      R=yangguo@chromium.org
      BUG=v8:5066
      
      Review-Url: https://codereview.chromium.org/2132493002
      Cr-Commit-Position: refs/heads/master@{#37704}
      04062e92
  20. 14 Jun, 2016 1 commit
  21. 13 Jun, 2016 2 commits
  22. 06 Jun, 2016 1 commit
  23. 01 Mar, 2016 1 commit
    • littledan's avatar
      Make RUNTIME_ASSERT have more useful output in debug mode · 78d84530
      littledan authored
      Runtime asserts are were previously a bit annoying to debug, due to
      the lack of a useful error message, even in debug mode. This patch
      prints out some more information in debug mode for runtime assert
      failures while preserving their exception-throwing semantics. While
      we're at it, it requires a semicolon after RUNTIME_ASSERT macro
      invocations.
      
      ```
      $ rlwrap out/Debug/d8 --allow-natives-syntax
      V8 version 5.1.0 (candidate)
      d8> %ArrayBufferNeuter(1)
      
      #
      # Runtime error in ../../src/runtime/runtime-typedarray.cc, line 52
      #
      # args[0]->IsJSArrayBuffer()
      
      ==== C stack trace ===============================
      
       1: 0xf70ab5
       2: 0xadeebf
       3: 0xadedd4
       4: 0x2ef17630693b
      (d8):1: illegal access
      %ArrayBufferNeuter(1)
      ^
      
      d8>
      ```
      
      Also give the other 'illegal access' case (a special SyntaxError type) a more
      descriptive error message for its sole usage.
      
      R=adamk
      
      Review URL: https://codereview.chromium.org/1748183002
      
      Cr-Commit-Position: refs/heads/master@{#34401}
      78d84530
  24. 15 Jan, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Add ForInPrepare runtime function which returns a ObjectTriple. · 84f8a506
      rmcilroy authored
      Adds a ForInPrepare Runtime function which returns a triple of
      cache_type, cache_array and cache_length.
      
      This requires adding support to CEntryStub to call runtime functions
      which return a ObjectTriple - a struct containing three Object*
      pointers. Also did some cleanup of the x64 CEntryStub to avoid
      replicated code.
      
      Replaces the interpreter's use of the ad-hock InterpreterForInPrepare
      Runtime function with ForInPrepare in preparation for fixing deopt in
      BytecodeGraphBuilder for ForIn (which will be done in a followup CL).
      
      MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1576093004
      
      Cr-Commit-Position: refs/heads/master@{#33334}
      84f8a506
  25. 30 Sep, 2015 1 commit
  26. 03 Jun, 2015 1 commit
  27. 01 Jun, 2015 1 commit
    • bmeurer's avatar
      [turbofan] First step towards sanitizing for-in and making it optimizable. · e2e47f30
      bmeurer authored
      In a nutshell: The FILTER_KEY builtin is gone, and was replaced by a
      simple runtime call to ForInFilter, which does everything and is even
      cheaper (because FILTER_KEY used to call into the runtime anyway).
      And ForInFilter returns either the name or undefined, which makes it
      possible to remove the control flow construction from the AstGraphBuilder,
      and thereby make both the initialization and the per-loop code of for-in
      optimizable later (in typed lowering).
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1160983004
      
      Cr-Commit-Position: refs/heads/master@{#28711}
      e2e47f30
  28. 04 Feb, 2015 2 commits
  29. 20 Oct, 2014 1 commit
  30. 30 Sep, 2014 1 commit
  31. 25 Sep, 2014 1 commit