Repository navigation
Fuzzer: Respect the noInvokes flag when adding interposing invokes - #9221
Conversation
Liedtke
left a comment
There was a problem hiding this comment.
Yes, this is the interpose call I was referring to in http://crbug.com/561837951#comment18, LGTM, so with this PR, #9214 and #9212 we should have addressed the 3 issues raised in that comment (roman I - III) IIUC. Thanks!
So on Fuzzilli side we'll need to simply add --fuzz-hang-limit=0 --fuzz-no-invokes to "materialize" these changes, is that correct?
|
As a side note, it might still be interesting to consider my proposal for the case when not calling
I didn't check the order, so without repeated calls to the fuzzer this might never emit a call to its invoker (if the invoker is added after emitting the interpose call) but it might still emit a call to itself which is placed in the very beginning of the function after the hang limit check, so it will build a recursion that only executes fuzzer instrumentation but no random code when ending up recursively calling itself, so filtering out itself as a potential call target would make sense? |
|
Yes, About the ordering, I'm not sure, but I think we have logic to randomize the order. We generate functions and mutate them in random order, that is, to increase the chance for calls from anywhere to anywhere. What I am not sure if the interposition fits in there perfectly, I'll check. |
noInvokes already stopped us from emitting new invokes. We also emit
calls to invokes, basically adding more invoke executions, by "interposing"
on exports - sticking a call in an export, where the call is to an invoke.
Respect the flag in that case too: if the user doesn't want the code growth
of invokes, they don't want either new invokes or new calls to existing
invokes.
Diff without whitespace is small (almost all comments).
cc @Liedtke