forc test single-step until jump point instead of patching binary

[xunilrj]

Description

Fixes #6720.

Since configurables started to use encoding v1, it is not possible to use configurables inside tests, because forc test patches the binary forcing a jump into the test function before configurables are initialized.

This PR fixes this changing the approach from patching the binary, to single-stepping the initialization and them manually changing the PC register to the first instruction of the test.

Performance is acceptable, a test with a lot of configurables takes 572.382µs.

Checklist

• I have linked to any relevant issues.
• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation where relevant (API docs, the reference, and the Sway book).
  • If my change requires substantial documentation changes, I have requested support from the DevRel team
• I have added tests that prove my fix is effective or that my feature works.
• I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
• I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
• I have requested a review from the relevant team or maintainers.

[JoshuaBatty]

Nice, thanks for doing this!

[JoshuaBatty]

Everything looks pretty reasonable here to me. Will defer to @kayagokalp for a review though

[kayagokalp]

Hey there, thanks a lot for the PR! I'll be checking it next thing in the morning 🙌

[kayagokalp]

Looks good to me! Thanks again.

Just for me to understand the choices behind the implementation better I have a question. With recent changes being done in the emitted metadata for @sdankel's work (to remove configurable for ABI uploads), I believe we have the information where the configurable section ends(?) So instead of single stepping in the vm could we use that information and add the jump instruction after that offset? (This is not to argue that is a better choice but for me to understand what exactly was the problem)

As far as I can see the problem was: we had the jmp instruction patched to the beginning of the bytecode, before configurable initialization, which was causing configurables not being available to tests.

Or am I interpreting the reason of single stepping wrong?

[xunilrj]

As far as I can see the problem was: we had the jmp instruction patched to the beginning of the bytecode, before configurable initialization, which was causing configurables not being available to tests.

Yes. Correct.

I believe we have the information where the configurable section ends(?)

At the beginning of the binary we have where the "encoded values" of the configurables are, but we do not have where the initialization of configurables starts and ends.

And there is not guarantee that there is "space" between the configurable end and the rest of the binary to overwrite with the necessary jump. For scrips/contracts and predicates using encoding v1, the first function is the "__entry" function, and we can overwrite is prologue, as it is not going to be called.

But for libraries, there is no configurable initialization, but there is also no "spare" instruction to use. As after the initialization, the first instruction is the first function prologue, and we cannot overwrite it, as it can be called.

For example:

library;

fn f() {

}

#[test]
fn ff() {
    f();
}

Generates:

0x00000000 MOVE R60 $pc                                    ;; [26, 240, 48, 0]
0x00000004 JMPF $zero 0x2                                  ;; [116, 0, 0, 2]
0x00000008                                                 ;; [0, 0, 0, 0, 0, 0, 0, 32]
0x00000010 LW R63 R60 0x1                                  ;; [93, 255, 192, 1]
0x00000014 ADD R63 R63 R60                                 ;; [16, 255, 255, 0]
0x00000018 MOVE R59 $sp                                    ;; [26, 236, 80, 0]
0x0000001c RET $zero                                       ;; [36, 0, 0, 0]

There is no "spare" instruction between 0x00000014 and 0x00000018 that we can replace. That is why I think single-stepping (or a breakpoint) are better solutions for the moment.

[kayagokalp]

As far as I can see the problem was: we had the jmp instruction patched to the beginning of the bytecode, before configurable initialization, which was causing configurables not being available to tests.

Yes. Correct.

I believe we have the information where the configurable section ends(?)

At the beginning of the binary we have where the "encoded values" of the configurables are, but we do not have where the initialization of configurables starts and ends.

And there is not guarantee that there is "space" between the configurable end and the rest of the binary to overwrite with the necessary jump. For scrips/contracts and predicates using encoding v1, the first function is the "__entry" function, and we can overwrite is prologue, as it is not going to be called.

But for libraries, there is no configurable initialization, but there is also no "spare" instruction to use. As after the initialization, the first instruction is the first function prologue, and we cannot overwrite it, as it can be called.

For example:

library;



fn f() {



}



#[test]

fn ff() {

    f();

}

Generates:

0x00000000 MOVE R60 $pc                                    ;; [26, 240, 48, 0]

0x00000004 JMPF $zero 0x2                                  ;; [116, 0, 0, 2]

0x00000008                                                 ;; [0, 0, 0, 0, 0, 0, 0, 32]

0x00000010 LW R63 R60 0x1                                  ;; [93, 255, 192, 1]

0x00000014 ADD R63 R63 R60                                 ;; [16, 255, 255, 0]

0x00000018 MOVE R59 $sp                                    ;; [26, 236, 80, 0]

0x0000001c RET $zero                                       ;; [36, 0, 0, 0]

There is no "spare" instruction between 0x00000014 and 0x00000018 that we can replace. That is why I think single-stepping (or a breakpoint) are better solutions for the moment.

Oh I see, that is nice. Thanks for the great explanation