Skip to content

Commit 2f59c61

Browse files
committed
dlmalloc: require __heap_end
This commit effectively drops the support of older wasm-ld. (LLVM <15.0.7) We have two relevant use cases: * `memory.grow` use outside of malloc (eg. used by polyfill preview1 binaries) * `--init-memory` to somehow preallocate heap (eg. avoid dynamic allocations, especially on small environments) While WebAssembly#377 fixed the former, it broke the latter if you are using an older LLVM, which doesn't provide the `__heap_end` symbol, to link your module. As we couldn't come up with a solution which satisfies all parties, this commit simply makes it require new enough LLVM which provides `__heap_end`. After all, a link-time failure is more friendly to users than failing later in a subtle way.
1 parent f2a35a4 commit 2f59c61

File tree

3 files changed

+10
-17
lines changed

3 files changed

+10
-17
lines changed

dlmalloc/src/malloc.c

Lines changed: 8 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -5215,7 +5215,7 @@ static void internal_inspect_all(mstate m,
52155215

52165216
/* Symbol marking the end of data, bss and explicit stack, provided by wasm-ld. */
52175217
extern char __heap_base;
5218-
extern char __heap_end __attribute__((__weak__));
5218+
extern char __heap_end;
52195219

52205220
/* Initialize the initial state of dlmalloc to be able to use free memory between __heap_base and initial. */
52215221
static void try_init_allocator(void) {
@@ -5227,23 +5227,14 @@ static void try_init_allocator(void) {
52275227

52285228
char *base = &__heap_base;
52295229
// Try to use the linker pseudo-symbol `__heap_end` for the initial size of
5230-
// the heap, but if that's not defined due to LLVM being too old perhaps then
5231-
// round up `base` to the nearest `PAGESIZE`. The initial size of linear
5232-
// memory will be at least the heap base to this page boundary, and it's then
5233-
// assumed that the initial linear memory image was truncated at that point.
5234-
// While this reflects the default behavior of `wasm-ld` it is also possible
5235-
// for users to craft larger linear memories by passing options to extend
5236-
// beyond this threshold. In this situation the memory will not be used for
5237-
// dlmalloc.
5238-
//
5239-
// Note that `sbrk(0)`, or in dlmalloc-ese `CALL_MORECORE(0)`, is specifically
5240-
// not used here. That captures the current size of the heap but is only
5241-
// correct if the we're the first to try to grow the heap. If the heap has
5242-
// grown elsewhere, such as a different allocator in place, then this would
5243-
// incorrectly claim such memroy as our own.
5230+
// the heap.
52445231
char *end = &__heap_end;
5245-
if (end == NULL)
5246-
end = (char*) page_align((size_t) base);
5232+
if (end == NULL) {
5233+
// This can happen when 1. you are using an old wasm-ld which doesn't
5234+
// provide `__heap_end` and 2. something (other libraries or maybe
5235+
// your app?) provide a weak reference to `__heap_end`.
5236+
return;
5237+
}
52475238
size_t initial_heap_size = end - base;
52485239

52495240
/* Check that initial heap is long enough to serve a minimal allocation request. */

expected/wasm32-wasi-threads/undefined-symbols.txt

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -13,6 +13,7 @@ __getf2
1313
__global_base
1414
__gttf2
1515
__heap_base
16+
__heap_end
1617
__imported_wasi_snapshot_preview1_args_get
1718
__imported_wasi_snapshot_preview1_args_sizes_get
1819
__imported_wasi_snapshot_preview1_clock_res_get

expected/wasm32-wasi/undefined-symbols.txt

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,7 @@ __floatunsitf
1111
__getf2
1212
__gttf2
1313
__heap_base
14+
__heap_end
1415
__imported_wasi_snapshot_preview1_args_get
1516
__imported_wasi_snapshot_preview1_args_sizes_get
1617
__imported_wasi_snapshot_preview1_clock_res_get

0 commit comments

Comments
 (0)