1. 17 Mar, 2020 1 commit
  2. 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
  3. 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
  4. 25 Oct, 2019 1 commit
  5. 20 Aug, 2019 1 commit
    • Jakob Gruber's avatar
      [deoptimizer] Extract frame layout calculation into helper classes · 81642fa6
      Jakob Gruber authored
      The deoptimizer calculates frame layout based on the translation's
      `height` field, together with additional data (e.g.: are we looking at
      the topmost frame? what kind of deopt are we in?). The result is the
      final deoptimized frame size in bytes, together with a bunch of
      intermediate results such as the variable frame size (= without the
      fixed-size portion).
      
      In order to consider the deoptimized frame size in optimized stack
      checks, we will need to calculate the frame layout during compilation
      in addition to what we currently do during deoptimization. This CL
      moves in that direction by extracting relevant parts of frame layout
      calculation into classes that can be reused by both compiler and
      deoptimizer.
      
      These helpers will support both precise and conservative modes; the
      deoptimizer will use the precise mode (since it has full information),
      while the instruction selector will use the conservative mode.
      
      Bug: v8:9534
      Change-Id: I93d6c39f10d251733f4625d3cc161b2010652d02
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760825
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63279}
      81642fa6
  6. 02 Aug, 2019 1 commit
  7. 31 Jul, 2019 1 commit
  8. 30 Jul, 2019 1 commit
    • Georgia Kouveli's avatar
      [arm64] Reduce code size of deoptimization exits · 207d6b35
      Georgia Kouveli authored
      Do not pass the deoptimization index in a register, instead infer it
      from the address we made the deoptimization call from. This makes the
      deoptimization exit sequence one instruction long instead of two.
      
      This requires emitting all deoptimization exits at the end of the
      function in a contiguous block, making sure no constant or veneer
      pools are emitted in between. This means that soft deoptimizations
      require an additional branch to the end of the function, which
      counteracts the removal of the move instruction, however soft
      deoptimizations are rare compared to eager and lazy ones.
      
      This reduces the code size of optimised functions for benchmarks like
      Octane and ARES-6 by about 4%.
      
      Change-Id: I771f9104a07de7931a4bb9c5836e25fb55b1a2a4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714876
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62991}
      207d6b35
  9. 11 Jul, 2019 1 commit
  10. 28 May, 2019 1 commit
  11. 21 May, 2019 1 commit
  12. 20 May, 2019 3 commits
  13. 09 Jan, 2019 1 commit
    • Predrag Rudic's avatar
      MIPS[64]: Port '[Deopt] Remove jump table in prologue of deopt entries.' · b0dc60f6
      Predrag Rudic authored
      Port commit 4ab96a9a
      
      Original message:
      > Remove the use of a jump table in the prologue of the deopt entries
      > and instead pass the bailout id explicitly in a register when calling
      > the deopt entry routine from optimized code. This unifies the logic
      > with the way the Arm64 code works. It saves the following amount of
      > memory in code stubs:
      >
      >  - arm:  384KB
      >  - ia32: 480KB
      >  - x64:  240KB
      >
      > This could be offset by a slight increase in the size of optimized code
      > for loading the immediate, however this impact should be minimal and
      > will scale with the maximum number of bailout ids (e.g., the size of
      > code will increase by one instruction per bailout id on Arm, therefore
      > ~98,000 bailouts will be needed before the overhead is greater than
      > the current fixed table size).
      >
      > Change-Id: I838604b48fa04cbd45320c7b9dac0de08fd8eb25
      > Reviewed-on: https://chromium-review.googlesource.com/c/1398224
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58636}
      
      Change-Id: I4d070b90ebd4f9d4e82eaa74fe6d41c3a39d93e8
      Reviewed-on: https://chromium-review.googlesource.com/c/1400848Reviewed-by: 's avatarSreten Kovacevic <skovacevic@wavecomp.com>
      Commit-Queue: Sreten Kovacevic <skovacevic@wavecomp.com>
      Cr-Commit-Position: refs/heads/master@{#58655}
      b0dc60f6
  14. 21 Dec, 2018 3 commits
    • Sigurd Schneider's avatar
      Reland "[deoptimizer] Refactor GenerateDeoptimizationEntries" · 2a72b8ac
      Sigurd Schneider authored
      This is a reland of f63a657e
      
      Original change's description:
      > [deoptimizer] Refactor GenerateDeoptimizationEntries
      >
      > This reduces preprocessor-expanded source size by 64,359 from
      >
      > gen         (   21 files):    71,570 to    1,613,100 (   23x)
      > src         (  624 files):   367,830 to   52,964,659 (  144x)
      > test        (  392 files):   490,924 to   37,360,916 (   76x)
      > third_party (  432 files):   239,085 to    9,547,902 (   40x)
      > total       ( 1521 files): 1,184,093 to  102,461,098 (   87x)
      >
      > to
      >
      > gen         (   21 files):    71,570 to    1,613,100 (   23x)
      > src         (  624 files):   367,837 to   52,919,005 (  144x)
      > test        (  392 files):   490,924 to   37,342,211 (   76x)
      > third_party (  432 files):   239,085 to    9,547,902 (   40x)
      > total       ( 1521 files): 1,184,100 to  102,396,739 (   86x)
      >
      > Bug: v8:8562
      > Change-Id: Iee474e22ababa1e080b8d6359af4d0076903e59a
      > Reviewed-on: https://chromium-review.googlesource.com/c/1384091
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58424}
      
      TBR=jarin@chromium.org,ulan@chromium.org
      
      Bug: v8:8562
      Change-Id: I7a8a350414941f49c6155ff43e36e0cb0b2006e5
      Reviewed-on: https://chromium-review.googlesource.com/c/1387497Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58437}
      2a72b8ac
    • Sigurd Schneider's avatar
      Revert "[deoptimizer] Refactor GenerateDeoptimizationEntries" · 4b4175d7
      Sigurd Schneider authored
      This reverts commit f63a657e.
      
      Reason for revert: breaks compile on lite mode:
      
      https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8926535782549686576/+/steps/build/0/steps/compile/0/stdout
      
      
      Original change's description:
      > [deoptimizer] Refactor GenerateDeoptimizationEntries
      > 
      > This reduces preprocessor-expanded source size by 64,359 from
      > 
      > gen         (   21 files):    71,570 to    1,613,100 (   23x)
      > src         (  624 files):   367,830 to   52,964,659 (  144x)
      > test        (  392 files):   490,924 to   37,360,916 (   76x)
      > third_party (  432 files):   239,085 to    9,547,902 (   40x)
      > total       ( 1521 files): 1,184,093 to  102,461,098 (   87x)
      > 
      > to
      > 
      > gen         (   21 files):    71,570 to    1,613,100 (   23x)
      > src         (  624 files):   367,837 to   52,919,005 (  144x)
      > test        (  392 files):   490,924 to   37,342,211 (   76x)
      > third_party (  432 files):   239,085 to    9,547,902 (   40x)
      > total       ( 1521 files): 1,184,100 to  102,396,739 (   86x)
      > 
      > Bug: v8:8562
      > Change-Id: Iee474e22ababa1e080b8d6359af4d0076903e59a
      > Reviewed-on: https://chromium-review.googlesource.com/c/1384091
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58424}
      
      TBR=ulan@chromium.org,jarin@chromium.org,sigurds@chromium.org
      
      Change-Id: I06e6f95255a3cea6a428713e9e841781425dffe8
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8562
      Reviewed-on: https://chromium-review.googlesource.com/c/1387494Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58425}
      4b4175d7
    • Sigurd Schneider's avatar
      [deoptimizer] Refactor GenerateDeoptimizationEntries · f63a657e
      Sigurd Schneider authored
      This reduces preprocessor-expanded source size by 64,359 from
      
      gen         (   21 files):    71,570 to    1,613,100 (   23x)
      src         (  624 files):   367,830 to   52,964,659 (  144x)
      test        (  392 files):   490,924 to   37,360,916 (   76x)
      third_party (  432 files):   239,085 to    9,547,902 (   40x)
      total       ( 1521 files): 1,184,093 to  102,461,098 (   87x)
      
      to
      
      gen         (   21 files):    71,570 to    1,613,100 (   23x)
      src         (  624 files):   367,837 to   52,919,005 (  144x)
      test        (  392 files):   490,924 to   37,342,211 (   76x)
      third_party (  432 files):   239,085 to    9,547,902 (   40x)
      total       ( 1521 files): 1,184,100 to  102,396,739 (   86x)
      
      Bug: v8:8562
      Change-Id: Iee474e22ababa1e080b8d6359af4d0076903e59a
      Reviewed-on: https://chromium-review.googlesource.com/c/1384091Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58424}
      f63a657e
  15. 16 Oct, 2018 1 commit
  16. 07 Aug, 2018 1 commit
  17. 13 Jun, 2018 1 commit
  18. 08 May, 2018 1 commit
  19. 25 Apr, 2018 1 commit
    • Andreas Haas's avatar
      Reland: [refactoring] Remove the isolate from signatures of ExternalReferences · 2a3c2c73
      Andreas Haas authored
      I missed one required change which was hidden behind an #if. The fix is in
      the diff between Patch 1 and Patch 3.
      
      Original message:
      In this CL I remove the isolate from signatures of ExternalReference
      accessor functions where the isolate is not used. The uses of the
      isolate were already removed in previous CLs.
      
      Changes:
      * I split the ExternalReference list in external-reference.h into
      those which need the isolate for initialization and those which do not.
      
      * I removed the public constructors and replaced them by
        ExternalReference::Create(). The reason is to separate external
        creation more clearly from internal creation, because externally
        created ExternalReferences sometimes need redirection, whereas
        internally created ExternalReferences are just stored as they are.
        In addition, by removing the isolate from the signature of the
        public constructors, they suddenly exactly matched the interal
        constructor.
      
      * Replace all uses of the public constructors with
        ExternalReference::Create().
      
      * Remove the isolate from all call sites where necessary.
      
      
      This is a step towards making WebAssembly compilation independent of
      the isolate.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:7570
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I750c162f5d58ed32e866722b0db920f8b9bd8057
      Reviewed-on: https://chromium-review.googlesource.com/1026673Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52777}
      2a3c2c73
  20. 24 Apr, 2018 2 commits
    • Andreas Haas's avatar
      Revert "[refactoring] Remove the isolate from signatures of ExternalReferences" · 7bfed2ad
      Andreas Haas authored
      This reverts commit 44ea425a.
      
      Reason for revert: https://ci.chromium.org/buildbot/client.v8.ports/V8%20Arm%20-%20debug%20builder/13575
      
      Original change's description:
      > [refactoring] Remove the isolate from signatures of ExternalReferences
      > 
      > In this CL I remove the isolate from signatures of ExternalReference
      > accessor functions where the isolate is not used. The uses of the
      > isolate were already removed in previous CLs.
      > 
      > Changes:
      > * I split the ExternalReference list in external-reference.h into
      > those which need the isolate for initialization and those which do not.
      > 
      > * I removed the public constructors and replaced them by
      >   ExternalReference::Create(). The reason is to separate external
      >   creation more clearly from internal creation, because externally
      >   created ExternalReferences sometimes need redirection, whereas
      >   internally created ExternalReferences are just stored as they are.
      >   In addition, by removing the isolate from the signature of the
      >   public constructors, they suddenly exactly matched the interal
      >   constructor.
      > 
      > * Replace all uses of the public constructors with
      >   ExternalReference::Create().
      > 
      > * Remove the isolate from all call sites where necessary.
      > 
      > 
      > This is a step towards making WebAssembly compilation independent of
      > the isolate.
      > 
      > Bug: v8:7570
      > R=​mstarzinger@chromium.org
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: I14f511fc6acc50ab2d6a6641299f5ddbeabef0da
      > Reviewed-on: https://chromium-review.googlesource.com/1018982
      > Commit-Queue: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52768}
      
      TBR=mstarzinger@chromium.org,ahaas@chromium.org
      
      Change-Id: I7c0d8d420f815cede23d550dee8942ac4d7791cc
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7570
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1026570Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52769}
      7bfed2ad
    • Andreas Haas's avatar
      [refactoring] Remove the isolate from signatures of ExternalReferences · 44ea425a
      Andreas Haas authored
      In this CL I remove the isolate from signatures of ExternalReference
      accessor functions where the isolate is not used. The uses of the
      isolate were already removed in previous CLs.
      
      Changes:
      * I split the ExternalReference list in external-reference.h into
      those which need the isolate for initialization and those which do not.
      
      * I removed the public constructors and replaced them by
        ExternalReference::Create(). The reason is to separate external
        creation more clearly from internal creation, because externally
        created ExternalReferences sometimes need redirection, whereas
        internally created ExternalReferences are just stored as they are.
        In addition, by removing the isolate from the signature of the
        public constructors, they suddenly exactly matched the interal
        constructor.
      
      * Replace all uses of the public constructors with
        ExternalReference::Create().
      
      * Remove the isolate from all call sites where necessary.
      
      
      This is a step towards making WebAssembly compilation independent of
      the isolate.
      
      Bug: v8:7570
      R=mstarzinger@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I14f511fc6acc50ab2d6a6641299f5ddbeabef0da
      Reviewed-on: https://chromium-review.googlesource.com/1018982
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52768}
      44ea425a
  21. 20 Oct, 2017 1 commit
  22. 18 Oct, 2017 1 commit
  23. 04 Oct, 2017 1 commit
  24. 13 Sep, 2017 1 commit
  25. 06 Sep, 2017 1 commit
    • Clemens Hammacher's avatar
      [assembler] Make Register et al. real classes · 9e995e12
      Clemens Hammacher authored
      Up to now, each architecture defined all Register types as structs,
      with lots of redundancy. An often found comment noted that they cannot
      be classes due to initialization order problems. As these problems are
      gone with C++11 constexpr constants, I now tried making Registers
      classes again.
      All register types now inherit from RegisterBase, which provides a
      default set of methods and named constructors (like ::from_code,
      code(), bit(), is_valid(), ...).
      This design allows to guarantee an interesting property: Each register
      is either valid, or it's the no_reg register. There are no other
      invalid registers. This is guaranteed statically by the constexpr
      constructor, and dynamically by ::from_code.
      
      I decided to disallow the default constructor completely, so instead of
      "Register reg;" you now need "Register reg = no_reg;". This makes
      explicit how the Register is initialized.
      
      I did this change to the x64, ia32, arm, arm64, mips and mips64 ports.
      Overall, code got much more compact and more safe. In theory, it should
      also increase performance (since the is_valid() check is simpler), but
      this is probably not measurable.
      
      R=mstarzinger@chromium.org
      
      Change-Id: I5ccfa4050daf4e146a557970e9d37fd3d2788d4a
      Reviewed-on: https://chromium-review.googlesource.com/650927Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47847}
      9e995e12
  26. 22 Aug, 2017 3 commits
  27. 11 Aug, 2017 1 commit
  28. 04 Aug, 2017 1 commit
  29. 03 Aug, 2017 2 commits
  30. 07 Jul, 2017 1 commit
  31. 26 Jun, 2017 1 commit