debug memory replay tests #1473
Conversation
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
…t activated Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
Signed-off-by: F Bojarski <[email protected]>
letypequividelespoubelles
requested review from
OlivierBBB and
lorenzogentile404
| int stackLineCounter, | ||
| int nonStackLineCounter, | ||
| int mmuStamp, | ||
| int mxpStamp) { | ||
| this.commonFragmentValues = commonValues; | ||
| this.twoLineInstructionCounter = stackLineCounter == 1; | ||
| this.nonStackRowsCounter = nonStackLineCounter; |
There was a problem hiding this comment.
We should homogenize the names. In the spec it's NON_STACK_ROWS or NSR.
| @@ -47,7 +47,7 @@ public class CommonFragmentValues { | |||
| public final HubProcessingPhase hubProcessingPhase; | |||
| public final int hubStamp; | |||
| public final CallStack callStack; | |||
| public final State.TxState.Stamps stamps; // for MMU and MXP stamps | |||
| public final State.TxState.Stamps stamps; | |||
There was a problem hiding this comment.
You provide the mmuStamp and mxpStamp separately in the CommonValuesFragment constructor. Are the State.TxState.Stamps dysfunctional ?
There was a problem hiding this comment.
There was a problem hiding this comment.
Was this instruction missing altogether ?
There was a problem hiding this comment.
no, it was in the CallDataLoadSection. But it was missing the postExecutiondefers to get the stack item directly from Besu
| public Optional<Bytes> exoBytes() { | ||
| return exoIsRom ? Optional.of(hub.romLex().getCodeByMetadata(contract)) : Optional.empty(); | ||
| } | ||
|
|
There was a problem hiding this comment.
Was this grabbing the currently executing bytecode in stead ?
There was a problem hiding this comment.
No, this was working well, except when the ROM is not set (ie in the case failure CREATE2), because we weren't able to get the initCode to hash in this case
| @@ -62,47 +63,45 @@ public StackRamSection(Hub hub) { | |||
| // the unexceptional case | |||
| checkArgument(Exceptions.none(exceptions)); | |||
|
|
|||
| final EWord offset = EWord.of(hub.currentFrame().frame().getStackItem(0)); | |||
| final CallFrame currentFrame = hub.currentFrame(); | |||
There was a problem hiding this comment.
I've never been a fan of the currentFrame terminology since we have two kinds of frames: CallFrame's and MessageFrame's. Maybe we can rename it to simply callFrame ?
| .limb1(value.hi()) | ||
| .limb2(value.lo()) | ||
| .sourceRamBytes(Optional.of(currentRam)); | ||
|
|
There was a problem hiding this comment.
This block is just formatting, right ?
| @@ -96,6 +96,8 @@ public PrecompileSubsection(final Hub hub, final CallSection callSection) { | |||
| this.callSection = callSection; | |||
| fragments = new ArrayList<>(maxNumberOfLines()); | |||
|
|
|||
| final MessageFrame messageFrame = hub.messageFrame(); | |||
|
|
|||
There was a problem hiding this comment.
I have a very general comment: XxxSection's, with the exception of prewarming, initialization, finalization and skipping sections I believe, are all generated in the traceOpcode method of the hub. This method has as its input a (Besu) MessageFrame. This message frame is always "the right one". We also have the message frame in the hub's callFrame. So the question is: can and should we ax CallFrame.messageFrame in favour of always using the <tracing method> provided MessageFrame ?
Reasons for doing so: avoid synchronization issues. Kind of like the one we had wrt traceEndTransaction, where the worldUpdater of the HUB, which was implicitly used in the canonical AccountSnapshot constructor, was out of date and we should have been using the Besu provided one.
No description provided.