[sandbox] Reference Code objects (and their entrypoint) through the CPT [v8/v8 : main]
Samuel Groß (Gerrit)
Samuel Groß has uploaded this change for review.
[sandbox] Reference Code objects (and their entrypoint) through the CPT
With this change, when the sandbox is enabled, the entries of the code
pointer table (CPT) now consist of two pointers: a pointer to a Code
object and a pointer to the entrypoint of the associated instruction
stream.
This change thereby achieves two things at the same time: (1) it
recovers the performance regression of code pointer sandboxing and (2)
it prepares for a future where (some) HeapObjects can live outside of
the sandbox and be safely referenced from inside it:
1) Previously, when calling/jumping to a JSFunction, we would have to
obtain the entrypoint by first accessing the function's Code object,
then loading the entrypoint pointer from there. With this change, the
JSFunction references its Code object through the CPT, and the CPT
entry directly contains the entrypoint pointer. Therefore, the new
lookup is JSFunction -> CPT entry -> entrypoint, which requires the
same number of memory accesses as without the sandbox. This seems to
recover virtually all of the performance regression previously
introduced for code pointer sandboxing.
2) Some sensitive types of HeapObjects allow stack or code corruption
when manipulated by an attacker. Likely the best way to deal with
this is to move these objects out of the sandbox and reference them
in some "safe" way. This change prepares for that by referencing Code
objects through a pointer table indirection (instead of a compressed
pointer). Afterwards, Code objects can be moved to a different heap
since the pointer table contains a full pointer to them. This
mechanism can then be generalized to support other types of sensitive
objects as well.
For this change, this CL introduces the concept of "indirect pointers".
An indirect pointer is a reference to a HeapObject which goes through a
pointer table indirection. As such, if object A references object B
through an indirect pointer, then A will have a 32-bit
"IndirectPointerHandle" which is an index into a pointer table. The
entry referenced through that handle then contains the real pointer to
object B.
This requires the following changes:
- We need indirect pointer accessors, (e.g. ReadIndirectPointerField).
We also introduce "MaybeIndirectPointer" variants which will load an
indirect pointer when the sandbox is enabled and a "regular" pointer
otherwise. This way we avoid having to put `#ifdef V8_ENABLE_SANDBOX`
into all the field accessors but can instead simply use these helper
functions.
- Since HeapObjects can be relocated during e.g. compacting GC, there
needs to be a mechanism that ensures that these indirect pointers stay
valid. While regular pointers use remembered sets for this (which
allow the GC to update the pointer when the pointed-to object moves),
indirect pointers use a different mechanism: here, the pointed-to
object owns its table entry (via a "self" indirect pointer) and
updates this entry whenever it is relocated. This way, the table entry
always contains the correct pointer.
- We need a new method in object visitors: VisitIndirectPointer. Besides
requiring the host object and a IndirectPointerSlot (representing this
new type of field), this method also takes a IndirectPointerMode
parameter which expresses the relationship between the host and the
pointed-to object. This is used to express weak ownership (required
for JSFunctions) as well as the "self" pointer that keeps the table
entry alive.
- We need support in the serializer and deserializer. This works by
encoding a kIndirectPointerPrefix before encoding the object
referenced through an indirect pointer. When the deserializer sees
this prefix, it makes sure to store the reference in a pointer table.
- We need a new type of write barrier that is aware of these types of
references. For that, a number of new write barrier functions in the
macro assemblers, code stub assemblers, and C++ runtime are added.
Bug: chromium:1395058
Change-Id: I783f9fcd2dbbef2b61feb6954de88a728d5442b5
---
M BUILD.bazel
M BUILD.gn
M include/v8-internal.h
M src/builtins/arm/builtins-arm.cc
M src/builtins/arm64/builtins-arm64.cc
M src/builtins/base.tq
M src/builtins/builtins-async-gen.cc
M src/builtins/builtins-constructor-gen.cc
M src/builtins/builtins-definitions.h
M src/builtins/builtins-internal-gen.cc
M src/builtins/builtins-lazy-gen.cc
M src/builtins/builtins.h
M src/builtins/ia32/builtins-ia32.cc
M src/builtins/x64/builtins-x64.cc
M src/codegen/arm/macro-assembler-arm.cc
M src/codegen/arm/macro-assembler-arm.h
M src/codegen/arm64/macro-assembler-arm64.cc
M src/codegen/arm64/macro-assembler-arm64.h
M src/codegen/code-stub-assembler.cc
M src/codegen/code-stub-assembler.h
M src/codegen/external-reference.cc
M src/codegen/external-reference.h
M src/codegen/ia32/macro-assembler-ia32.cc
M src/codegen/ia32/macro-assembler-ia32.h
M src/codegen/machine-type.h
M src/codegen/tnode.h
M src/codegen/x64/macro-assembler-x64.cc
M src/codegen/x64/macro-assembler-x64.h
M src/common/globals.h
M src/compiler/access-builder.cc
M src/compiler/access-builder.h
M src/compiler/backend/arm/code-generator-arm.cc
M src/compiler/backend/arm64/code-generator-arm64.cc
M src/compiler/backend/arm64/instruction-selector-arm64.cc
M src/compiler/backend/ia32/code-generator-ia32.cc
M src/compiler/backend/instruction-codes.h
M src/compiler/backend/x64/code-generator-x64.cc
M src/compiler/backend/x64/instruction-selector-x64.cc
M src/compiler/code-assembler.cc
M src/compiler/code-assembler.h
M src/compiler/js-create-lowering.cc
M src/compiler/machine-operator.cc
M src/compiler/wasm-compiler.cc
M src/compiler/write-barrier-kind.h
M src/diagnostics/objects-debug.cc
M src/execution/isolate.cc
M src/heap/heap-write-barrier-inl.h
M src/heap/heap-write-barrier.cc
M src/heap/heap-write-barrier.h
M src/heap/mark-compact.cc
M src/heap/marking-barrier.cc
M src/heap/marking-barrier.h
M src/heap/marking-visitor-inl.h
M src/heap/marking-visitor.h
M src/maglev/maglev-ir.cc
M src/objects/code-inl.h
M src/objects/code.h
M src/objects/heap-object.h
M src/objects/js-function-inl.h
M src/objects/js-function.tq
M src/objects/object-macros.h
M src/objects/objects-body-descriptors-inl.h
M src/objects/objects-body-descriptors.h
M src/objects/objects-inl.h
M src/objects/objects.h
M src/objects/slots-inl.h
M src/objects/slots.h
M src/objects/visitors.h
M src/profiler/heap-snapshot-generator.cc
M src/sandbox/code-pointer-inl.h
M src/sandbox/code-pointer-table-inl.h
M src/sandbox/code-pointer-table.h
M src/sandbox/code-pointer.h
A src/sandbox/indirect-pointer-inl.h
A src/sandbox/indirect-pointer.h
M src/snapshot/deserializer.cc
M src/snapshot/deserializer.h
M src/snapshot/serializer-deserializer.h
M src/snapshot/serializer.cc
M src/snapshot/serializer.h
M src/torque/constants.h
M src/torque/global-context.cc
M src/torque/global-context.h
M src/torque/implementation-visitor.cc
M src/torque/torque-parser.cc
M src/torque/type-oracle.h
M src/torque/types.cc
M test/unittests/compiler/arm64/instruction-selector-arm64-unittest.cc
M test/unittests/torque/torque-unittest.cc
89 files changed, 1,548 insertions(+), 353 deletions(-)
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Samuel Groß (Gerrit)
5 comments:
File include/v8-internal.h:
Patch Set #36, Line 591:
static const int kBuiltinTier0EntryTableSize = 9 * kApiSystemPointerSize;I'm not sure what the consequences are of adding more Tier0 entries? Should they become Tier1 or something like that?
File src/common/globals.h:
Patch Set #30, Line 688:
enum IndirectPointerMode {Should this get a better name as well? Maybe `IndirectPointerOwnership`? Does that still fit with `kSelf`?
File src/common/globals.h:
Patch Set #26, Line 686:
enum class PointerType { kDirect, kIndirect };This name feels a bit too generic. Any ideas for a better name?
File src/compiler/access-builder.cc:
Patch Set #35, Line 210:
// Here we pretend that these fields are tagged values (i.e. Smis) since thatI'm not entirely sure this works correctly. Previously, I was using a simple Uint32 here, but to me it looked like in that case, the object materialization code should shift the value to the left (i.e. convert it to a Smi) since it can only handle tagged fields. This "workaround" seemed to work fine though.
The other thing I'm not sure about is whether this guarantees that the referenced `Code` object is kept alive when the function is dematerialized by the escape analysis?
File src/heap/mark-compact.cc:
Patch Set #14, Line 3238:
// This is only necessary when the sandbox is not enabled. If it is, theI think we don't need to do this since we handle relocating Code object differently, but please double check that this is all that this code is trying to achieve.
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Jakob Linke (Gerrit)
Patch Set #36, Line 591:
static const int kBuiltinTier0EntryTableSize = 9 * kApiSystemPointerSize;
I'm not sure what the consequences are of adding more Tier0 entries? Should they become Tier1 or som […]
Quick answer: tier0 entries just use up IsolateData slots that can be addressed with compact instructions. Only add tier0 entries for builtins that are known to be *very* frequently used, or need fixed-size call instruction encodings for some other reason.
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Samuel Groß (Gerrit)
Attention is currently required from: Igor Sheludko, Jakob Linke, Michael Lippautz, Tobias Tebbi.
Samuel Groß would like Michael Lippautz, Jakob Linke, Tobias Tebbi and Igor Sheludko to review this change.
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Samuel Groß (Gerrit)
Attention is currently required from: Igor Sheludko, Jakob Linke, Michael Lippautz, Tobias Tebbi.
1 comment:
Patchset:
I'm sorry that this is such a large CL, but I don't see a way to split it up into chunks that make much sense on their own. The feature does seem to need all these changes to actually work...
Jakob, could you take a look at src/snapshot,
Michael at src/heap and the write barrier changes,
Igor at the general runtime-related changes,
and Tobias (or someone else on your team) at src/compiler?
Thanks!!
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Jakob Linke (Gerrit)
Attention is currently required from: Igor Sheludko, Michael Lippautz, Samuel Groß, Tobias Tebbi.
7 comments:
Patchset:
Quick pass over snapshot/, I'll have a closer look at the rest Tuesday morning.
File src/snapshot/deserializer.cc:
Patch Set #38, Line 585:
next_reference_is_indirect_pointer_ = false;Please DCHECK that the next ref isn't both weak and indirect.
File src/snapshot/serializer.cc:
Patch Set #38, Line 1122:
bytes_processed_so_far_ += kTaggedSize;kIndirectPointerSlotSize?
Patch Set #38, Line 1128:
if (!serializer_->SerializePendingObject(*obj)) {If I'm reading the deserializer correctly, we DCHECK there that this case doesn't happen?
Patch Set #38, Line 1201:
#ifndef V8_CODE_POINTER_SANDBOXINGnit: slight pref for non-negated conditions i.e. switching the branch order.
Patch Set #38, Line 1205:
static uint8_t field_value[kSystemPointerSize] = {0};The kCodePointerSlotSize constant is still useful in this build config, no?
Patch Set #38, Line 1217:
#endifnit: #endif // V8_CODE_POINTER_SANDBOXING
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Samuel Groß (Gerrit)
Attention is currently required from: Igor Sheludko, Jakob Linke, Michael Lippautz, Tobias Tebbi.
6 comments:
File src/snapshot/deserializer.cc:
Patch Set #38, Line 585:
next_reference_is_indirect_pointer_ = false;Please DCHECK that the next ref isn't both weak and indirect.
Done
File src/snapshot/serializer.cc:
Patch Set #38, Line 1122:
bytes_processed_so_far_ += kTaggedSize;kIndirectPointerSlotSize?
Done
Patch Set #38, Line 1128:
if (!serializer_->SerializePendingObject(*obj)) {If I'm reading the deserializer correctly, we DCHECK there that this case doesn't happen?
Right good point, I turned this into a DCHECK as well, can you double-check that the comment makes sense (I'm not 100% certain I understand what these are, I assume they are (back)references to pending/queued objects that will be serialized later)?
Patch Set #38, Line 1201:
#ifndef V8_CODE_POINTER_SANDBOXINGnit: slight pref for non-negated conditions i.e. switching the branch order.
Done
Patch Set #38, Line 1205:
static uint8_t field_value[kSystemPointerSize] = {0};The kCodePointerSlotSize constant is still useful in this build config, no?
Yep, true
Patch Set #38, Line 1217:
#endifnit: #endif // V8_CODE_POINTER_SANDBOXING
Done
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Jakob Linke (Gerrit)
Attention is currently required from: Igor Sheludko, Jakob Linke, Michael Lippautz, Tobias Tebbi.
7 comments:
File src/codegen/x64/macro-assembler-x64.cc:
Patch Set #38, Line 493:
// Currently, only Code objects can be referenced through indirect pointers.Suggestion: perhaps turn this and related comments into `static_assert(kAllIndirectPointerObjectsAreCode)`, it'll make relevant spots easier to find.
Patch Set #38, Line 674:
cmp_tagged(value, Operand(slot_address, 0));Why not add support for indirect ptrs here? Wouldn't it just be a LoadCodePointerField call (plus some push/pops)?
Patch Set #38, Line 932:
V8_CODE_POINTER_SANDBOXING_BOOL ? PointerType::kIndirectSuggestion: extract this to `CodePointerType()` or `kCodePointerType`.
File src/execution/isolate.cc:
Patch Set #38, Line 455:
static_assert(Code::kSelfIndirectPointerOffsetEnd + 1 ==Is this field's value preserved through deserialization? If so, we could include it in the hash.
File src/heap/marking-visitor-inl.h:
Patch Set #38, Line 372:
#ifdef V8_CODE_POINTER_SANDBOXINGSince this pattern is used at least twice, please extract it to `Object raw_code(AcquireLoadTag)`.
File src/objects/js-function-inl.h:
Patch Set #38, Line 259:
// initialized here but the SharedFunctionInfo, InstructionStream objects mayI wonder if this comment is still up to date. I don't see how JSFunction could point at an uninitialized Code object (or SFI). Anyways, please update 'InstructionStream'->'Code', thanks :)
File src/objects/js-function.tq:
Patch Set #38, Line 39:
@ifnot(V8_CODE_POINTER_SANDBOXING) code: Code;nit: please keep the @if/@ifnot parts adjacent.
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Jakob Linke (Gerrit)
Attention is currently required from: Igor Sheludko, Michael Lippautz, Samuel Groß, Tobias Tebbi.
3 comments:
File src/objects/js-function-inl.h:
Patch Set #38, Line 259:
// initialized here but the SharedFunctionInfo, InstructionStream objects may
I wonder if this comment is still up to date. […]
Re uninitialized Code obj: I guess this is due to concurrent code creation for SP (and now ML).
File src/objects/objects-body-descriptors-inl.h:
Patch Set #39, Line 1123:
obj, obj.RawIndirectPointerField(kInstructionStartOffset),kSelfIndirectPointerOffset
File src/snapshot/serializer.cc:
Patch Set #38, Line 1128:
if (!serializer_->SerializePendingObject(*obj)) {Right good point, I turned this into a DCHECK as well, can you double-check that the comment makes s […]
Hmm.. I think we're currently okay, because don't serialize any Code objects except for builtins, which end up in the RO snapshot. These are never pending.
This doesn't hold once you extend the indirect ptr mechanism to other object types though. See https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:v8/src/snapshot/serializer.cc;l=751;drc=f09c12c84b39d13189a7039a05253ca3766d4751 for the deferral decision. Perhaps comment this extensively here, together with a DCHECK that `host` is JSFunction and `target` is Code?
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Samuel Groß (Gerrit)
Attention is currently required from: Igor Sheludko, Jakob Linke, Michael Lippautz, Tobias Tebbi.
9 comments:
File src/codegen/x64/macro-assembler-x64.cc:
Patch Set #38, Line 493:
// Currently, only Code objects can be referenced through indirect pointers.
Suggestion: perhaps turn this and related comments into `static_assert(kAllIndirectPointerObjectsAre […]
Nice idea, done!
Patch Set #38, Line 932:
V8_CODE_POINTER_SANDBOXING_BOOL ? PointerType::kIndirectSuggestion: extract this to `CodePointerType()` or `kCodePointerType`.
Done
File src/execution/isolate.cc:
Patch Set #38, Line 455:
static_assert(Code::kSelfIndirectPointerOffsetEnd + 1 ==Is this field's value preserved through deserialization? If so, we could include it in the hash.
If I understand your question correctly then no, the "self" indirect pointer will be reconstructed during deserialization because we need to allocate a code pointer table entry for it, and set the self-pointer to that entry. So we may end up with a different table entry (and therefore another value of this slot) for the object after deserialization. Is that what you meant?
File src/heap/marking-visitor-inl.h:
Patch Set #38, Line 372:
#ifdef V8_CODE_POINTER_SANDBOXINGSince this pattern is used at least twice, please extract it to `Object raw_code(AcquireLoadTag)`.
Good idea! Now also the regular `code` accessors use `raw_code` (+ type cast), but let me know if you prefer to keep these separate.
File src/objects/js-function-inl.h:
Patch Set #38, Line 259:
// initialized here but the SharedFunctionInfo, InstructionStream objects mayI wonder if this comment is still up to date. […]
Right, I was wondering the same. I think I figured it meant that the pointer to these objects could be uninitialized (i.e. Smi::zero()), but now that I read it again, that's not what it sounds like... Maybe it just means that we need to use acquire load here so that the object cannot be uninitialized due to instruction reordering? In any case, changed it to `Code` now.
File src/objects/js-function.tq:
Patch Set #38, Line 39:
@ifnot(V8_CODE_POINTER_SANDBOXING) code: Code;nit: please keep the @if/@ifnot parts adjacent.
Done
File src/objects/objects-body-descriptors-inl.h:
Patch Set #39, Line 1123:
obj, obj.RawIndirectPointerField(kInstructionStartOffset),kSelfIndirectPointerOffset
Done
File src/snapshot/serializer.cc:
Patch Set #38, Line 1128:
if (!serializer_->SerializePendingObject(*obj)) {
Hmm.. […]
Cool, thanks for the pointers, Done.
Patch Set #38, Line 1205:
static uint8_t field_value[kSystemPointerSize] = {0};
Yep, true
Ah actually no, `kCodePointerSlotSize` no longer exists because `code pointer` is now a "reference to an entry in the code pointer table that contains both a pointer to a Code object and its entrypoint" and that concept only exists when the sandbox is enabled. In non-sandbox builds, kInstructionStartOffset is defined as a kSystemPointerSize-sized field in code.h, so I think this should also just be kSystemPointerSize.
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Jakob Linke (Gerrit)
Attention is currently required from: Igor Sheludko, Michael Lippautz, Samuel Groß, Tobias Tebbi.
1 comment:
File src/execution/isolate.cc:
Patch Set #38, Line 455:
static_assert(Code::kSelfIndirectPointerOffsetEnd + 1 ==
If I understand your question correctly then no, the "self" indirect pointer will be reconstructed d […]
Yes that's what I meant. With v8_enable_shared_ro_heap=true, we could guarantee the same table indices for builtin Code objs since they are all be deserialized in a deterministic order once-per-process before all other Code objs.
With v8_enable_shared_ro_heap=false this doesn't hold, but I'm not sure we need this config at all (in combination with sandboxing).
Including them in the hash isn't super important, just a nice to have if possible.
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Jakob Linke (Gerrit)
Attention is currently required from: Igor Sheludko, Michael Lippautz, Samuel Groß, Tobias Tebbi.
1 comment:
File src/objects/js-function-inl.h:
Patch Set #38, Line 259:
// initialized here but the SharedFunctionInfo, InstructionStream objects may
Right, I was wondering the same. […]
Discussed with Leszek offline - it's not related to concurrent code gen since the JSFunction::code/sfi fields are still set synchronously.
I got interested and followed the blame back: it was first introduced at [0] and later updated in [1]. AFAIK the `!IsCode` and `!IsSFI` branches are dead code in today's V8. Could you perhaps leave a TODO to investigate / attempt to change the branches to CHECKs? The acquire loads should be sufficient protection.
[0] https://chromium-review.googlesource.com/c/v8/v8/+/1393292/6/src/objects/js-objects-inl.h
[1] https://chromium-review.googlesource.com/c/v8/v8/+/3035774/4/src/objects/js-function-inl.h
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Samuel Groß (Gerrit)
Attention is currently required from: Igor Sheludko, Jakob Linke, Michael Lippautz, Tobias Tebbi.
2 comments:
File src/codegen/x64/macro-assembler-x64.cc:
Patch Set #38, Line 674:
cmp_tagged(value, Operand(slot_address, 0));Why not add support for indirect ptrs here? Wouldn't it just be a LoadCodePointerField call (plus so […]
It's a LoadIndirectPointerField call, which I've added now, probably makes sense to support this. I'm now assuming that `Pop` will always just emit a single `popq` instruction that doesn't affect flags. I can also move the pops after the check which would not make such assumptions, but it would also make the original register values less accessible. Not sure that matters though
File src/objects/js-function-inl.h:
Patch Set #38, Line 259:
// initialized here but the SharedFunctionInfo, InstructionStream objects may
Discussed with Leszek offline - it's not related to concurrent code gen since the JSFunction::code/s […]
Cool! Sure, added a comment now. I just made it `TODO(v8)`, or is there a more appropriate owner for this?
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Jakob Linke (Gerrit)
Attention is currently required from: Igor Sheludko, Michael Lippautz, Samuel Groß, Tobias Tebbi.
1 comment:
File src/objects/js-function-inl.h:
Patch Set #38, Line 259:
// initialized here but the SharedFunctionInfo, InstructionStream objects may
Cool! Sure, added a comment now. […]
SG, thanks :)
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Samuel Groß (Gerrit)
Attention is currently required from: Igor Sheludko, Jakob Linke, Michael Lippautz, Tobias Tebbi.
1 comment:
File src/execution/isolate.cc:
Patch Set #38, Line 455:
static_assert(Code::kSelfIndirectPointerOffsetEnd + 1 ==
Yes that's what I meant. […]
I tried this now (by making it `static constexpr int kStartOffset = Code::kSelfIndirectPointerOffset;`), but then I get
```
#
# Fatal error in ../../src/execution/isolate.cc, line 4593
# The Isolate is incompatible with the embedded blob. This is usually caused by incorrect usage of mksnapshot. When generating custom snapshots, embedders must ensure they pass the same flags as during the V8 build process (e.g.: --turbo-instruction-scheduling).
#
```During/after mksnapshot. Maybe the order that the Code objects are allocated during mksnapshot differs from the order that they are then post-processed during deserialization? Or is this some other issue?
To me it feels a little fragile to include the 'self' pointer since it will always be recomputed during deserialization, it just happens that that part should be deterministic.
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Samuel Groß (Gerrit)
Attention is currently required from: Igor Sheludko, Jakob Linke, Michael Lippautz, Tobias Tebbi.
1 comment:
File include/v8-internal.h:
Patch Set #36, Line 591:
static const int kBuiltinTier0EntryTableSize = 9 * kApiSystemPointerSize;
Quick answer: tier0 entries just use up IsolateData slots that can be addressed with compact instruc […]
I've downgraded them to tier1 builtins now. I'll run a quick benchmark, but I don't expect these to be too performance sensitive.
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Samuel Groß (Gerrit)
Attention is currently required from: Igor Sheludko, Jakob Linke, Michael Lippautz, Tobias Tebbi.
1 comment:
File src/compiler/access-builder.cc:
Patch Set #35, Line 210:
// Here we pretend that these fields are tagged values (i.e. Smis) since that
I'm not entirely sure this works correctly. […]
I guess the alternative way would be to:
- Introduce a new `MachineType::IndirectPointer()` (with `MachineRepresentation::kIndirectPointer`)
- Use this machine type here and in the indirect pointer loads/stores coming from CSA
- Handle the indirect pointers either in memory-lowering.cc or only in the macro-assembler at the very end of compilation
This would probably also resolve my concerns about GC + dematerialization: the dematerialized object would still look like it had a simple (direct) pointer to the `Code` object, which is then only converted to an indirect pointer during materialization (if necessary).
I can give that a shot as well, but I'd probably be another 100-ish LoCs or so. We could also go with this version first, then change it in a follow-up CL (or leave it like this entirely). Let me know what y'all prefer!
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Samuel Groß (Gerrit)
Attention is currently required from: Igor Sheludko, Jakob Linke, Michael Lippautz, Tobias Tebbi.
Samuel Groß uploaded patch set #46 to this change.
- We need a new MachineType/MemoryRepresentation for the compiler which
is used to emit the appropriate assembly code during code generation.
M src/codegen/machine-type.cc
M src/codegen/machine-type.h
M src/codegen/tnode.h
M src/codegen/x64/macro-assembler-x64.cc
M src/codegen/x64/macro-assembler-x64.h
M src/common/globals.h
M src/compiler/access-builder.cc
M src/compiler/access-builder.h
M src/compiler/backend/arm/code-generator-arm.cc
M src/compiler/backend/arm64/code-generator-arm64.cc
M src/compiler/backend/arm64/instruction-selector-arm64.cc
M src/compiler/backend/ia32/code-generator-ia32.cc
M src/compiler/backend/instruction-codes.h
M src/compiler/backend/instruction-scheduler.cc
M src/compiler/backend/instruction.cc
M src/compiler/backend/instruction.h
M src/compiler/backend/register-allocation.h
M src/compiler/backend/x64/code-generator-x64.cc
M src/compiler/backend/x64/instruction-codes-x64.h
M src/compiler/backend/x64/instruction-scheduler-x64.cc
M src/compiler/backend/x64/instruction-selector-x64.cc
M src/compiler/code-assembler.cc
M src/compiler/code-assembler.h
M src/compiler/decompression-optimizer.cc
M src/compiler/js-native-context-specialization.cc
M src/compiler/load-elimination.cc
M src/compiler/machine-graph-verifier.cc
M src/compiler/machine-operator.cc
M src/compiler/representation-change.cc
M src/compiler/simplified-lowering.cc
M src/compiler/turboshaft/representations.cc
M src/compiler/turboshaft/representations.h
M src/compiler/wasm-compiler.cc
M src/compiler/write-barrier-kind.h
M src/deoptimizer/translated-state.cc
M src/diagnostics/objects-debug.cc
M src/execution/isolate.cc
M src/heap/heap-write-barrier-inl.h
M src/heap/heap-write-barrier.cc
M src/heap/heap-write-barrier.h
M src/heap/mark-compact.cc
M src/heap/marking-barrier.cc
M src/heap/marking-barrier.h
M src/heap/marking-visitor-inl.h
M src/heap/marking-visitor.h
M src/maglev/maglev-ir.cc
M src/objects/code-inl.h
M src/objects/code.h
M src/objects/heap-object.h
M src/objects/js-function-inl.h
M src/objects/js-function.h
105 files changed, 1,773 insertions(+), 373 deletions(-)
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Samuel Groß (Gerrit)
Attention is currently required from: Igor Sheludko, Jakob Linke, Michael Lippautz, Tobias Tebbi.
Patch Set #35, Line 210:
// Here we pretend that these fields are tagged values (i.e. Smis) since that
I guess the alternative way would be to: […]
Chatted offline with Tobias, and this seems to be the way to go, so I implemented it now.
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Samuel Groß (Gerrit)
Attention is currently required from: Igor Sheludko, Jakob Linke, Michael Lippautz, Tobias Tebbi.
1 comment:
File src/compiler/write-barrier-kind.h:
Patch Set #48, Line 22:
kIndirectPointerWriteBarrier,I guess technically we don't need this since the write barrier kind is also implied by the machine representation now (`MachineRepresentation::kIndirectPointer` would imply an indirect pointer write barrier during code generation/instruction selection). But maybe it's still nice to make it explicit? Not sure, let me know if you have any preferences!
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Samuel Groß (Gerrit)
Attention is currently required from: Igor Sheludko, Jakob Linke, Michael Lippautz, Tobias Tebbi.
Samuel Groß uploaded patch set #50 to this change.
object owns its table entry and updates this entry whenever it is
relocated during compacting GC. This way, the table entry always
contains the correct pointer.
- We need a new method in object visitors: VisitIndirectPointer. Besides
requiring the host object and a IndirectPointerSlot (representing this
new type of field), this method also takes a IndirectPointerMode
parameter which expresses the relationship between the host and the
pointed-to object. This is used to express weak ownership, which is
required for JSFunctions.
M src/compiler/backend/arm/instruction-selector-arm.cc
M src/compiler/backend/arm64/code-generator-arm64.cc
M src/compiler/backend/arm64/instruction-codes-arm64.h
M src/compiler/backend/arm64/instruction-scheduler-arm64.cc
M src/compiler/backend/arm64/instruction-selector-arm64.cc
M src/compiler/backend/ia32/code-generator-ia32.cc
M src/compiler/backend/ia32/instruction-selector-ia32.cc
109 files changed, 1,828 insertions(+), 394 deletions(-)
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Samuel Groß (Gerrit)
Attention is currently required from: Igor Sheludko, Jakob Linke, Michael Lippautz, Tobias Tebbi.
Patch Set #30, Line 688:
enum IndirectPointerMode {
What do you mean with "via iteration"? […]
As discussed offline, I've now removed the `kSelf` value and instead added a separate visitor method: https://chromium-review.googlesource.com/c/v8/v8/+/4628448/48..50
We now have `VisitIndirectPointer` which visits a HeapObject through an indirect pointer, and we have `VisitIndirectPointerTableEntry`, which visits an entry in an indirect pointer table. WDYT?
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Jakob Linke (Gerrit)
Attention is currently required from: Igor Sheludko, Michael Lippautz, Samuel Groß, Tobias Tebbi.
2 comments:
File src/codegen/x64/macro-assembler-x64.cc:
Patch Set #38, Line 674:
cmp_tagged(value, Operand(slot_address, 0));
It's a LoadIndirectPointerField call, which I've added now, probably makes sense to support this. […]
Acknowledged
File src/execution/isolate.cc:
Patch Set #38, Line 455:
static_assert(Code::kSelfIndirectPointerOffsetEnd + 1 ==
I tried this now (by making it `static constexpr int kStartOffset = Code::kSelfIndirectPointerOffset […]
The setup/deserialization order should be the same. I don't know what creates the difference for you, but leaving it out of the hash sgtm.
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Jakob Linke (Gerrit)
Attention is currently required from: Igor Sheludko, Michael Lippautz, Samuel Groß, Tobias Tebbi.
Patch set 51:Code-Review +1
5 comments:
File src/codegen/code-stub-assembler.cc:
Patch Set #51, Line 1814:
Word32Shr(handle, UniqueUint32Constant(kCodePointerHandleShift));Same q here (as in masm), could we combine the 2 shifts?
File src/codegen/x64/macro-assembler-x64.cc:
shrl(destination, Immediate(kCodePointerHandleShift));
shll(destination, Immediate(kCodePointerTableEntrySizeLog2));So effectively `shr(destination, 2)`? Or is the point to also clear the 4 LSB?
File src/compiler/backend/x64/code-generator-x64.cc:
Patch Set #51, Line 679:
// Indirect pointer fields contain an index to a pointer table entry, whichnit: static_assert(kAllIndirectPointerObjectsAreCode);
File src/objects/objects-body-descriptors-inl.h:
Patch Set #51, Line 185:
v->VisitPointer(obj, obj.RawField(offset));Suggestion: go through IteratePointer/IterateCustomWeakPointer to not miss any DCHECKs.
File src/snapshot/serializer.cc:
Patch Set #51, Line 1121:
HeapObject target = HeapObject::cast(value);nit: we could avoid all these different names for the same value (value, target, obj) with:
```
Handle<HeapObject> slot_value(HeapObject::cast(slot.load()), isolate());
CHECK(slot_value->IsHeapObject());
```
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Samuel Groß (Gerrit)
Attention is currently required from: Igor Sheludko, Jakob Linke, Michael Lippautz, Tobias Tebbi.
6 comments:
Patchset:
Thanks Jakob!
File src/codegen/code-stub-assembler.cc:
Patch Set #51, Line 1814:
Word32Shr(handle, UniqueUint32Constant(kCodePointerHandleShift));Same q here (as in masm), could we combine the 2 shifts?
Acknowledged
File src/codegen/x64/macro-assembler-x64.cc:
shrl(destination, Immediate(kCodePointerHandleShift));
shll(destination, Immediate(kCodePointerTableEntrySizeLog2));So effectively `shr(destination, 2)`? Or is the point to also clear the 4 LSB?
Yeah, clearing the LSBs is important here. Otherwise, an attacker could set these bits and that way either confuse a code entrypoint pointer with a pointer to a `Code` object, or load one of these pointers at an offset. I think there's a comment about that somewhere, but we could replace this with one shift and a `times_8` for the memory load, but then we need to make sure that confusing `Code` and entrypoint pointer is always safe (it probably is, more or less...). But since Oli is already looking into adopting the code pointer table for tiering, I think it makes sense to wait with that. Possibly in the future we'll again only have one pointer in the table, and then we can always do one shift + scaled load.
File src/compiler/backend/x64/code-generator-x64.cc:
Patch Set #51, Line 679:
// Indirect pointer fields contain an index to a pointer table entry, whichnit: static_assert(kAllIndirectPointerObjectsAreCode);
Done
File src/objects/objects-body-descriptors-inl.h:
Patch Set #51, Line 185:
v->VisitPointer(obj, obj.RawField(offset));Suggestion: go through IteratePointer/IterateCustomWeakPointer to not miss any DCHECKs.
Ah yes, good idea!
File src/snapshot/serializer.cc:
Patch Set #51, Line 1121:
HeapObject target = HeapObject::cast(value);
nit: we could avoid all these different names for the same value (value, target, obj) with: […]
Nice, thanks!
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Tobias Tebbi (Gerrit)
Attention is currently required from: Igor Sheludko, Jakob Linke, Michael Lippautz, Samuel Groß.
Patch set 52:Code-Review +1
2 comments:
Patchset:
src/compiler and src/torque LGTM
File src/builtins/base.tq:
Patch Set #52, Line 237:
constexpr 'IndirectPointerHandle';Does it make sense to introduce a type
```
type IndirectPointer<To: type> extends IndirectPtr;
```
similar to `RawPtr` so that we can annotate the kind of object pointed to and possibly provide more typed operations in Torque to follow indirect pointers?
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Samuel Groß (Gerrit)
Attention is currently required from: Igor Sheludko, Jakob Linke, Michael Lippautz.
2 comments:
Patchset:
Thanks!
File src/builtins/base.tq:
Patch Set #52, Line 237:
constexpr 'IndirectPointerHandle';
Does it make sense to introduce a type […]
Oh that's a really nice idea! I implemented the bare minimum of that now in this CL (added the typedef you provided and made the `code` field in JSFunction a `IndirectPointer<Code>`), and left a TODO to extend this in the future.
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Igor Sheludko (Gerrit)
Attention is currently required from: Jakob Linke, Michael Lippautz, Samuel Groß.
Patch set 53:Code-Review +1
6 comments:
Patchset:
lgtm with nits
File src/codegen/arm64/macro-assembler-arm64.cc:
Patch Set #53, Line 3487:
const Register&Here and below: Why? `Register` is a one-word value anyway...
Patch Set #53, Line 3488:
const MemOperand field_operand,Same here... I think it's nicer to be uniform - ether switch all methods to oass around `const` or nothing.
File src/common/globals.h:
Patch Set #53, Line 698:
kStrong,Please consider defining the enum as an `enum class` to avoid polluting the global scope with such a generic names.
File src/common/globals.h:
Patch Set #26, Line 686:
enum class PointerType { kDirect, kIndirect };This name feels a bit too generic. […]
Maybe `kIndex` or `kTableIndex`? But `kIndirect` is fine too.
File src/objects/code.h:
Patch Set #53, Line 325:
value \Nit: are \ allowed in the middle of multiline comments?
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Michael Lippautz (Gerrit)
Attention is currently required from: Jakob Linke, Samuel Groß.
Patch set 53:Code-Review +1
3 comments:
Patchset:
heap parts lgtm, thanks for changing the indirection types. This now looks much more uniform.
File src/common/globals.h:
Patch Set #30, Line 688:
enum IndirectPointerMode {
As discussed offline, I've now removed the `kSelf` value and instead added a separate visitor method […]
Acknowledged
File src/heap/mark-compact.cc:
Patch Set #14, Line 3238:
// This is only necessary when the sandbox is not enabled. If it is, theI think we don't need to do this since we handle relocating Code object differently, but please doub […]
Acknowledged
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Samuel Groß (Gerrit)
Attention is currently required from: Jakob Linke.
7 comments:
File src/codegen/arm64/macro-assembler-arm64.cc:
Patch Set #53, Line 3487:
const Register&Here and below: Why? `Register` is a one-word value anyway...
Yeah it seems to be a bit inconsistent in this file, some methods use `const Register&`, others just `Register`. I agree that it should just a an int anyway, so no real point in passing a reference. I'll change it back.
Patch Set #53, Line 3488:
const MemOperand field_operand,
Same here... […]
Done
File src/codegen/x64/macro-assembler-x64.cc:
shrl(destination, Immediate(kCodePointerHandleShift));
shll(destination, Immediate(kCodePointerTableEntrySizeLog2));
Yeah, clearing the LSBs is important here. […]
Done
File src/common/globals.h:
Patch Set #53, Line 698:
kStrong,
Please consider defining the enum as an `enum class` to avoid polluting the global scope with such a […]
Done
File src/common/globals.h:
Patch Set #26, Line 686:
enum class PointerType { kDirect, kIndirect };
Maybe `kIndex` or `kTableIndex`? But `kIndirect` is fine too.
I think I'll stick with `kIndirect` since we use "indirect pointer" in many other places as well, so that should be the most recognizable
File src/compiler/write-barrier-kind.h:
Patch Set #48, Line 22:
kIndirectPointerWriteBarrier,
I guess technically we don't need this since the write barrier kind is also implied by the machine r […]
Done
File src/objects/code.h:
Patch Set #53, Line 325:
value \Nit: are \ allowed in the middle of multiline comments?
Ah good point, must be from `git cl format`, fixed it manually now.
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Michael Lippautz (Gerrit)
Attention is currently required from: Igor Sheludko, Jakob Linke, Samuel Groß, Tobias Tebbi.
Patch set 58:Code-Review +1
Samuel Groß (Gerrit)
Attention is currently required from: Igor Sheludko, Jakob Linke, Samuel Groß, Tobias Tebbi.
Patch set 58:Commit-Queue +2
V8 LUCI CQ (Gerrit)
V8 LUCI CQ submitted this change.
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4628448
Reviewed-by: Michael Lippautz <mlip...@chromium.org>
Commit-Queue: Samuel Groß <sa...@chromium.org>
Cr-Commit-Position: refs/heads/main@{#89285}
M src/objects/slots-inl.h
M src/objects/slots.h
M src/objects/visitors.h
M src/profiler/heap-snapshot-generator.cc
M src/sandbox/code-pointer-inl.h
M src/sandbox/code-pointer-table-inl.h
M src/sandbox/code-pointer-table.h
M src/sandbox/code-pointer.h
A src/sandbox/indirect-pointer-inl.h
A src/sandbox/indirect-pointer.h
M src/snapshot/deserializer.cc
M src/snapshot/deserializer.h
M src/snapshot/serializer-deserializer.h
M src/snapshot/serializer.cc
M src/snapshot/serializer.h
M src/torque/constants.h
M src/torque/global-context.cc
M src/torque/global-context.h
M src/torque/implementation-visitor.cc
M src/torque/torque-parser.cc
M src/torque/type-oracle.h
M src/torque/types.cc
M src/wasm/turboshaft-graph-interface.cc
M test/unittests/compiler/arm64/instruction-selector-arm64-unittest.cc
M test/unittests/torque/torque-unittest.cc
109 files changed, 1,812 insertions(+), 376 deletions(-)
Liu Yu (Gerrit)
Attention is currently required from: Zhao Jiazhong.
Liu Yu would like Zhao Jiazhong to review this change.
[loong64][mips64][sandbox] Reference Code objects (and their entrypoint) through the CPT
Port commit fbb9df7218ae348b56104ff8fdd82b578e42d189
Bug: chromium:1395058
Change-Id: I3edbc161ac9d30378ac7e6ad6850f2ae13208623
---
M src/builtins/loong64/builtins-loong64.cc
M src/builtins/mips64/builtins-mips64.cc
M src/codegen/loong64/macro-assembler-loong64.cc
M src/codegen/loong64/macro-assembler-loong64.h
M src/codegen/mips64/macro-assembler-mips64.cc
M src/codegen/mips64/macro-assembler-mips64.h
M src/compiler/backend/loong64/code-generator-loong64.cc
M src/compiler/backend/loong64/instruction-selector-loong64.cc
M src/compiler/backend/mips64/code-generator-mips64.cc
M src/compiler/backend/mips64/instruction-selector-mips64.cc
10 files changed, 62 insertions(+), 27 deletions(-)
To view, visit change 4740420. To unsubscribe, or for help writing mail filters, visit settings.
Liu Yu (Gerrit)
Attention is currently required from: Zhao Jiazhong.
Patch set 1:Auto-Submit +1
Liu Yu (Gerrit)
Attention is currently required from: Zhao Jiazhong.
Liu Yu has uploaded this change for review.
[loong64][mips64][sandbox] Reference Code objects (and their entrypoint) through the CPT
Port commit fbb9df7218ae348b56104ff8fdd82b578e42d189
Bug: chromium:1395058
Change-Id: I3edbc161ac9d30378ac7e6ad6850f2ae13208623
---
M src/builtins/loong64/builtins-loong64.cc
M src/builtins/mips64/builtins-mips64.cc
M src/codegen/loong64/macro-assembler-loong64.cc
M src/codegen/loong64/macro-assembler-loong64.h
M src/codegen/mips64/macro-assembler-mips64.cc
M src/codegen/mips64/macro-assembler-mips64.h
M src/compiler/backend/loong64/code-generator-loong64.cc
M src/compiler/backend/loong64/instruction-selector-loong64.cc
M src/compiler/backend/mips64/code-generator-mips64.cc
M src/compiler/backend/mips64/instruction-selector-mips64.cc
10 files changed, 62 insertions(+), 27 deletions(-)
To view, visit change 4740420. To unsubscribe, or for help writing mail filters, visit settings.
Zhao Jiazhong (Gerrit)
V8 LUCI CQ (Gerrit)
V8 LUCI CQ submitted this change.
[loong64][mips64][sandbox] Reference Code objects (and their entrypoint) through the CPT
Port commit fbb9df7218ae348b56104ff8fdd82b578e42d189
Bug: chromium:1395058
Change-Id: I3edbc161ac9d30378ac7e6ad6850f2ae13208623
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4740420
Reviewed-by: Zhao Jiazhong <zhaojia...@loongson.cn>
Auto-Submit: Liu Yu <li...@loongson.cn>
Commit-Queue: Zhao Jiazhong <zhaojia...@loongson.cn>
Cr-Commit-Position: refs/heads/main@{#89302}
---
M src/builtins/loong64/builtins-loong64.cc
M src/builtins/mips64/builtins-mips64.cc
M src/codegen/loong64/macro-assembler-loong64.cc
M src/codegen/loong64/macro-assembler-loong64.h
M src/codegen/mips64/macro-assembler-mips64.cc
M src/codegen/mips64/macro-assembler-mips64.h
M src/compiler/backend/loong64/code-generator-loong64.cc
M src/compiler/backend/loong64/instruction-selector-loong64.cc
M src/compiler/backend/mips64/code-generator-mips64.cc
M src/compiler/backend/mips64/instruction-selector-mips64.cc
10 files changed, 62 insertions(+), 27 deletions(-)
Yahan Lu (Gerrit)
Yahan Lu uploaded patch set #2 to this change.
[riscv][sandbox] Reference Code objects (and their entrypoint) through the CPT
Port commit fbb9df7218ae348b56104ff8fdd82b578e42d189
Bug: chromium:1395058
Change-Id: Ie4b7feb6157ed3846a743d4ef1e2adcfdc522f30
---
M src/builtins/riscv/builtins-riscv.cc
M src/codegen/riscv/macro-assembler-riscv.cc
M src/codegen/riscv/macro-assembler-riscv.h
M src/compiler/backend/riscv/code-generator-riscv.cc
M src/compiler/backend/riscv/instruction-codes-riscv.h
M src/compiler/backend/riscv/instruction-scheduler-riscv.cc
M src/compiler/backend/riscv/instruction-selector-riscv.h
M src/compiler/backend/riscv/instruction-selector-riscv64.cc
M test/cctest/test-helper-riscv32.cc
M test/cctest/test-helper-riscv32.h
M test/cctest/test-helper-riscv64.cc
M test/cctest/test-helper-riscv64.h
M test/cctest/test-macro-assembler-riscv32.cc
M test/cctest/test-macro-assembler-riscv64.cc
M test/cctest/test-simple-riscv32.cc
M test/cctest/test-simple-riscv64.cc
16 files changed, 141 insertions(+), 74 deletions(-)
To view, visit change 4750761. To unsubscribe, or for help writing mail filters, visit settings.
Yahan Lu (Gerrit)
Yahan Lu uploaded patch set #3 to this change.
[riscv][sandbox] Reference Code objects (and their entrypoint) through the CPT
Also port Make Object methods static
Port commit fbb9df7218ae348b56104ff8fdd82b578e42d189
Port commit f20f342a3e275ae6442a53e34869f1c90f0db4a0
Bug: chromium:1395058
Bug: v8:12710
Yahan Lu (Gerrit)
Attention is currently required from: Ji Qiu.
Yahan Lu would like Ji Qiu to review this change.
16 files changed, 166 insertions(+), 77 deletions(-)
Ji Qiu (Gerrit)
Attention is currently required from: Ji Qiu, Yahan Lu.
Ji Qiu uploaded patch set #5 to the change originally created by Yahan Lu.
The following approvals got outdated and were removed: Commit-Queue+1 by Yahan Lu
[riscv][sandbox] Reference Code objects (and their entrypoint) through the CPT
Also port:
[riscv][tagged-ptr] Make Object methods static
Port commit fbb9df7218ae348b56104ff8fdd82b578e42d189
Port commit f20f342a3e275ae6442a53e34869f1c90f0db4a0
Bug: chromium:1395058
Bug: v8:12710
Change-Id: Ie4b7feb6157ed3846a743d4ef1e2adcfdc522f30
---
M src/builtins/riscv/builtins-riscv.cc
M src/codegen/riscv/macro-assembler-riscv.cc
M src/codegen/riscv/macro-assembler-riscv.h
M src/compiler/backend/riscv/code-generator-riscv.cc
M src/compiler/backend/riscv/instruction-codes-riscv.h
M src/compiler/backend/riscv/instruction-scheduler-riscv.cc
M src/compiler/backend/riscv/instruction-selector-riscv.h
M src/compiler/backend/riscv/instruction-selector-riscv64.cc
M test/cctest/test-helper-riscv32.cc
M test/cctest/test-helper-riscv32.h
M test/cctest/test-helper-riscv64.cc
M test/cctest/test-helper-riscv64.h
M test/cctest/test-macro-assembler-riscv32.cc
M test/cctest/test-macro-assembler-riscv64.cc
M test/cctest/test-simple-riscv32.cc
M test/cctest/test-simple-riscv64.cc
16 files changed, 166 insertions(+), 77 deletions(-)
To view, visit change 4750761. To unsubscribe, or for help writing mail filters, visit settings.
Ji Qiu (Gerrit)
Attention is currently required from: Yahan Lu.
Patch set 5:Code-Review +1Commit-Queue +2
To view, visit change 4750761. To unsubscribe, or for help writing mail filters, visit settings.
Yahan Lu (Gerrit)
Attention is currently required from: Ji Qiu, Yahan Lu.
Yahan Lu uploaded patch set #6 to this change.
[riscv][sandbox] Reference Code objects (and their entrypoint) through the CPT
To view, visit change 4750761. To unsubscribe, or for help writing mail filters, visit settings.
Yahan Lu (Gerrit)
Attention is currently required from: Ji Qiu, Yahan Lu.
Patch set 6:Commit-Queue +2
Yahan Lu (Gerrit)
Attention is currently required from: Ji Qiu.
Patch set 6:Auto-Submit +1
V8 LUCI CQ (Gerrit)
V8 LUCI CQ submitted this change.
5 is the latest approved patch-set.
No files were changed between the latest approved patch-set and the submitted one.
[riscv][sandbox] Reference Code objects (and their entrypoint) through the CPT
Also port: [riscv][tagged-ptr] Make Object methods static
Port commit fbb9df7218ae348b56104ff8fdd82b578e42d189
Port commit f20f342a3e275ae6442a53e34869f1c90f0db4a0
Bug: chromium:1395058
Bug: v8:12710
Change-Id: Ie4b7feb6157ed3846a743d4ef1e2adcfdc522f30
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4750761
Auto-Submit: Yahan Lu <ya...@iscas.ac.cn>
Reviewed-by: Ji Qiu <qi...@iscas.ac.cn>
Commit-Queue: Yahan Lu <ya...@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#89388}
---
M src/builtins/riscv/builtins-riscv.cc
M src/codegen/riscv/macro-assembler-riscv.cc
M src/codegen/riscv/macro-assembler-riscv.h
M src/compiler/backend/riscv/code-generator-riscv.cc
M src/compiler/backend/riscv/instruction-codes-riscv.h
M src/compiler/backend/riscv/instruction-scheduler-riscv.cc
M src/compiler/backend/riscv/instruction-selector-riscv.h
M src/compiler/backend/riscv/instruction-selector-riscv64.cc
M test/cctest/test-helper-riscv32.cc
M test/cctest/test-helper-riscv32.h
M test/cctest/test-helper-riscv64.cc
M test/cctest/test-helper-riscv64.h
M test/cctest/test-macro-assembler-riscv32.cc
M test/cctest/test-macro-assembler-riscv64.cc
M test/cctest/test-simple-riscv32.cc
M test/cctest/test-simple-riscv64.cc
16 files changed, 166 insertions(+), 77 deletions(-)
Ji Qiu (Gerrit)
Samuel Groß has uploaded this change for review.
[sandbox] Reference Code objects (and their entrypoint) through the CPT
109 files changed, 1,812 insertions(+), 376 deletions(-)
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Ji Qiu (Gerrit)
1 comment:
Patchset:
Hi there,
Both @ya...@iscas.ac.cn and I don't have permission the according issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1395058. Would you help us to unlock it? Thank you!
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.
Samuel Groß (Gerrit)
1 comment:
Patchset:
Hi there, […]
Hi! I've derestricted the issue, so you should be able to access it now.
To view, visit change 4628448. To unsubscribe, or for help writing mail filters, visit settings.