From nobody Sun Nov 26 04:56:03 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 4SdGdV4ZkMz51tyf for ; Sun, 26 Nov 2023 04:56:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 4SdGdV2K79z3Xjt for ; Sun, 26 Nov 2023 04:56:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-54917ef6c05so4230278a12.1 for ; Sat, 25 Nov 2023 20:56:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1700974573; x=1701579373; 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=/JO9AG3kQwSZuJ1QbiYYA2FBH/MZQiUD2Lhi6o7J8Mc=; b=SIdJ7NjIASXud5y8ecJyCSFrlbqQAn3CJD0SmODWVT+4ZQ0+leyfVmY7m0cNTeneVZ 23Z+EM4kne70J1SwFmu7AhKd7CyIi/WnUKNw7QpZGlGFEVMb7BGym1t4nobRStbUYT7d Q+kFdig4pVnYhjuVTV2GmxzpHidgtVARPJRxO27Z5TAvAAhpD7y4WjIOiP1UN+b4czSF nRfVWJQix0RflLg/LrYfE/bVmwqQW0lPyMlSeakUmJ5gsBUczqGfYQLMH7zaWlS/K3vf 38IIyYF7i3dDgRpcCWfWouVb4Fb5W6OxP6cK4G37suI5j2Jz34p252ltLVv9QPD3WfhD ucXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700974573; x=1701579373; 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=/JO9AG3kQwSZuJ1QbiYYA2FBH/MZQiUD2Lhi6o7J8Mc=; b=nujKe01KoqQXZKqgAPg5fGHq1wg3tcCXVd2pABUi7Sa/5p8XC8qZTAOZSM91iuGIrG hxYdq5Gobpg0rTgnFTvFeLWo1EQFMBYz0ekDwUEDEOAPTf/ncKL74rs5ekvzWB/Um7CM AfrEMy7YObn5JfXzDuTAdW3Hv1k7H2aOxZGZINcrbqimQgY2nGHzHIT0Hop8nkbtQmRm gfAVR2PTuIA4Eq9iy7BgJgA4FMnveXuyLPDbDaP8OAF+6oSrOg/pCrtx6I85BxMbQQbM zlwd9kCVawoJDhgpd65rzACfQy1DEH4zMdFn/MjdsuQFdXgKjKcq2nrDTGY9ESVZwFMk dIyQ== X-Gm-Message-State: AOJu0YyttZWg5KB15NPhHXzoIPMy2hUtSu3QApCr78SB3DcZAbKhoqZm 3GRrvd2RrJMQU5w3FnJvqaiB+D0BA7Mqq3cTdkiK/pnZ8Ieb+QBU X-Google-Smtp-Source: AGHT+IHm3XMmsBuHje3nRizmWV6AmovBJqmiS5agQA6z/F1cIvmDeqLAUw19kh6+VHU4mcBu6QXwskwXQfnr+1CD6+Q= X-Received: by 2002:a05:6402:2207:b0:54b:25e8:c009 with SMTP id cq7-20020a056402220700b0054b25e8c009mr2104639edb.0.1700974572928; Sat, 25 Nov 2023 20:56:12 -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> In-Reply-To: <5668E8DE-B3B3-408D-978E-C2358A614803@iitbombay.org> From: Warner Losh Date: Sat, 25 Nov 2023 21:56:03 -0700 Message-ID: Subject: Re: sbrk To: Bakul Shah Cc: Joseph Holsten , "freebsd-arm@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000003118ac060b070112" 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: 4SdGdV2K79z3Xjt --0000000000003118ac060b070112 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 25, 2023 at 8:58=E2=80=AFPM Bakul Shah wr= ote: > On Nov 25, 2023, at 7:47=E2=80=AFPM, Warner Losh wrote: > > > On Sat, Nov 25, 2023, 8:44 PM wrote: > >> Yes, it=E2=80=99s no longer included. It=E2=80=99s long been deprecated,= but that does >> make porting things like the original vi a bit challenging. >> >> Is there a particular project you=E2=80=99re trying to use it for? >> > > It was never included in FreeBSD/arm64 due to the fact that the address > space is complicated now and there no longer is an area beyond bss that y= ou > can expand into... let alone contract... > > Emacs was not happy with it... > > > Thanks. Note that linux does provide it (may be not perfect but I thought > FreeBSD cared more about compatibility....). > > This came up in trying to compile the v language > https://github.com/vlang/v > > It uses a libgc which seems to be derived from some ancestor of BDW GC an= d > there are so many defines my eyes glaze over. > 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. 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). Looks fun to play with. Maybe I'd help (but I already have too many fun and even more un-fun projects). Warner > Warner > > -- >> Joseph Holsten >> On Nov 25, 2023 at 19:41 -0800, Bakul Shah , wrote: >> >> Does sbrk not exist on FreeBSD-14 on arm64? Is this by design? >> >> $ cat sb.c >> #include >> #include >> int main(int c, char**v) { >> void *x =3D sbrk(102400); >> printf("%p\n", x); >> } >> $ cc sb.c >> ld: error: undefined symbol: sbrk >> >>> referenced by sb.c >> >>> /tmp/sb-e97caf.o:(main) >> cc: error: linker command failed with exit code 1 (use -v to see >> invocation) >> >> > --0000000000003118ac060b070112 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Nov 25, 2023 at 8:58=E2=80=AF= PM Bakul Shah <bakul@iitbombay.or= g> wrote:
On Nov 25, 2023, at 7:47=E2=80=AFPM, Warner Losh <imp@bsdimp.com> wrote:
<= blockquote type=3D"cite">

On Sat, Nov 25, 2023, 8:44 P= M <joseph= @josephholsten.com> wrote:
Yes, it=E2=80=99s no longer included. It=E2=80=99s long b= een deprecated, but that does make porting things like the original vi a bi= t challenging.

Is there a particular project you=E2=80=99re trying to use it for?

It was never included in FreeBSD/arm64 due to the fact that the addres= s space is complicated now and there no longer is an area beyond bss that y= ou can expand into... let alone contract...

Emacs was not happy with it...

Thanks. Note that linux does provide it (may be not pe= rfect but I thought FreeBSD cared more about compatibility....).=C2=A0

This came up in trying to compile the v language
=

It uses a libgc which seems to b= e derived from some ancestor of BDW GC and there are so many defines my eye= s glaze over.

I see that it= also uses tcc, which I coincidentally was looking at in the cdefs moderniz= ation efforts I've been doing. You'll need at least one patch to cd= efs 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-c= oming in cdefs.h since tcc doesn't support .symver yet.
<= br>
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 remappe= d with MAP_FIXED. The only draw-back is you need reserve enough address spa= ce 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, yo= u 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 Bourn= e shell).

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

Warner
=C2=A0
=
Warner

--
Joseph Holsten
On Nov 25, 2023 at 19:41 -0800, Bakul Sha= h <bakul@iitbombay.org>, wrote:
Does sbrk not exist on FreeBSD-14 on arm64? Is this by de= sign?

$=C2=A0cat sb.c
#include <unistd.h>
#include <stdio.h>
int main(int c, char**v) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 void *x =3D sbrk(102400);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 printf("%p\n", x);
}
$ cc sb.c
ld: error: undefined symbol: sbrk
>>> referenced by sb.c
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /tmp/sb-= e97caf.o:(main)
cc: error: linker command failed with exit code 1 (use -v to see invoc= ation)


--0000000000003118ac060b070112--