From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12439 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 18:37:24 +0000 Message-ID: References: <20180131152507.GO1627@brightrain.aerifal.cx> <20180131182546.GL4418@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11492f36408711056416c5d9" X-Trace: blaine.gmane.org 1517423741 23902 195.159.176.226 (31 Jan 2018 18:35:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 31 Jan 2018 18:35:41 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12455-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 31 19:35:37 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 1egxEO-0005tB-0s for gllmg-musl@m.gmane.org; Wed, 31 Jan 2018 19:35:36 +0100 Original-Received: (qmail 17908 invoked by uid 550); 31 Jan 2018 18:37:37 -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 17883 invoked from network); 31 Jan 2018 18:37:37 -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=kWiEd3RQIlKtl1X6dWxiPZfuimKuQv/ujSyGHY185ls=; b=vcSlctfiOORgf3k2/vVQbtyCJ/fvVstp0Y3p6oI73dN1XYTLSCV61H3m4kLNDhb4eL OKY2DHZRTTHZA3X0Zlq/O7RDJf3g4AR1IIXeG6rq9SrdvhyeQW+0unaDc5Qmg1m0wCJi scaR0lz8/nmIUWfBG9PGxtzYKPXNa3lIJAZdThvAg4Ll4K1l8Fo9yZSZeS+dXcdc7Znx aO/k34mDVZ8AK5IoA8ZhvBs7S0nZDx6ZF4Jb3O6aL70ei/qacE9qGjXJ/3TORXc7PsY2 4b+e5e/4D95sLh3IfUK0voJreNH/LhBn7G6eDDrBhXTwgTAWvrtRFGK6E+ANxJG3Gji6 gseg== 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=kWiEd3RQIlKtl1X6dWxiPZfuimKuQv/ujSyGHY185ls=; b=FslC//XrW7jciHD0FtwlplfHwzKJsC0DZR1/D0cGvaBu8hsRMu5H+5kDXjNJ2LFyoM yC5kbRa1XmbQrb1LkPQR3i0hadRmHJLg7LzXNxnCZaSOsuE4GOYCax7VOZhNnDaRUdpt 2LHerUZs+P+1dFWfoy+WS/PhOHsQ9kLgxdjCnvqkATJuvXuugmJy47gg9fxht/MChiUG A+GKMnI40aYNTgXOXK6sujiQNaMyLpRXN5Afh8SXMmteYZpzGagEplfmeky9sIG/RWj4 ZHDDoIzuGkq/0LNSBM2uxrdq7Luy01PKcb0Jy5HnXonwYTbEPQkVG4ZxmyLvF0GbEQws Z5Fg== X-Gm-Message-State: AKwxytcL9I6sXT4cYjPVdGI9Ht/pFUcsbBYsg6LjHDbdg3PSxR5T3eup U3LMR9U7A9pXz23zDYPuQCXY/1PlKWHcGn03f77z1A== X-Google-Smtp-Source: AH8x2272amDgPeDgNOoe+LKQDtivYreRdTc4LvAyct9puMEn/gusLOwesnOAMaIaqrm0uWqvQN6yEua+eVTGQakB4bU= X-Received: by 10.157.35.228 with SMTP id t91mr23424799otb.228.1517423844950; Wed, 31 Jan 2018 10:37:24 -0800 (PST) In-Reply-To: <20180131182546.GL4418@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:12439 Archived-At: --001a11492f36408711056416c5d9 Content-Type: text/plain; charset="UTF-8" Yep, that's the 5%! There's work on rounding modes happening in LLVM at present, but it doesn't work yet and I can't justify working on it :( There are a number of style warnings from clang related to operator precedence (suggesting more parentheses) - would patches for these be worth submitting? Thanks! On 31 Jan 2018 18:26, "Szabolcs Nagy" wrote: * Jon Chesterfield [2018-01-31 17:51:33 +0000]: > 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. > note that in particular for math code llvm is problematic. i'm not aware of any issues in musl libm currently, but rounding mode changes can break in unexpected ways because there is no support for -frounding-math (last time i checked the few cases where it matters clang did not miscompile those, but this is not actively tested) an illustration of the kind of things that can go wrong: https://github.com/freebsd/freebsd/commit/e7b0a63c190c7ecb475b09f41387a7 5952540f49 we don't have equivalent hacks in musl. > 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 --001a11492f36408711056416c5d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yep, that's the 5%! There's work on rounding= modes happening in LLVM at present, but it doesn't work yet and I can&= #39;t justify working on it :(
<= br>
There are a number of style warnings fr= om clang related to operator precedence (suggesting more parentheses) - wou= ld patches for these be worth submitting?

Thanks!
=

On 31 Jan 2018 18:26, "Szabolcs Nagy" <nsz@port70.net> wrote:
=
* Jon Chesterfield <jonathanchesterfield@gmail.com> [2018-01= -31 17:51:33 +0000]:
> Implementing the syscalls probably wouldn&#= 39;t be too much trouble, thanks for
> the advice.
>
> I've been able to build 95% of math on our toolchain in the last h= our.
> Impressed by how straightforward that was. Nice codebase.
>

note that in particular for math code llvm is problematic.

i'm not aware of any issues in musl libm currently, but
rounding mode changes can break in unexpected ways because
there is no support for -frounding-math (last time i checked
the few cases where it matters clang did not miscompile those,
but this is not actively tested)

an illustration of the kind of things that can go wrong:
https://github.com= /freebsd/freebsd/commit/e7b0a63c190c7ecb475b09f41387a7595254= 0f49
we don't have equivalent hacks in musl.

> 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 n= o 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 em= ulating the
> > Linux syscall interface.
> >
> > I would like to derive libc from a subset of musl. Math.h include= d,
> > filesystem excluded. Malloc and threads tdb.
> >
> > Are there any bare metal projects that use musl without syscall e= mulation?
> > If not, would one be of interest to this mailing list?
>
> I'm not aware of any specific ones to recommend (maybe others can<= br> > suggest) but here are a couple general guidelines:
>
> 1. The easiest and probably-recommended way to do this is just writing=
>=C2=A0 =C2=A0 a trap handler to implement the syscalls you need and usi= ng musl
>=C2=A0 =C2=A0 unmodified. You've said you don't want to do that= , though, so
>=C2=A0 =C2=A0 moving on...
>
> 2. The other intended/recommended way is making new arch dirs with a >=C2=A0 =C2=A0 syscall_impl.h that implements the syscall.h backend stuf= f as calls
>=C2=A0 =C2=A0 to your own functions. The SYS_* macros can actually be d= efined as
>=C2=A0 =C2=A0 function pointers if you like, or you can still use numbe= rs and a
>=C2=A0 =C2=A0 switch-based dispatch table. Either way the vast majority= of
>=C2=A0 =C2=A0 syscall points have constant expressions for the syscall = number so
>=C2=A0 =C2=A0 it should all collapse/inline fine to a single direct cal= l.
>
> 3. While you can trim down parts of the tree you don't need, there= 's
>=C2=A0 =C2=A0 usually no compelling reason to do so. Static linking (on= ly option
>=C2=A0 =C2=A0 for bare metal anyway) will not link things you don't= use.
>
> Hope this helps a bit.
>
> Rich

--001a11492f36408711056416c5d9--