[wasm] Fix crash serializing modules w/ big frames
When a wasm function has a large stack frame, the x64 code generator performs the stack overflow check before constructing the frame. This requires using the `address_of_real_stack_limit` external reference, as well as the `ThrowWasmStackOverflow` runtime function. `ThrowWasmStackOverflow` is called via a generated trampoline, but it is not a builtin, so the serializer adds it to the `stub_lookup_` map. This map is encoded by using a monotonically increasing `stub_id` that starts at 0. When the function is serialized, a stub is differentiated from a builtin by which half of the `i32` bits is used, upper or lower. A stub only uses the lower 16 bits and a builtin only uses the upper 16 bits. The deserializer checks whether the lower 16 bits are 0; if so, it is determined to be a builtin. But if the `stub_id` is 0, then it will be confused with builtin 0 (`RecordWrite`). Calling the builtin instead of the stub causes a crash. This CL starts all `stub_id`s at 1, which prevents the builtin/stub confusion. There is an additional bug that is not fixed by this CL: `ThrowWasmStackOverflow` shouldn't be called at all. Currently it is called because `address_of_real_stack_limit` is a thread-local value that is not properly relocated. Bug: chromium:808848 Change-Id: I06b3e650ea58ad717dcc47a3716443e16582e711 Reviewed-on: https://chromium-review.googlesource.com/981687Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Ben Smith <binji@chromium.org> Cr-Commit-Position: refs/heads/master@{#52252}
Showing
Please
register
or
sign in
to comment