Stream: wasm

Topic: heap base alignment


view this post on Zulip Stephan Renatus (Jul 19 2021 at 12:27):

Using stack-first with an llvm-emitted wasm module, I'm appending some data segments when post-processing the module. I'll thus have to adjust the memory location to be used for heap_base, and I'm wondering if it should be aligned to (a) a page or (b) a multiple of 16 or (c) nothing at all. I wasn't able to answer this myself, I'm afraid :|

view this post on Zulip Alex Crichton (Jul 19 2021 at 14:07):

nothing in the module itself uses that exported variable, so unless you've got other tooling relying on it then it should be fine to just remove it.

view this post on Zulip Stephan Renatus (Jul 19 2021 at 19:24):

ah, thanks. we've got a little malloc implementation using it as the starting point for its allocations. so, I guess it doesn't matter then. (if the implementation using it, uhm, doesn't care about alignment...)

view this post on Zulip Stephan Renatus (Jul 20 2021 at 20:04):

on a related note, using llvm, would you know if the stack pointer (mutable) global is something I could "move" a bit back in the start function?

view this post on Zulip Alex Crichton (Jul 20 2021 at 20:43):

@Stephan Renatus by move back do you mean move down? (in that the stack grows down)

view this post on Zulip fitzgen (he/him) (Jul 20 2021 at 21:34):

if you want more shadow stack, I'd suggest configuring that via linker flags at compile time rather than dynamically nudging it at runtime and potentially overwriting other data

view this post on Zulip Stephan Renatus (Jul 21 2021 at 07:21):

by move back do you mean move down?

I was thinking about back as in "higher up" so that it gets more space to grow down

I'd suggest configuring that via linker flags at compile time

yeah I'd prefer that :smiling_face: but we're messing with the wasm module emitted by llvm, adding further data segments. I believe if we don't adapt the heap_base/sp location, the effectively usable stack (before it's overwriting static data) will be smaller than what we're passing to wasm-ld.

view this post on Zulip Stephan Renatus (Jul 21 2021 at 07:27):

obviously it would be much cleaner if our compiler emitted a relocatable object instead and we could use wasm-ld from there.... I've never driven llvm from go, though. (and calling an external binary is out of the question)

view this post on Zulip Alex Crichton (Jul 21 2021 at 17:21):

hm ok in that case I'd be less certain myself, I don't know enough about LLD's layout and its options to know whether this is safe or not

view this post on Zulip Stephan Renatus (Jul 21 2021 at 19:26):

yeah, we're avoiding this for now. the plan is to keep rolling with the default until we know of a case where it's insufficient... thanks for your inputs! :)


Last updated: Dec 23 2024 at 12:05 UTC