| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[trap-handler] Remove dependencies on macros, globals, flags This will allow us to refactor those V8 files without being concerned about potential interference with the security of the trap handler. This requires the duplication of V8_EXPORT_PRIVATE, the CHECK/DCHECK macros, and V8_DISABLE_ASAN. The trap-handler specific definitions are prefixed with "TH_". R=ahaas@chromium.org Bug: v8:11755 Change-Id: Iac39b553704ef50e51937375c8db805d57ce2625 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2880218 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#74588} | 5 年前 | |
buganizer: fix component IDs in DIR_METADATA This only matches the old monorail components. Bug: 341800538 Change-Id: Id74fbdb3b9be0c858b77af84966c6c37adf78c5c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6025833 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Auto-Submit: Paul Semel <paulsemel@chromium.org> Commit-Queue: Paul Semel <paulsemel@chromium.org> Cr-Commit-Position: refs/heads/main@{#97252} | 1 年前 | |
[trap-handler] Add more owners Make mark@ and mseaborn@ owners of the trap-handler directory. R=ahaas@chromium.org CC=mark@chromium.org, mseaborn@chromium.org Change-Id: I0de583218895245527e8da4c2b6a8506dd007266 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4171632 Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Mark Mentovai <mark@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Mark Seaborn <mseaborn@chromium.org> Cr-Commit-Position: refs/heads/main@{#85357} | 3 年前 | |
Reland "Remove g_thread_in_wasm_code flag" This is a reland of commit 73288e18ba967b06e73cacd8f1659529915e3097 For ASan on Windows, we need more function to run without ASan instrumentation now. Original change's description: > Remove g_thread_in_wasm_code flag > > Keeping track of whether a thread is currently executing Wasm code or > not has become quite complex (see size of this change) and therefore a > maintenance burden. Furthermore, this feature now conflicts with future > V8 sandbox advancements as we want to forbid writes from sandboxed code > (which includes all Wasm code) to out-of-sandbox memory. As such, we can > no longer write to thread-local storage (where the flag was stored). > > This CL replaces the flag with a simpler guarding mechanism that ensures > that the trap handler is robust against nested faults and deadlocks. In > essence, we now set a thread-local flag (only) when entering the trap > handler or taking one of the locks used by it. If the flag is already > set when entering the trap handler, then we bail out immediately as it > means that we're either handling a nested fault (which we shouldn't) or > risk running into a deadlock because the current thread holds one of the > locks required by the trap handler. > > Bug: 350324877, 40192807 > Change-Id: Idb9fce83ac9b46ab04fd93d5bdbd8cb8c0722488 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6650680 > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Mark Seaborn <mseaborn@chromium.org> > Commit-Queue: Samuel Groß <saelo@chromium.org> > Reviewed-by: Matthias Liedtke <mliedtke@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/main@{#101213} Bug: 350324877, 40192807 Change-Id: I9c5a6b3820181129fa7ed4240831cfc1dbef1697 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6700520 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#101275} | 11 个月前 | |
Split V8_OS_MACOSX into V8_OS_DARWIN and V8_OS_MACOS Previously, V8_OS_MACOSX was, somewhat confusingly, also used for iOS. With this CL, V8_OS_DARWIN will be set on both macOS and iOS, V8_OS_MACOS only on macOS, and V8_OS_IOS only on iOS. This CL also renames V8_TARGET_OS_MACOSX to V8_TARGET_OS_MACOS and renames platform-xnu.cc to platform-darwin.cc. Change-Id: I4bcafc7c337586662114144f6c7ccf47d978da1f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3468577 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#79167} | 4 年前 | |
Reland "Remove g_thread_in_wasm_code flag" This is a reland of commit 73288e18ba967b06e73cacd8f1659529915e3097 For ASan on Windows, we need more function to run without ASan instrumentation now. Original change's description: > Remove g_thread_in_wasm_code flag > > Keeping track of whether a thread is currently executing Wasm code or > not has become quite complex (see size of this change) and therefore a > maintenance burden. Furthermore, this feature now conflicts with future > V8 sandbox advancements as we want to forbid writes from sandboxed code > (which includes all Wasm code) to out-of-sandbox memory. As such, we can > no longer write to thread-local storage (where the flag was stored). > > This CL replaces the flag with a simpler guarding mechanism that ensures > that the trap handler is robust against nested faults and deadlocks. In > essence, we now set a thread-local flag (only) when entering the trap > handler or taking one of the locks used by it. If the flag is already > set when entering the trap handler, then we bail out immediately as it > means that we're either handling a nested fault (which we shouldn't) or > risk running into a deadlock because the current thread holds one of the > locks required by the trap handler. > > Bug: 350324877, 40192807 > Change-Id: Idb9fce83ac9b46ab04fd93d5bdbd8cb8c0722488 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6650680 > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Mark Seaborn <mseaborn@chromium.org> > Commit-Queue: Samuel Groß <saelo@chromium.org> > Reviewed-by: Matthias Liedtke <mliedtke@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/main@{#101213} Bug: 350324877, 40192807 Change-Id: I9c5a6b3820181129fa7ed4240831cfc1dbef1697 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6700520 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#101275} | 11 个月前 | |
[trap-handler] Remove dependencies on macros, globals, flags This will allow us to refactor those V8 files without being concerned about potential interference with the security of the trap handler. This requires the duplication of V8_EXPORT_PRIVATE, the CHECK/DCHECK macros, and V8_DISABLE_ASAN. The trap-handler specific definitions are prefixed with "TH_". R=ahaas@chromium.org Bug: v8:11755 Change-Id: Iac39b553704ef50e51937375c8db805d57ce2625 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2880218 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#74588} | 5 年前 | |
Reland "Remove g_thread_in_wasm_code flag" This is a reland of commit 73288e18ba967b06e73cacd8f1659529915e3097 For ASan on Windows, we need more function to run without ASan instrumentation now. Original change's description: > Remove g_thread_in_wasm_code flag > > Keeping track of whether a thread is currently executing Wasm code or > not has become quite complex (see size of this change) and therefore a > maintenance burden. Furthermore, this feature now conflicts with future > V8 sandbox advancements as we want to forbid writes from sandboxed code > (which includes all Wasm code) to out-of-sandbox memory. As such, we can > no longer write to thread-local storage (where the flag was stored). > > This CL replaces the flag with a simpler guarding mechanism that ensures > that the trap handler is robust against nested faults and deadlocks. In > essence, we now set a thread-local flag (only) when entering the trap > handler or taking one of the locks used by it. If the flag is already > set when entering the trap handler, then we bail out immediately as it > means that we're either handling a nested fault (which we shouldn't) or > risk running into a deadlock because the current thread holds one of the > locks required by the trap handler. > > Bug: 350324877, 40192807 > Change-Id: Idb9fce83ac9b46ab04fd93d5bdbd8cb8c0722488 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6650680 > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Mark Seaborn <mseaborn@chromium.org> > Commit-Queue: Samuel Groß <saelo@chromium.org> > Reviewed-by: Matthias Liedtke <mliedtke@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/main@{#101213} Bug: 350324877, 40192807 Change-Id: I9c5a6b3820181129fa7ed4240831cfc1dbef1697 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6700520 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#101275} | 11 个月前 | |
[cleanup] Replace deprecated goo.gl links That service will shut down in a few months. To prevent data loss, this patch replaces all goo.gl short links with their full version. Change-Id: I14eebeb68e4c27c6a6c312332975dbbfbd81932a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6491315 Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Mark Seaborn <mseaborn@chromium.org> Cr-Commit-Position: refs/heads/main@{#99936} | 1 年前 | |
[arm64] Allow enabling the simulator for arm64 builds. Testing on the simulator can sometimes be useful even when working natively on arm64, for example to experiment with features that are not available on the host. Change-Id: I62671d2dda00f4d2739ceb1e7ce8c4e7bbf5a04a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6439508 Reviewed-by: Mark Seaborn <mseaborn@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Cr-Commit-Position: refs/heads/main@{#99755} | 1 年前 | |
[cleanup] Replace deprecated goo.gl links That service will shut down in a few months. To prevent data loss, this patch replaces all goo.gl short links with their full version. Change-Id: I14eebeb68e4c27c6a6c312332975dbbfbd81932a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6491315 Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Mark Seaborn <mseaborn@chromium.org> Cr-Commit-Position: refs/heads/main@{#99936} | 1 年前 | |
Reland "Remove g_thread_in_wasm_code flag" This is a reland of commit 73288e18ba967b06e73cacd8f1659529915e3097 For ASan on Windows, we need more function to run without ASan instrumentation now. Original change's description: > Remove g_thread_in_wasm_code flag > > Keeping track of whether a thread is currently executing Wasm code or > not has become quite complex (see size of this change) and therefore a > maintenance burden. Furthermore, this feature now conflicts with future > V8 sandbox advancements as we want to forbid writes from sandboxed code > (which includes all Wasm code) to out-of-sandbox memory. As such, we can > no longer write to thread-local storage (where the flag was stored). > > This CL replaces the flag with a simpler guarding mechanism that ensures > that the trap handler is robust against nested faults and deadlocks. In > essence, we now set a thread-local flag (only) when entering the trap > handler or taking one of the locks used by it. If the flag is already > set when entering the trap handler, then we bail out immediately as it > means that we're either handling a nested fault (which we shouldn't) or > risk running into a deadlock because the current thread holds one of the > locks required by the trap handler. > > Bug: 350324877, 40192807 > Change-Id: Idb9fce83ac9b46ab04fd93d5bdbd8cb8c0722488 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6650680 > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Mark Seaborn <mseaborn@chromium.org> > Commit-Queue: Samuel Groß <saelo@chromium.org> > Reviewed-by: Matthias Liedtke <mliedtke@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/main@{#101213} Bug: 350324877, 40192807 Change-Id: I9c5a6b3820181129fa7ed4240831cfc1dbef1697 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6700520 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#101275} | 11 个月前 | |
Reland "Remove g_thread_in_wasm_code flag" This is a reland of commit 73288e18ba967b06e73cacd8f1659529915e3097 For ASan on Windows, we need more function to run without ASan instrumentation now. Original change's description: > Remove g_thread_in_wasm_code flag > > Keeping track of whether a thread is currently executing Wasm code or > not has become quite complex (see size of this change) and therefore a > maintenance burden. Furthermore, this feature now conflicts with future > V8 sandbox advancements as we want to forbid writes from sandboxed code > (which includes all Wasm code) to out-of-sandbox memory. As such, we can > no longer write to thread-local storage (where the flag was stored). > > This CL replaces the flag with a simpler guarding mechanism that ensures > that the trap handler is robust against nested faults and deadlocks. In > essence, we now set a thread-local flag (only) when entering the trap > handler or taking one of the locks used by it. If the flag is already > set when entering the trap handler, then we bail out immediately as it > means that we're either handling a nested fault (which we shouldn't) or > risk running into a deadlock because the current thread holds one of the > locks required by the trap handler. > > Bug: 350324877, 40192807 > Change-Id: Idb9fce83ac9b46ab04fd93d5bdbd8cb8c0722488 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6650680 > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Mark Seaborn <mseaborn@chromium.org> > Commit-Queue: Samuel Groß <saelo@chromium.org> > Reviewed-by: Matthias Liedtke <mliedtke@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/main@{#101213} Bug: 350324877, 40192807 Change-Id: I9c5a6b3820181129fa7ed4240831cfc1dbef1697 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6700520 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#101275} | 11 个月前 | |
Reland "Remove g_thread_in_wasm_code flag" This is a reland of commit 73288e18ba967b06e73cacd8f1659529915e3097 For ASan on Windows, we need more function to run without ASan instrumentation now. Original change's description: > Remove g_thread_in_wasm_code flag > > Keeping track of whether a thread is currently executing Wasm code or > not has become quite complex (see size of this change) and therefore a > maintenance burden. Furthermore, this feature now conflicts with future > V8 sandbox advancements as we want to forbid writes from sandboxed code > (which includes all Wasm code) to out-of-sandbox memory. As such, we can > no longer write to thread-local storage (where the flag was stored). > > This CL replaces the flag with a simpler guarding mechanism that ensures > that the trap handler is robust against nested faults and deadlocks. In > essence, we now set a thread-local flag (only) when entering the trap > handler or taking one of the locks used by it. If the flag is already > set when entering the trap handler, then we bail out immediately as it > means that we're either handling a nested fault (which we shouldn't) or > risk running into a deadlock because the current thread holds one of the > locks required by the trap handler. > > Bug: 350324877, 40192807 > Change-Id: Idb9fce83ac9b46ab04fd93d5bdbd8cb8c0722488 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6650680 > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Mark Seaborn <mseaborn@chromium.org> > Commit-Queue: Samuel Groß <saelo@chromium.org> > Reviewed-by: Matthias Liedtke <mliedtke@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/main@{#101213} Bug: 350324877, 40192807 Change-Id: I9c5a6b3820181129fa7ed4240831cfc1dbef1697 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6700520 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#101275} | 11 个月前 | |
[win][msvc] fix cross-compilation for arm64 Cross-compiling x64 to ARM64 on Windows fails with MSVC. The reason is the ProbeMemory function which uses asm() code prohibited in this case. This change adds conditionalizing on V8_TRAP_HANDLER_SUPPORTED thus removing the problematic parts of the code in MSVC cross-compilation. This extends https://chromium-review.googlesource.com/c/v8/v8/+/3964232 in a way, as it wraps ProbeMemory usage inside of the "#ifdef V8_TRAP_HANDLER_VIA_SIMULATOR" blocks. This follows https://chromium-review.googlesource.com/c/v8/v8/+/4403215 and https://chromium-review.googlesource.com/c/v8/v8/+/4489305 as a part of an effort to completely fix cross-compilation with MSVC. Change-Id: I59d9a995fbc8ee1cee2807429fd44d8043c178fb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4574697 Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Mark Seaborn <mseaborn@chromium.org> Commit-Queue: Mark Seaborn <mseaborn@chromium.org> Cr-Commit-Position: refs/heads/main@{#88147} | 3 年前 | |
2026.03.30 arkweb_144代码蓝黄同步 Signed-off-by: jiujiaoxiaogula <sujiahao10@huawei.com> Change-Id: I00194d339064f999dedfc211cd5af5501cbed0fb | 3 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 5 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 11 个月前 | ||
| 4 年前 | ||
| 11 个月前 | ||
| 5 年前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 11 个月前 | ||
| 11 个月前 | ||
| 11 个月前 | ||
| 3 年前 | ||
| 3 个月前 |