[llvm-dev] Wasm, start function, and default globals

Petr Penzin via llvm-dev llvm-dev at lists.llvm.org
Tue Oct 15 18:11:13 PDT 2019


There is a good amount of expertise on this in Emscripten community: 
https://github.com/emscripten-core/emscripten

You can also try to ask in one of the WebAssembly repos: 
https://github.com/WebAssembly

I think Luke Imhoff has done some work accessing the start function, I 
am not sure if he is on this list. I personally don't know of a way 
write to start function. There is a bit on it in tool conventions:

https://github.com/WebAssembly/tool-conventions/blob/master/Linking.md#start-section

The __heap_base symbol is there because Wasm does not have the memory 
layout C family languages expect. At higher opt level Clang is usually 
pretty good at removing its use.

Best,

Petr

On 10/15/19 4:50 PM, Bill Ticehurst via llvm-dev wrote:
>
> Apologies if there is a better forum for these questions. Please 
> redirect me if so.
>
> I’ve been using the clang/wasm-ld tools to experiment with some basic 
> examples, and there’s a couple things I’m wrestling with.
>
> 1) How to denote a function as the “start” function 
> (https://webassembly.github.io/spec/core/binary/modules.html#start-section)
>
> 2) How to avoid the defaulted __heap_base global.
>
> I’ve dug around on the samples, mailing lists, and in the wasm-ld code 
> for an attribute or flag to specify the start function, but don’t see 
> anything. Is this just not implemented (or tracked) yet?
>
> For 2), I always see the below global in the compiled output even with 
> the most trivial code that makes no reference to it (e.g. compiling 
> just a simple function that only references values on the implicit 
> operand stack).
>
> (global (;0;) (mut i32) (i32.const 66560))
>
> Per https://dassur.ma/things/c-to-webassembly/, looks like this is the 
> __heap_base value implicitly provided for modeling the stack/heap as 
> are usually present in most C/C++ environments, even though unused in 
> my compiled output. Is this something that could/should be optimized 
> away, but again just isn’t implemented yet? Any way to suppress this 
> building with the current clang/wasm-ld toolchain?
>
> Thanks,
>
>   * Bill
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
> Windows 10
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191015/72585a9a/attachment.html>


More information about the llvm-dev mailing list