[PATCH] D42030: [WebAssembly] Define __heap_base global

[Sam Clegg via Phabricator via llvm-commits]

sbc100 added a comment.

In https://reviews.llvm.org/D42030#979606, @dschuff wrote:

> > I don't see that. How the underlying system allocates memory, and how it's split up for application use, don't have to relate at all. Exactly the same reasoning would say, "well x86 uses 4K pages so it doesn't make sense for malloc to subdivide that for a 10-byte allocation". I do agree though that it's odd/unusual and also awkward for mmap not to reflect the kernel's page size - but odd doesn't make it wrong, or inefficient.
>
> I guess I am sort of just being pedantic here.  The purpose of the mmap syscall is to change the mappings in the address space, and it exposes the kernel's page size based on how it rounds the addresses (and in some cases requires the user to round their requests to page size). It doesn't do subdivision or allocation per se, that's the caller's job (whether the caller is malloc or not). So having mismatched page sizes makes no sense because it's the difference between having mmap be a suballocator or not. And clearly doing nothing is better/more efficient than doing something :)
>
> Now having said all that, I do buy the utility of having an emulation for compatibility.  In a custom wasm-only allocator you wouldn't assume an mmap, but I understand why musl's does. I hadn't realized musl's was quite so reliant on mmap but really it's not a problem on any other recent architecture I know of. So in principle I don't see any problem with having a system that uses a partial mmap emulation suitable for musl's unmodified allocator. And in that case you'd want to take the specifics of musl's allocator into account when choosing your page size.
>
> Which I guess brings us back to this code review; all of these tradeoffs can and should be made in the toolchain/OS emulation, and not in the linker; you or I or whoever should be able to make different choices and use the same linker.  So while some ABI choices will necessarily be baked in, I guess we should probably try not to bake too many in. I wouldn't have expected page size to be something that people would want to have different, but this compatibility argument is pretty compelling. Now that I think about it, I'll be there's a lot of code out there that assumes 4k pages, and in at least some of cases I'd guess it would make more sense to just fake having 4k pages than to fix that. So it probably does make sense to keep those assumptions out of the tools where possible.
>
> I think for the compiler and linker generally and this CL specifically, 16 byte stack alignment (rather than page-alignment) makes sense. This question of page size may come up in the future though, so I guess we should just be aware of it.


Indeed, IIUC we have gone off topic here since this CL has already landed with essentially with no specific heap base alignment and musl handles that just fine.

This discussion is now really just about musl's limits.h and we can discuss that independently of lld (at least I think its unrelated since lld isn't assuming a page size here).  Presumably over in the musl repo would be the best place to continue this.


Repository:
  rLLD LLVM Linker

https://reviews.llvm.org/D42030