From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12437 Path: news.gmane.org!.POSTED!not-for-mail From: Jon Chesterfield Newsgroups: gmane.linux.lib.musl.general Subject: Re: Views on bare metal port Date: Wed, 31 Jan 2018 17:51:33 +0000 Message-ID: References: <20180131152507.GO1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113cd4d242f8840564162109" X-Trace: blaine.gmane.org 1517421001 27635 195.159.176.226 (31 Jan 2018 17:50:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 31 Jan 2018 17:50:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12453-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 31 18:49:57 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1egwW0-0006BI-VT for gllmg-musl@m.gmane.org; Wed, 31 Jan 2018 18:49:45 +0100 Original-Received: (qmail 11404 invoked by uid 550); 31 Jan 2018 17:51:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 11380 invoked from network); 31 Jan 2018 17:51:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Ths2TyPz2UpsOE08pSpzT8BPbrlNlf3LwqyJTHZn4zs=; b=iaD5h4NhaXhzHys7l6T1rkQ6TfWozzzRjUdCTe00CV/MVXtMvDHbVBocp8ansMpWnK RA2sfIj8/bOr/8io7hM0EznAN8j1BE3N9fnPyF1gEOlqhyRiz+ElKn68E52zA9+25Kg4 c1s9s893ZGXQuES3WgY/HchdlQVLY2JgBYBJlegfHe/cV/pp8YojLOKMuzca+cXkTMxX SmWok6cpxc0NhsETrt4NrpoxYJ36HqQvk9nfVrDB0alJuKsdBAFkqPDQg+vjpIlAAOda e6bOXesBPEY9hAHGey2pmkYAqMAaD8NnRK0rs71VkNKZCPk4vk2WYtg6nfInPgS9vPkP p98Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Ths2TyPz2UpsOE08pSpzT8BPbrlNlf3LwqyJTHZn4zs=; b=Ysb1Orl+5G92TpBk6NkGtO0DR+giwwD/ieKlLme1xj56UtkemClnZneuZWjr4DFp2b suTwqU44UE0gk4iWgpeKqxeu7Kknnve/hrHelDXB5j4/Oi3bFTQw83PF0oXyhC6faW35 pXoa63hRYMWnm8PwqWbxc48HfJO+Zm0xm0zqPYS+10HGiQ5STHAmX5Dc4S4AfrYJrmUu 2QuIqt9jjN14atNBmDQqjEIHnHr46Jciz1Dov//QHb4bi2dJP5LoWgl3EH0Qy2RUp7et qJAQOYZxMtzl9QFB/AqqpQV0ojsiJ2fnR1qPv3qWRD5P/U/5JZNlH8wm2fwlTEeuW9ZR 6wvg== X-Gm-Message-State: AKwxytf5GwDs4mG4WynJMWzx7Si/bP68KcuQbSh4HnDn4dy0Fkcaa818 P/9LRALCq424kFVLzquiKtPBTO7V4nBL6g/xC/GsSQ== X-Google-Smtp-Source: AH8x224TtQUi2cQjb4GOnaNTX+AiRiYGeQOgIM8wpkZcgY/sekzTun6tgI6P6bsd7MBZ0NSEDoQFsV4cXGlAFMeCyes= X-Received: by 10.202.193.137 with SMTP id r131mr20651635oif.232.1517421093646; Wed, 31 Jan 2018 09:51:33 -0800 (PST) In-Reply-To: <20180131152507.GO1627@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12437 Archived-At: --001a113cd4d242f8840564162109 Content-Type: text/plain; charset="UTF-8" Thank you for your reply. Implementing the syscalls probably wouldn't be too much trouble, thanks for the advice. I've been able to build 95% of math on our toolchain in the last hour. Impressed by how straightforward that was. Nice codebase. Cheers, Jon On 31 Jan 2018 15:25, "Rich Felker" wrote: On Wed, Jan 31, 2018 at 01:38:44PM +0000, Jon Chesterfield wrote: > Hello musl, > > I'm writing an llvm back end for a custom asic. There's no kernel, limited > syscall support. As far as I can tell from the source tree, musl expects a > host OS. I'm aware of a couple of projects running musl by emulating the > Linux syscall interface. > > I would like to derive libc from a subset of musl. Math.h included, > filesystem excluded. Malloc and threads tdb. > > Are there any bare metal projects that use musl without syscall emulation? > If not, would one be of interest to this mailing list? I'm not aware of any specific ones to recommend (maybe others can suggest) but here are a couple general guidelines: 1. The easiest and probably-recommended way to do this is just writing a trap handler to implement the syscalls you need and using musl unmodified. You've said you don't want to do that, though, so moving on... 2. The other intended/recommended way is making new arch dirs with a syscall_impl.h that implements the syscall.h backend stuff as calls to your own functions. The SYS_* macros can actually be defined as function pointers if you like, or you can still use numbers and a switch-based dispatch table. Either way the vast majority of syscall points have constant expressions for the syscall number so it should all collapse/inline fine to a single direct call. 3. While you can trim down parts of the tree you don't need, there's usually no compelling reason to do so. Static linking (only option for bare metal anyway) will not link things you don't use. Hope this helps a bit. Rich --001a113cd4d242f8840564162109 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for your reply.

Implementing the syscalls probably wouldn't be too m= uch trouble, thanks for the advice.

I'= ve been able to build 95% of math on our toolchain in the last hour. Impres= sed by how straightforward that was. Nice codebase.=C2=A0

Cheers,

=
Jon

On 31 Jan 2018 15:25, "Rich Felker" <dalias@libc.org> wrote:
On Wed, Jan = 31, 2018 at 01:38:44PM +0000, Jon Chesterfield wrote:
> Hello musl,
>
> I'm writing an llvm back end for a custom asic. There's no ker= nel, limited
> syscall support. As far as I can tell from the source tree, musl expec= ts a
> host OS. I'm aware of a couple of projects running musl by emulati= ng the
> Linux syscall interface.
>
> I would like to derive libc from a subset of musl. Math.h included, > filesystem excluded. Malloc and threads tdb.
>
> Are there any bare metal projects that use musl without syscall emulat= ion?
> If not, would one be of interest to this mailing list?

I'm not aware of any specific ones to recommend (maybe others can=
suggest) but here are a couple general guidelines:

1. The easiest and probably-recommended way to do this is just writing
=C2=A0 =C2=A0a trap handler to implement the syscalls you need and using mu= sl
=C2=A0 =C2=A0unmodified. You've said you don't want to do that, tho= ugh, so
=C2=A0 =C2=A0moving on...

2. The other intended/recommended way is making new arch dirs with a
=C2=A0 =C2=A0syscall_impl.h that implements the syscall.h backend stuff as = calls
=C2=A0 =C2=A0to your own functions. The SYS_* macros can actually be define= d as
=C2=A0 =C2=A0function pointers if you like, or you can still use numbers an= d a
=C2=A0 =C2=A0switch-based dispatch table. Either way the vast majority of =C2=A0 =C2=A0syscall points have constant expressions for the syscall numbe= r so
=C2=A0 =C2=A0it should all collapse/inline fine to a single direct call.
3. While you can trim down parts of the tree you don't need, there'= s
=C2=A0 =C2=A0usually no compelling reason to do so. Static linking (only op= tion
=C2=A0 =C2=A0for bare metal anyway) will not link things you don't use.=

Hope this helps a bit.

Rich

--001a113cd4d242f8840564162109--