Re: sbrk

On Sat, Nov 25, 2023 at 10:10 PM Bakul Shah <bakul@iitbombay.org> wrote:

> 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.
>

MY fix will fix that... Try this:

% diff --git a/sys/sys/cdefs.h b/sys/sys/cdefs.h
index 549a51a00893..3fd2ac4e2af4 100644
--- a/sys/sys/cdefs.h
+++ b/sys/sys/cdefs.h
@@ -532,11 +532,17 @@
        __asm__(".section .gnu.warning." #sym); \
        __asm__(".asciz \"" msg "\"");  \
        __asm__(".previous")
+#ifndef __TINYC__
 #define        __sym_compat(sym,impl,verid)    \
        __asm__(".symver " #impl ", " #sym "@" #verid)
 #define        __sym_default(sym,impl,verid)   \
        __asm__(".symver " #impl ", " #sym "@@@" #verid)
 #else
+/* TinyC doesn't implement .symver */
+#define      __sym_compat(sym,impl,verid)
+#define      __sym_default(sym,impl,verid)
+#endif
+#else
 #define        __weak_reference(sym,alias)     \
        __asm__(".weak alias");         \
        __asm__(".equ alias, sym")

you can just copy the patches sys/cdefs.h to /usr/include/sys and rebuild
tcc and see how it goes.


> 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.
>

I think it fixed another 10 or 15, but there were so many I didn't count
them.


> 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!
>

Sure. included what I have so far above.

> 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 :-)
>

Yea...

> 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.
>

I'd be interested in knowing...

Warner