Skip to content

Support type use before definition in binaries - #3588

Merged
tlively merged 3 commits into
WebAssembly:mainfrom
tlively:forward-declared-binary
Feb 19, 2021
Merged

tlively merged 3 commits into
WebAssembly:mainfrom
tlively:forward-declared-binary

Conversation

@tlively

@tlively tlively commented Feb 19, 2021

Copy link
Copy Markdown
Member

Update parsing of binary type sections to use TypeBuilder to support uses before
definitions. Now that both the binary and text parsers support out-of-order type
uses, this PR also relaxes the logic for emitting types to allow uses to be
emitted before definitions.

Update parsing of binary type sections to use TypeBuilder to support uses before
definitions. Now that both the binary and text parsers support out-of-order type
uses, this PR also relaxes the logic for emitting types to allow uses to be
emitted before definitions.
@tlively
tlively requested a review from kripken February 19, 2021 09:00

@kripken kripken left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

lgtm aside from the one question.

Comment thread src/wasm-type.h Outdated
data,
};
static constexpr BasicHeapType _last_basic_type = data;
static constexpr uintptr_t _invalid_type = -1;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not 0? (is -1 guaranteed to segfault on use like 0 is?)

@kripken kripken Feb 19, 2021 •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, is this needed? It would be better to avoid allowing an invalid HeapType at all. It seems like getBasicHeapType returns a boolean already, so we know if a value was found or not. Given that, the HeapType could be initialized to a valid value (say, anyref, doesn't matter) before the call? (There is a risk to doing that as well, but with a good comment there I think it's less risky than a general change to allow invalid HeapTypes to be declared as easily as HeapType bad;).

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I can have the default constructor just choose an arbitrary BasicHeapType. FWIW, address -1 should segfault on all reasonable platforms (as long as you're not in kernel mode or in WebAssembly or something 😉).

@kripken

kripken commented Feb 19, 2021

Copy link
Copy Markdown
Member

Side note, @jakobkummerow and I happened to look at a wasm file with recursive types now (testcase for the names section), and I noticed that it crashes with this PR,

==580908== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==580908== 
==580908== Process terminating with default action of signal 11 (SIGSEGV)
==580908==  Access not within mapped region at address 0x1FFE801FF0
==580908== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==580908==    at 0x507BBEC: std::_Function_handler<void (unsigned long), wasm::(anonymous namespace)::Canonicalizer::getOrderedItems()::{lambda(unsigned long)#1}>::_M_invoke(std::_Any_data const&, unsigned long&&) (in /home/azakai/Dev/2-binaryen/lib/libbinaryen.so)

(Infinite recursion?)

That wasm has something like this:

// type 0: struct $StrA (field ($byte i8) ($word i16) ($pointer (ref $StrB)))
// type 1: struct $StrB (field ($next (ref null $StrA)))

name-section.wasm.gz

@tlively

tlively commented Feb 19, 2021 •

Copy link
Copy Markdown
Member Author

Yeah there are going to be lots of infinite recursions for recursive types right now, but I'm surprised that this didn't trigger an assertion in the TypeBuilder first.

@tlively
tlively merged commit 611e6de into WebAssembly:main Feb 19, 2021
@tlively
tlively deleted the forward-declared-binary branch February 19, 2021 21:44
@tlively tlively mentioned this pull request Feb 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants