Date: Sat, 25 Nov 2023 22:19:42 -0700 From: Warner Losh <imp@bsdimp.com> To: Bakul Shah <bakul@iitbombay.org> Cc: Joseph Holsten <joseph@josephholsten.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: sbrk Message-ID: <CANCZdfqSZeFtKvuZAgd9AvXCSF0hhi2PpyuQ86VN=7KpK0%2BK3A@mail.gmail.com> In-Reply-To: <4BA4DB2E-859A-427E-85AC-80F8F266C7BE@iitbombay.org> References: <2F758BA2-F7F5-4A2C-85CF-6969EE50309C@iitbombay.org> <949f8f16-1219-4f4a-abf6-f9727c95681b@Spark> <CANCZdfqcA-kLd3gLWkcD1%2BPGFg48TPAF=OPk9HzRFyaokZbvAQ@mail.gmail.com> <5668E8DE-B3B3-408D-978E-C2358A614803@iitbombay.org> <CANCZdfposZ2b0tDjwaQjqj1RVYKEK%2Bngr66wtkuRyUUq3r74Pw@mail.gmail.com> <4BA4DB2E-859A-427E-85AC-80F8F266C7BE@iitbombay.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000c8e687060b07557d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Sat, Nov 25, 2023 at 10:10=E2=80=AFPM Bakul Shah <bakul@iitbombay.org> w=
rote:
> On Nov 25, 2023, at 8:56=E2=80=AFPM, 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 pat=
ch
> 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 a=
re
> 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
--000000000000c8e687060b07557d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Sat, Nov 25, 2023 at 10:10=E2=80=
=AFPM Bakul Shah <<a href=3D"mailto:bakul@iitbombay.org">bakul@iitbombay=
.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div>On Nov 25, 2023, at 8:56=E2=80=AFPM, Warner Losh <<a href=3D"ma=
ilto:imp@bsdimp.com" target=3D"_blank">imp@bsdimp.com</a>> wrote:<br><di=
v><blockquote type=3D"cite"><br><div><div style=3D"font-family:Helvetica;fo=
nt-size:18px;font-style:normal;font-variant-caps:normal;font-weight:400;let=
ter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;whi=
te-space:normal;word-spacing:0px;text-decoration:none">I see that it also u=
ses tcc, which I coincidentally was looking at in the cdefs modernization e=
fforts 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 matte=
r, 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 yo=
u. I've not looked into any of the test failures, just a short-coming i=
n cdefs.h since tcc doesn't support .symver yet.</div></div></blockquot=
e><div><br></div>using tcc fails with</div><div><br></div><div><div><font f=
ace=3D"Menlo">In file included from /tmp/v_1001/ncpu.2284299819361377756.tm=
p.c:430:</font></div><div><font face=3D"Menlo">/usr/include/stdlib.h:352: e=
rror: ARM asm not implemented.</font></div></div></div></blockquote><div><b=
r></div><div>MY fix will fix that... Try this:</div><div><br></div><div>% d=
iff --git a/sys/sys/cdefs.h b/sys/sys/cdefs.h<br>index 549a51a00893..3fd2ac=
4e2af4 100644<br>--- a/sys/sys/cdefs.h<br>+++ b/sys/sys/cdefs.h<br>@@ -532,=
11 +532,17 @@<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 __asm__(".section .gnu.wa=
rning." #sym); \<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 __asm__(".asciz \=
"" msg "\""); =C2=A0\<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 __asm__(".previous")<br>+#ifndef __TINYC__<br>=C2=A0#define =
=C2=A0 =C2=A0 =C2=A0 =C2=A0__sym_compat(sym,impl,verid) =C2=A0 =C2=A0\<br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 __asm__(".symver " #impl ", &quo=
t; #sym "@" #verid)<br>=C2=A0#define =C2=A0 =C2=A0 =C2=A0 =C2=A0_=
_sym_default(sym,impl,verid) =C2=A0 \<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 __asm_=
_(".symver " #impl ", " #sym "@@@" #verid)<br=
>=C2=A0#else<br>+/* TinyC doesn't implement .symver */<br>+#define =C2=
=A0 =C2=A0 =C2=A0__sym_compat(sym,impl,verid)<br>+#define =C2=A0 =C2=A0 =C2=
=A0__sym_default(sym,impl,verid)<br>+#endif<br>+#else<br>=C2=A0#define =C2=
=A0 =C2=A0 =C2=A0 =C2=A0__weak_reference(sym,alias) =C2=A0 =C2=A0 \<br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 __asm__(".weak alias"); =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 \<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 __asm__(".equ alias, sy=
m")</div><div><br></div><div>you can just copy the patches sys/cdefs.h=
to /usr/include/sys and rebuild tcc and see how it goes.<br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>tcc al=
so doesn't pass as many tests as clang on amd64 (unfortunately, as it i=
s compiles so much faster). Its native compiler is nowhere near ready.</div=
></div></blockquote><div><br></div><div>I think it fixed another 10 or 15, =
but there were so many I didn't count them.<br></div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div><div>It doesn't w=
ork well with the ported tcc on freebsd (I forget the details now). But if =
you have any bug fixes I am interested!<br></div></div></blockquote><div><b=
r></div><div>Sure. included what I have so far above.</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><div><div><blockquote type=3D"cite"><div>=
<div style=3D"font-family:Helvetica;font-size:18px;font-style:normal;font-v=
ariant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;t=
ext-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text=
-decoration:none">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 rem=
apped 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&q=
uot; the area to make it bigger (I hate that I know this trick, thank you B=
ourne shell).<br></div></div></blockquote><div><br></div>I worked around wi=
th #define USE_MMAP 1.</div><div><br></div><div>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 :-)<br></div></div></blockquote><div><br></di=
v><div>Yea... <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div><div><blockquote type=3D"cite"><div><div style=3D"font-family:Helvetica=
;font-size:18px;font-style:normal;font-variant-caps:normal;font-weight:400;=
letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;=
white-space:normal;word-spacing:0px;text-decoration:none">Looks fun to play=
with. Maybe I'd help (but I already have too many fun and even more un=
-fun projects).</div></div></blockquote><br></div><div>It seems to be so fa=
r but I haven't written enough code to find its gotchas.</div></div></b=
lockquote><div><br></div><div>I'd be interested in knowing...</div><div=
><br></div><div>Warner <br></div></div></div>
--000000000000c8e687060b07557d--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqSZeFtKvuZAgd9AvXCSF0hhi2PpyuQ86VN=7KpK0%2BK3A>