| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[x64][deopt] Zap code objects marked for lazy deopt The identification of code objects that should be deoptimized and the actual deoptimization happen at different points in time. It can therefore happen that deoptimization does not happen even though a code object is marked for deoptimization. With this CL, code objects on x64 get zapped with int3 the moment they are marked for deoptimization. Therefore, if for whatever reason deoptimization fails later, execution of that code object cannot continue, as it will cause a crash immediately. Bug: 422364570, 422951610 Change-Id: I93c31cafd24014f8a53b961ee7b78d3da7ef2af7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6624355 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#100968} | 1 年前 | |
[x64][deopt] Zap code objects marked for lazy deopt The identification of code objects that should be deoptimized and the actual deoptimization happen at different points in time. It can therefore happen that deoptimization does not happen even though a code object is marked for deoptimization. With this CL, code objects on x64 get zapped with int3 the moment they are marked for deoptimization. Therefore, if for whatever reason deoptimization fails later, execution of that code object cannot continue, as it will cause a crash immediately. Bug: 422364570, 422951610 Change-Id: I93c31cafd24014f8a53b961ee7b78d3da7ef2af7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6624355 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#100968} | 1 年前 | |
[x64][deopt] Zap code objects marked for lazy deopt The identification of code objects that should be deoptimized and the actual deoptimization happen at different points in time. It can therefore happen that deoptimization does not happen even though a code object is marked for deoptimization. With this CL, code objects on x64 get zapped with int3 the moment they are marked for deoptimization. Therefore, if for whatever reason deoptimization fails later, execution of that code object cannot continue, as it will cause a crash immediately. Bug: 422364570, 422951610 Change-Id: I93c31cafd24014f8a53b961ee7b78d3da7ef2af7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6624355 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#100968} | 1 年前 | |
[loong64][mips64][deopt] Zap code objects marked for lazy deopt Port commit 635b5186cc955c914f2f6fc43b60a9ddc8ed4c62 Currently just fix build issue, not implemented yet. Change-Id: I7c25e51c193f6eabf59224f7ce3eaeaac2e1b403 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6667061 Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/main@{#100990} | 1 年前 | |
[loong64][mips64][deopt] Zap code objects marked for lazy deopt Port commit 635b5186cc955c914f2f6fc43b60a9ddc8ed4c62 Currently just fix build issue, not implemented yet. Change-Id: I7c25e51c193f6eabf59224f7ce3eaeaac2e1b403 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6667061 Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/main@{#100990} | 1 年前 | |
PPC/s390: [compiler] Fix segfaults due to memory protection (pku) This applies to the simulator running on x64 with PKU available. Need to set the memory as writable. Change-Id: I53aab6a61308ca5f3f32895c7d5a5c05e71ccf01 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6842015 Reviewed-by: Junliang Yan <junyan1@ibm.com> Commit-Queue: Milad Farazmand <mfarazma@ibm.com> Cr-Commit-Position: refs/heads/main@{#101854} | 10 个月前 | |
[riscv][deopt] Change deopt entries into builtins "... introduced a new optimization in which the final jump to the deoptimization entry is generated once per Code object, and deopt exits can continue to emit a near-call." On RISCV64 the deopt exit size reduced from 8 byte to 4 byte. Before: 0x08a8 ld t6, -160(s6) 0x08ac jalr t6 After: # eager deoptimization entry jump. 0x0868 ld t2, -168(s6) 0x086c jr t2 # lazy deoptimization entry jump. 0x0870 ld t2, -160(s6) 0x0874 jr t2 # the deopt exit. 0x0898 jal -40 <lazy deoptimization entry jump offset> Port commit c7cb9beca18d98ba83c3b75860b912219d425d0e Bug: 41480764 Change-Id: Ia8a1817ce21dfcd0f944f640c71371f1b411aa80 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7000607 Auto-Submit: Ji Qiu <qiuji@iscas.ac.cn> Reviewed-by: Yahan Lu (LuYahan) <yahan@iscas.ac.cn> Commit-Queue: Ji Qiu <qiuji@iscas.ac.cn> Cr-Commit-Position: refs/heads/main@{#103076} | 8 个月前 | |
PPC/s390: [compiler] Fix segfaults due to memory protection (pku) This applies to the simulator running on x64 with PKU available. Need to set the memory as writable. Change-Id: I53aab6a61308ca5f3f32895c7d5a5c05e71ccf01 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6842015 Reviewed-by: Junliang Yan <junyan1@ibm.com> Commit-Queue: Milad Farazmand <mfarazma@ibm.com> Cr-Commit-Position: refs/heads/main@{#101854} | 10 个月前 | |
[heap] Fix processing of JSDispatch handle through RelocInfo Before this patch any dispatch handles contained in RelocInfo were assumed to be kept alive by their corresponding JSFunctions. This was fine as: - RelocInfo treated the corresponding JSFunction weakly which meant that the Code would be deoptimized if the JSFunction went away. - The top most frame was always strongified all references in case it could not be deoptimized. This meant that JSFunction and the dispatch handle (and instrunction stream) were marked this way. In a world with sandbox corruptions assuming a liveness witness does not hold anymore as attackers can break the link from JSFunction to dispatch handle (and thus instructon stream). This patch implements proper weak handling in RelocInfo's dispatch handles: - For regular processing the handles are treated weakly and discovering a dead handle leads to deoptimization of the code objects. - For the top most frame the dispatch handle and the instruction stream are strongified. Despite fixing the sandbox problem this also better follows the principle of treating edges individually (weak or strong) without considering other liveness witnesses which generally leads to more robust code. Fixed: 443772809 Change-Id: I4608cc830019c5267dfe49539867a7f0bbb0a144 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6939390 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#102520} | 9 个月前 | |
[compiler] Move signature lowering out of sea-of-nodes file This is a follow-up to https://crrev.com/c/5729976 which introduced a new dependency from the deoptimizer to the signature lowering done by the compiler. As the sea-of-nodes implementations in wasm-compiler.h will soon be replaced, still used functionality should be moved outside of these files. Bug: 42204618, 42204049 Change-Id: Ic85baae7642c93d35321851573b07768fe7aa5dc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5735772 Commit-Queue: Matthias Liedtke <mliedtke@chromium.org> Auto-Submit: Matthias Liedtke <mliedtke@chromium.org> Reviewed-by: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/main@{#95216} | 1 年前 | |
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 年前 | |
[deoptimizer] Add dmercadier and mliedtke as owners Change-Id: I404fd4fc29cd38974ddb9db3037cfb82c0713fb5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5516581 Auto-Submit: Matthias Liedtke <mliedtke@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#93718} | 2 年前 | |
More fine grained speculation control in charAt builtins Use a second bit for the SpeculationMode in call feedback. This allows us to do more fine grained speculations. In this CL we use this to both speculate on a charAt being called on a string and the char not being out of bounds. Bug: 420433007 Change-Id: I32e63a62891a63deaed139d0bde17c540a58c4d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6582363 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Olivier Flückiger <olivf@chromium.org> Commit-Queue: Olivier Flückiger <olivf@chromium.org> Cr-Commit-Position: refs/heads/main@{#100547} | 1 年前 | |
Reland "[maglev] No implicit Float64 <=> HoleyFloat64 conversion" This reverts commit cfc9e609fb50a28bcfe49fbebd4c8fff62c35a43. Reland fixes a number of bugs by handling missing cases of HoleyFloat64 handling, introducing missing conversion nodes and relaxing some DCHECKs. Bug: 448997822, 455515497, 458609996, 458677902, 458790911, 458849015, 458957498, 459129418, 459130968, 459310839, 459335522, 459526523, 459526524, 459629118 Change-Id: I94d2fc32f4c4d04544afd185fcf67d1447386ed1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7137286 Reviewed-by: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#103671} | 7 个月前 | |
[casting] Remove Tagged/Handle<T>::cast(value) Replace them both with Cast<T>(value). Bug: 345640551 Change-Id: Iee0a4b7e084d125cc0f8167d39de2c538469ef69 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5607996 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#94394} | 2 年前 | |
[deoptimizer] Refactor translation opcodes and array builder The final CL of this chain, this extracts translation opcodes into the TranslationOpcode class, and merges logic for TranslationArray creation into TranslationArrayBuilder. Drive-by: Pull TranslationArray printing logic into translation-state.cc. Bug: v8:11332 Change-Id: Ia4bbb6cdd15ea3318dfb9b7edb6eb881530dda54 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642254 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#72278} | 5 年前 | |
2026.03.30 arkweb_144代码蓝黄同步 Signed-off-by: jiujiaoxiaogula <sujiahao10@huawei.com> Change-Id: I00194d339064f999dedfc211cd5af5501cbed0fb | 3 个月前 | |
Reland "[tiering] Uniformly treat deopts which don't invalidate code" This is a reland of commit f7c2751ff9e362b668f6c0fbbcf2df2fe68f1635 Fix: Move new fields to the end of the Deoptimizer to fix access on arm Drive-By: Cleanup DeoptInfo to not record/read unused data Original change's description: > [tiering] Uniformly treat deopts which don't invalidate code > > There are currently two situations where deopts don't invalidate code: > * deopt in osr code and the deopt is outside the loop > * deopt to be able to osr from maglev to turbofan > > We should ensure that the deoptimizer and NotifyDeoptimized (a runtime > function which runs after the deoptimizer is done) agree on when code > needs to be discarded and when not. > > Also, if code is not discarded, or if deopts don't affect the main code, > we shouldn't change the tiering state. > > Drive-By: > * Read DeoptInfo only once and cache it. > * Reset tiering state only once. > > Change-Id: If789b6bbcab55eccf76010585152b1593b72134e > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7036595 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Auto-Submit: Olivier Flückiger <olivf@chromium.org> > Cr-Commit-Position: refs/heads/main@{#103114} Change-Id: Id86574b5a91588c8fcf12b29f49da5bb67ef74f9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7046222 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Olivier Flückiger <olivf@chromium.org> Cr-Commit-Position: refs/heads/main@{#103747} | 7 个月前 | |
[deoptimizer][wasm] Fix DCHECK for Float32 result in lazy deopt of JS-to-Wasm wrapper The Float32(float) constructor DCHECKs that the provided float is not a NaN value because for Wasm it is important to not accidentally change the bit representation of a NaN (as the wasm spec enforces keeping the bit representation unmodified for certain operations. For the JS-to-Wasm-wrapper this doesn't matter as JS does not have such guarantees and different NaN bit patterns should not result in observable differences in behavior. Fixed: 431542997 Change-Id: Ieadf5641534981410be6c423c8b4b3ede8ede75d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6732847 Auto-Submit: Matthias Liedtke <mliedtke@chromium.org> Reviewed-by: Paolo Severini <paolosev@microsoft.com> Reviewed-by: Darius Mercadier <dmercadier@chromium.org> Commit-Queue: Darius Mercadier <dmercadier@chromium.org> Cr-Commit-Position: refs/heads/main@{#101406} | 11 个月前 | |
Reland "[handles] Migration to direct handles, part 12" This is a reland of commit 5fa54d85a10049a55ba2fa02bc05145ddee7d19a Original change's description: > [handles] Migration to direct handles, part 12 > > This CL migrates a large number of handles to direct handles. The > changes are only relevant for builds with v8_enable_direct_handle=true. > > Affected source directories: api, asmjs, ast, builtins, codegen, > compiler, d8, debug, deoptimizer, diagnostics, execution, extensions, > heap, ic, init, interpreter, json, maglev, objects, parsing, profiler, > regexp, runtime, snapshot, strings, wasm, and tests. > > Bug: 42203211 > Change-Id: I2334b3295e5780e8f52d0b13d1545dce29fcf81e > Cq-Include-Trybots: luci.v8.try:v8_linux64_css_dbg > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6181904 > Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org> > Reviewed-by: Omer Katz <omerkatz@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/main@{#98240} Bug: 42203211 Change-Id: Ie21acd681c12e7212185d61a19bd858365650204 Cq-Include-Trybots: luci.v8.try:v8_linux64_css_dbg Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6187462 Reviewed-by: Omer Katz <omerkatz@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Nikolaos Papaspyrou <nikolaos@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/main@{#98249} | 1 年前 | |
Reland "[handles] Migration to direct handles, part 12" This is a reland of commit 5fa54d85a10049a55ba2fa02bc05145ddee7d19a Original change's description: > [handles] Migration to direct handles, part 12 > > This CL migrates a large number of handles to direct handles. The > changes are only relevant for builds with v8_enable_direct_handle=true. > > Affected source directories: api, asmjs, ast, builtins, codegen, > compiler, d8, debug, deoptimizer, diagnostics, execution, extensions, > heap, ic, init, interpreter, json, maglev, objects, parsing, profiler, > regexp, runtime, snapshot, strings, wasm, and tests. > > Bug: 42203211 > Change-Id: I2334b3295e5780e8f52d0b13d1545dce29fcf81e > Cq-Include-Trybots: luci.v8.try:v8_linux64_css_dbg > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6181904 > Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org> > Reviewed-by: Omer Katz <omerkatz@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/main@{#98240} Bug: 42203211 Change-Id: Ie21acd681c12e7212185d61a19bd858365650204 Cq-Include-Trybots: luci.v8.try:v8_linux64_css_dbg Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6187462 Reviewed-by: Omer Katz <omerkatz@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Nikolaos Papaspyrou <nikolaos@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/main@{#98249} | 1 年前 | |
[handles] Migration to direct handles, part 13 This CL migrates a large number of handles to direct handles. The changes are only relevant for builds with v8_enable_direct_handle=true. Affected source directories: api, ast, builtins, codegen, compiler, debug, deoptimizer, execution, heap, ic, init, interpreter, json, maglev, objects, parsing, regexp, runtime, snapshot, strings, temporal, wasm, and in tests. Bug: 42203211 Change-Id: Icb4238ee9082865dae47dce025e529a1c3fdfc48 Cq-Include-Trybots: luci.v8.try:v8_linux64_css_dbg Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6189992 Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org> Reviewed-by: Omer Katz <omerkatz@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#98283} | 1 年前 | |
[handles] Migration to direct handles, part 13 This CL migrates a large number of handles to direct handles. The changes are only relevant for builds with v8_enable_direct_handle=true. Affected source directories: api, ast, builtins, codegen, compiler, debug, deoptimizer, execution, heap, ic, init, interpreter, json, maglev, objects, parsing, regexp, runtime, snapshot, strings, temporal, wasm, and in tests. Bug: 42203211 Change-Id: Icb4238ee9082865dae47dce025e529a1c3fdfc48 Cq-Include-Trybots: luci.v8.try:v8_linux64_css_dbg Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6189992 Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org> Reviewed-by: Omer Katz <omerkatz@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#98283} | 1 年前 | |
[hole] Remove unneeded hole value checks Undo a bunch of work which added by-value hole checks. Originally we wanted to make holes fully unmapped, including their map pointer, so that potential hole values would have to be checked by pointer value rather than map checks. This turned out to be tricky, partially because the optimizing compiler could hoist map reads above hole checks, and partially because the extra hole value checks ended up with performance regressions. In https://crrev.com/c/7156717 we switched to keeping the holes' maps mapped with an unmapped payload after the map (very similar approach to the WasmNull). This means that all those hole checks we added are now unnecessary, since they were already covered by the existing map-based checks. We can also remove the --assert-hole-checked-by-value flag and fuzzing, since this is no longer an invariant we want to preserve. Bug: 434179415 Change-Id: I9399498d89592127e4291b8acffee83a3ba70052 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7206087 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#103982} | 7 个月前 | |
[deoptimizer] Store register params first for continuation stubs Builtin continuation stubs can have both in-register and on-stack parameters. The intuitive way of storing these is register params followed by stack params, since that's how they are defined in the descriptors (the first N parameters go into registers, the remainder go onto the stack). Until now, the translation frames were storing stack parameters first, and register parameters second. This had a good reason -- JS continuation builtin frames want to have the first translation parameter be the receiver for consistency with unoptimized frames during frame iteration. However, this leads to awkward re-ordering of the parameters to continuation stubs, which need to move the on stack parameters to the start of the parameters array, and notably we were forgetting to do this in Maglev (which caused issues in Turbolev on ia32, where there are fewer registers and therefore more stack parameters). We can make the parameter ordering more natural while preserving the receiver-first property by splitting up the encoding of JS-linkage continuation builtins and stub continuation builtins; these anyway differ in stack parameter order (JS-linkage pushes stack arguments in reverse order). This simplifies the stub parameter encoding (even removing the need for an intermediate std::vector) in TF, and keeps the Maglev one as-is. I've also added some documentation static_asserts for the receiver-first property of JS continuation frames, since that was surprising at first when I tried to make _all_ register parameters be before stack parameters, and code assuming that this is the case was spread out over a couple of different locations. Fixed: 428754707 Change-Id: If83d05536b0f62068be5ebb1e9ce8f5f79e6ae9a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6701447 Reviewed-by: Victor Gomes <victorgomes@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#101281} | 11 个月前 | |
[deopt] Use BytecodeArray param count for inlined args Use the parameter_count from the BytecodeArray to set the formal_parameter_count of an InlinedExtraArguments frame. Fixed: 379418918 Bug: 40931165, 336140976 Change-Id: I01aff44282c8caefdea86f943a02ba21f8884b7d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6031888 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Darius Mercadier <dmercadier@chromium.org> Cr-Commit-Position: refs/heads/main@{#97311} | 1 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 8 个月前 | ||
| 10 个月前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 7 个月前 | ||
| 2 年前 | ||
| 5 年前 | ||
| 3 个月前 | ||
| 7 个月前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 7 个月前 | ||
| 11 个月前 | ||
| 1 年前 |