From nobody Sun Nov 26 05:19:42 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SdH8p4RjQz5263j for ; Sun, 26 Nov 2023 05:19:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SdH8n4jYdz3dHS for ; Sun, 26 Nov 2023 05:19:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-54b0e553979so1695072a12.2 for ; Sat, 25 Nov 2023 21:19:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1700975992; x=1701580792; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=c/Pff4w+yA9K0F4CIC8mBr37PovwRUw5AeoiT/LA1MQ=; b=D+x7KC4mt7XOAi0rOFgxcaqF+LV4JnCOPki4QToYp8uUQ8JKvUNBRHYMVbBxLamQKC pddF/u0Hp2jaqPTF6iERKJlQ4XTqaz2Vn/IZ37rLBcQIlJFxN8A+6zv+1hnC2ngFCZyd ACW/eyypSxpXilNTu7zDbOZrWzQtDFfHEHz3azyqvOVcJZHjQlvePTgefORR2cZEFf70 Idakn+d2B1ux4MdZycYIiujpTp5zpKBtQMpuN5d9RQ/HBQdm7yjG9xZsMJR+z+3+nvq0 YlDqms536YlXWOD2FiAm3qPkcMIW7R8/++//vSdFYu6peKKYRlKw3Oz/aoIL4J0Rgrtd BAQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700975992; x=1701580792; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=c/Pff4w+yA9K0F4CIC8mBr37PovwRUw5AeoiT/LA1MQ=; b=KN86P64Ibdgjkb/nTHWQUEBhJcdPP7s8D8eOyXegBWgZpmEUhv5rKnWLh9eErJGu4o TZ+9U0tiKQikN/ECiavEFYN+oO7Fo1fOwuYfcYMPcUfzDCMlKjBusYer1T+ojsCMGLSr CLMd4u5/bS17B6wgkmTQNarkCAbNPqjfZHcw7iZBxCqrw0Rn/i3cr1pwO0hGj7BbwK6v 4Y0+0vepl2iGnA5jlmTQOOY/2owmhCqba/NC2FWUQgdcknH73/xKHqFsKkRrKXq+W3Fl D8eBi8gkUt/vU0exc4hJS9lcsqFumpkBBwU9M0S6oYWhGO7X+RDNfHvuxMAYMhGG37CE lsoQ== X-Gm-Message-State: AOJu0Yy7EKBexzfKZZ0i37EWPkSLMRC/pg/xBkbI1QNrRy2BX0vpKh+7 +oqLBa7O6C7izftf28MhxjPlPcloALXws3+eZwCEqLTb4+xUU0GG6Io= X-Google-Smtp-Source: AGHT+IFUEXH82OLw8DqoUqPiyQcQJrf5Bl+mMF8x50luf+TNIACjSI1V2XFltLTpqjFQXO2Y1mvesY6KwgcIR2k9Jts= X-Received: by 2002:a05:6402:35d4:b0:53d:b751:ece1 with SMTP id z20-20020a05640235d400b0053db751ece1mr5424032edc.41.1700975992165; Sat, 25 Nov 2023 21:19:52 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <2F758BA2-F7F5-4A2C-85CF-6969EE50309C@iitbombay.org> <949f8f16-1219-4f4a-abf6-f9727c95681b@Spark> <5668E8DE-B3B3-408D-978E-C2358A614803@iitbombay.org> <4BA4DB2E-859A-427E-85AC-80F8F266C7BE@iitbombay.org> In-Reply-To: <4BA4DB2E-859A-427E-85AC-80F8F266C7BE@iitbombay.org> From: Warner Losh Date: Sat, 25 Nov 2023 22:19:42 -0700 Message-ID: Subject: Re: sbrk To: Bakul Shah Cc: Joseph Holsten , "freebsd-arm@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000c8e687060b07557d" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4SdH8n4jYdz3dHS --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 w= rote: > On Nov 25, 2023, at 8:56=E2=80=AFPM, Warner Losh 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


=
On Sat, Nov 25, 2023 at 10:10=E2=80= =AFPM Bakul Shah <bakul@iitbombay= .org> wrote:
On Nov 25, 2023, at 8:56=E2=80=AFPM, Warner Losh <imp@bsdimp.com> wrote:

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.

using tcc fails with

In file included from /tmp/v_1001/ncpu.2284299819361377756.tm= p.c:430:
/usr/include/stdlib.h:352: e= rror: ARM asm not implemented.
MY fix will fix that... Try this:

% d= iff --git a/sys/sys/cdefs.h b/sys/sys/cdefs.h
index 549a51a00893..3fd2ac= 4e2af4 100644
--- a/sys/sys/cdefs.h
+++ b/sys/sys/cdefs.h
@@ -532,= 11 +532,17 @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0 __asm__(".section .gnu.wa= rning." #sym); \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 __asm__(".asciz \= "" msg "\""); =C2=A0\
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 __asm__(".previous")
+#ifndef __TINYC__
=C2=A0#define = =C2=A0 =C2=A0 =C2=A0 =C2=A0__sym_compat(sym,impl,verid) =C2=A0 =C2=A0\
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 __asm__(".symver " #impl ", &quo= t; #sym "@" #verid)
=C2=A0#define =C2=A0 =C2=A0 =C2=A0 =C2=A0_= _sym_default(sym,impl,verid) =C2=A0 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 __asm_= _(".symver " #impl ", " #sym "@@@" #verid)=C2=A0#else
+/* TinyC doesn't implement .symver */
+#define =C2= =A0 =C2=A0 =C2=A0__sym_compat(sym,impl,verid)
+#define =C2=A0 =C2=A0 =C2= =A0__sym_default(sym,impl,verid)
+#endif
+#else
=C2=A0#define =C2= =A0 =C2=A0 =C2=A0 =C2=A0__weak_reference(sym,alias) =C2=A0 =C2=A0 \
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 __asm__(".weak alias"); =C2=A0 =C2=A0 = =C2=A0 =C2=A0 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 __asm__(".equ alias, sy= m")

you can just copy the patches sys/cdefs.h= to /usr/include/sys and rebuild tcc and see how it goes.
=C2= =A0
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.

I think it fixed another 10 or 15, = but there were so many I didn't count them.
=C2=A0
<= 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">
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!
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 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).

I worked around wi= th #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...
<= div>
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 fa= r but I haven't written enough code to find its gotchas.

I'd be interested in knowing...

Warner
--000000000000c8e687060b07557d--