Length-prefix recursive types in the type section

Ouverte
  • Quelque chose ne va pas ?
#732 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 4 jours

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
wasm
Domaine
compilers

Piste de recherche

Start by reviewing the recursive type grammar described in the issue and wasm-tools pull request #2686, which provides context on parser stack-overflow handling. Determine whether a length-prefixed encoding is appropriate for the component and instance type sections, and document the proposed 1.0 binary-format change and its compatibility implications.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

pre-1.0

Currently the binary format for component and instance types is self-recursive, for example:

type          ::= dt:<deftype>
deftype       ::= ...
                | ct:<componenttype>
componenttype ::= 0x41 cd*:vec(<componentdecl>)
componentdecl ::= ...
                | id:<instancedecl>
instancedecl  ::= ...
                | 0x01 t:<type>

This recursive nature already needs to be handled by validators but the binary format here means that even just component parsers need to be hardened against this sort of binary format. For example in wasm-tools https://github.com/bytecodealliance/wasm-tools/pull/2686 was a bugfix which adds extra logic to the parser to ensure that stack-overflow doesn't happen on the host where parsers are currently written as recursive-descent parsing.

Elsewhere in wasmparser and wasm's binary format this is often a use case for length-prefixed portions of the binary. For example if a component or instance type were prefixed by not only their numeric item length but also the byte size in the type section it would enable parsers to more efficiently model this as a not-recursive case. Parsing a component type would then yield "here's a chunk of bytes that's supposed to be a component" without actually parsing anything. The caller would then have to parse those bytes itself, but this inverts the control flow a bit where the caller/embedder is now in control of recursion instead of that having to happen internally.

I realize though that this is a breaking change to the binary format so not something we can do in the near-term. Otherwise though I was thinking that this might be a good 1.0-style binary tweak to make it a bit easier on parsers.

Langage dominant
WebAssembly
Étoiles
1.4k
Forks
132
Merge moyen
4 j 14 h
PR mergées (30 j)
12

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de WebAssembly/component-model

Toutes les issues de WebAssembly/component-model

Issues similaires

Plus d'issues Compilers

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.