feature/label statement

[Yi2255]

It seems that the current version of Fuzzilli lacks code generation for label statement. Its specification ref MDN. This PR aims to support the related features.

The logic implemented is：

1. Add three operations, i.e. loopLabelBreak, loopLabelContinue,loadLabel, to support label statement.
2. A label generation statement, i.e. loadLabel operation, randomly inserted just above every loop structures. This approach is taken because I found that using existing context mechanism cannot achieve this specific generation position. For example,

outerLoop: 
for (let i = 0; i < 3; i++) {
    console.log(`Label: outerLoop, Iteration: ${i}`);
}

3. Due to the nested structure of loops, labels are implemented with a stack-like mechanism. When entering a loop, the generated label is pushed onto the stack, and when the loop ends, the label is popped from the stack. This ensures that break and continue statements can find the appropriate label operation in the current stack.

My concerns are as follows, and I would appreciate any corrections:

• The implementation of the label stack seems to be somewhat non-standard.
• This is my first time implementing a complete JSOperation from scratch, and I'm unsure if there are any parts of the code that I may have missed or not properly modified.

Thanks a lot!

[saelo]

Thanks! @vi3tL0u1s @Yi2255 Is #476 a superset of this PR as it also adds support in the JS -> FuzzIL compiler? I don't have a strong preference for which PR to review, but if #476 is more feature complete, I'd go for that one?

[Yi2255]

We have merged #476 into this PR, and now this PR (#467) can support label statement in both the JsOperation and the JS -> FuzzIL compiler. So I think you could review this PR. Thanks so much!

[saelo]

Thanks for working on this, this is really cool!

So some high-level comments. I think the current approach won't work well with our mutation engine. IIUC, we rely on the LoadLabel and LabelContinue and LabelBreak to get the same input variable, and on that being a string. However, we can no longer guarantee that as soon as our mutation engine kicks in (and changes inputs, or splices code, etc.). We would quickly get something like

v0 <- BeginFunctionDefinition
...
EndFunctionDefinition
LoopLabel v0
BeginWhileLoop
    v3 <- CallFunction v1
    LoopBreak v3
EndWhileLoop

Which we can't even properly lift anymore, so we'll generate invalid JS syntax, and that's one thing we try hard to avoid. I also think that something like

foo: <whatever>

while (true) {
    break foo;
}

Is already a SyntaxError, and those are really bad because they can't be avoided with a try-catch and nothing will be executed at all. So we need to avoid that. On the other hand, it would be nice if we could also support something like

foo: if (true) {
    while (true) {
         break foo;
    }
}

I.e. creating labels for things other than loops.

Finally, for fuzzing efficiency, it would be good to avoid "indirect" dependencies where e.g. a BreakLabel "foo" operation only works if we also had a CreateLabel "foo" operation prior to that (the indirect dependency here being the string "foo" that both would need to use). Those are generally tricky because mutating the code will quickly break them.

So overall, I'm wondering if we just want something like this instead:

BeginIf X
    BeginWhileLoop
        ....
        BreakNested 2
    EndWhileLoop
EndIf

So we'd only add two new instructions: BreakNested <depth> and ContinueNested <depth>. We'd then allow <depth> to be too large, in which case we could just use depth % actual_block_depth as the real depth. And then we'd have to autogenerate the labels when necessary during lifting. I think for fuzzing efficiency, this will be optimal because we will always generate syntactically valid code and will only emit labels when necessary. The complexity then lies in the lifter, which needs to figure out where to place labels. For that, it would probably need to build up some helper datastructure that records all valid continue/break targets (BeginIf, BeginXYZLoop, BeginBlock, maybe some more?) and keeps track of the current depth at each point in time, then figures out where each BreakNested and ContinueNested goes, and then generates the labels (e.g. just label1: , label2: etc.) as necessary.

So the lifting will become somewhat complicated. But I think that's ok. In general, in Fuzzilli we prefer "local" complexity (e.g. in the Lifter) over "global" complexity (where multiple different parts of the engine have to work together for something to work).

WDYT? Would this work, and would this also work for the Compiler?

[saelo]

Nit: should this be while (true), otherwise we'll anyway only run once?

[Yi2255]

Hi saelo, according to your feedback, I reimplemented the feature of the label statement under the context of loop structure. The new PR #479 outlines the design approach.
If there are any issues, please point out so we can address them. Thanks a lot!

[saelo]

Maybe also add some tests with nested loops where we break out of two or more loops?

[saelo]

Maybe also something like

ifLabel: if (true) {
    loopLabel: while (true) {
        break ifLabel;
    }
    console.log("Never reached");
}

But it'll of course depend on whether we can support this type of code.

[saelo]

Thanks for adding these tests, that's great! I think it would also be good to add some LifterTests.