Re: sbrk

On Nov 25, 2023, at 8:56 PM, Warner Losh <imp@bsdimp.com> wrote:
> 
> I see that it also uses tcc, which I coincidentally was looking at in the cdefs modernization efforts I've been doing. You'll need at least one patch to cdefs to get even the basics to compile. And three tests fail (one doesn't matter, one is constructors and dtors and a third fails to detect out of bounds access). I think only the ctor/dtor one is going to make things hard for you. I've not looked into any of the test failures, just a short-coming in cdefs.h since tcc doesn't support .symver yet.

using tcc fails with

In file included from /tmp/v_1001/ncpu.2284299819361377756.tmp.c:430:
/usr/include/stdlib.h:352: error: ARM asm not implemented.

tcc also doesn't pass as many tests as clang on amd64 (unfortunately, as it is compiles so much faster). Its native compiler is nowhere near ready.

It doesn't work well with the ported tcc on freebsd (I forget the details now). But if you have any bug fixes I am interested!

> sbrk can be faked with mmap of a large area up front with MAP_GUARD that's then grown or shrunk as new sbrk calls happen and remapped with MAP_FIXED. The only draw-back is you need reserve enough address space for all the program's memory needs (like GB of space maybe). The MAP_GUARD mappings are relatively cheap until it's actually used. Heck, you can even map SIGSEGV to check to see if you've "overflowed" the area to make it bigger (I hate that I know this trick, thank you Bourne shell).

I worked around with #define USE_MMAP 1.

SIGSEGV to grow the stack -- that was a problem on V7 shell on 68000! Luckily now that is only fit for old farts discussion on TUHS :-)

> Looks fun to play with. Maybe I'd help (but I already have too many fun and even more un-fun projects).

It seems to be so far but I haven't written enough code to find its gotchas.