PrintBoundary pass, emitting a JSON summary of the API boundary of the module#8703
Conversation
| item["name"] = json::Value::make(exp->name.view()); | ||
| item["kind"] = getKindName(exp->kind); | ||
| item["type"] = | ||
| getExternalType(exp->kind, *exp->getInternalName(), *module); |
There was a problem hiding this comment.
It looks like this won't work for exported heap types... but I don't remember why Export even supports holding a HeapType given that we have no ExternalKind for heap types. Do you remember the context around #7335?
There was a problem hiding this comment.
Wasn't the context, as mentioned there, preparation for type exports..? I feel I am not understanding your question, sorry.
There was a problem hiding this comment.
Yeah, but why were we preparing for type exports? It doesn't look like anything else has changed to support them since then.
There was a problem hiding this comment.
Looks like it's at stage 1 still, I guess nothing changed because it isn't urgent for anything?
| ;; CHECK-NEXT: "params": [ | ||
| ;; CHECK-NEXT: "(ref $struct.0)" | ||
| ;; CHECK-NEXT: ], | ||
| ;; CHECK-NEXT: "results": [ | ||
| ;; CHECK-NEXT: "i32", | ||
| ;; CHECK-NEXT: "i32", | ||
| ;; CHECK-NEXT: "i32" | ||
| ;; CHECK-NEXT: ] |
There was a problem hiding this comment.
Maybe we should just print the number of params and results instead of their types, since non-abstract reference types will not be meaningful to consumers of this json. It sounds like Fuzzilli will not use more than the arity anyway.
An alternative that doesn't go so far would be to print the top reference type so the consumer can at least determine what reference type hierarchy the parameter or result is in.
There was a problem hiding this comment.
I would like Fuzzilli to do more than the arity, though (eventually). It would make sense to send references to reference params, for example, reducing the odds of immediate traps that make testcases useless. More specifically, even, when Fuzzilli sees a ref $A is sent out one place, then it could send it back in to another that receives ref $A.
| ;; CHECK-NEXT: "type": [ | ||
| ;; CHECK-NEXT: "i32" | ||
| ;; CHECK-NEXT: ] |
There was a problem hiding this comment.
I wonder what happens if you try to emit a binary with an imported or exported tuple global. That shouldn't work because such globals do not exist in WebAssembly, so there should be no situations in which the consumer of this information can actually observe multiple values here. We can probably just emit a single type here instead of a list.
There was a problem hiding this comment.
We disallow exporting/importing multivalue globals (validation fails).
I agree it is nicer to not emit a list when not needed, done.
|
Looks great! The json files looks exactly like what we need on Fuzzilli part. Thanks Alon for quickly adding this functionality. |
|
Great! Landing. |
3 participants
cc @tlively @rmahdav @Liedtke - does this look like what we want? (see test for concrete example)