thi-ng / tinyalloc Goto Github PK

I'm compiling to WASM with Clang/LLVM, not Emscripten, and was hoping to use tinyalloc. Going off of the information in this article, specifically the image indicating the data, stack, and heap layouts, it is stated that the .data section comes first, followed by the stack, and then the heap. Notice that the stack grows downwards toward __data_end.

(I couldn't find documentation describing Emscripten's memory layout, so I'm not sure if this is the same or different than Emscripten).

That leaves me with a few questions:

1. __data_end is typically 0x400, which is used for TA_BASE. If I place TA_BASE at 0x400, aren't I at risk of having the tinyalloc blocks clobbered by a stack that grows all the way to __data_end?
2. For my specific application, I have a lot of static strings compiled into my program, and therefore my .data section is much larger than 0x400, but I don't necessarily know the exact size at compile time (obviously using 0x400 for TA_BASE was overwriting some of my static data). Is it feasible to define a TA_BASE at runtime as part of ta_init(), or are there some reasons that it must be defined at compile time that I just don't understand?
3. If it's feasible to set TA_BASE and TA_HEAP_START at runtime, I was thinking that it might be a good idea to set TA_BASE to __heap_base and TA_HEAP_START to __heap_base + sizeof(Heap) so that it can grow without interference to the stack and data sections.

If these seem like valuable additions to the project, I'd be happy to take a stab at implementing them in such a way that these things can be configured when calling ta_init() and submitting a PR.

Hi @postspectacular, I noticed there haven't been any commits in master for a while, and a couple of PRs have been sitting for a bit too. Are you still interested in maintaining tinyalloc here, or would it make sense for ongoing work to continue in a new org/repo?

@marknelsonengineer (hope the tag is right) contacted me separately and is also interested in working on tinyalloc - I'll let him speak more to that.

Calling ta_alloc(0) and then another ta_alloc() (of any size) appears to be returning the same address twice. Having two memory blocks sharing the same address is bad since there is no way for ta_free() to know which to free.

ta_alloc(0) should probably either return NULL or behave the same as if ta_alloc(1) was called.

In function ta_init() the line
heap->fresh = heap->blocks;
appears before heap->blocks has been assigned.