Views on bare metal port

Views on bare metal port

[Jon Chesterfield]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

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?

Cheers,

Jon

[-- Attachment #2: Type: text/html, Size: 1061 bytes --]

Re: Views on bare metal port

[Rich Felker]

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

Re: Views on bare metal port

[Jon Chesterfield]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

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" <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 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

[-- Attachment #2: Type: text/html, Size: 2775 bytes --]

Re: Views on bare metal port

[Szabolcs Nagy]

* Jon Chesterfield <jonathanchesterfield@gmail.com> [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/e7b0a63c190c7ecb475b09f41387a75952540f49
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 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

Re: Views on bare metal port

[Jon Chesterfield]

[-- Attachment #1: Type: text/plain, Size: 2972 bytes --]

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" <nsz@port70.net> wrote:

* Jon Chesterfield <jonathanchesterfield@gmail.com> [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" <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 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

[-- Attachment #2: Type: text/html, Size: 4322 bytes --]

Re: Views on bare metal port

[Rich Felker]

On Wed, Jan 31, 2018 at 06:37:24PM +0000, Jon Chesterfield wrote:
> 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?

No, they'll almost surely be rejected. What would be nice is a
proposal for getting the warnings we want, and only the ones we want,
by default on clang. Right now configure is well-tuned to do that for
gcc but not for clang.

I think what we need is probably first some way to detect if -w is
needed to turn off unwanted defaults (it's unsafe to use with gcc
because it overrides even -W's that come _after_ it), then using -w,
omitting -Wall, and manually building up the interesting warnings.

Rich

Re: Views on bare metal port

[ardi]

On Wed, Jan 31, 2018 at 7:25 PM, Szabolcs Nagy <nsz@port70.net> wrote:
>
> 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/e7b0a63c190c7ecb475b09f41387a75952540f49
> we don't have equivalent hacks in musl.

Being a clang user, this comment has worried me, because, according to
this bug report, there's a risk of generating wrong code:

https://bugs.llvm.org/show_bug.cgi?id=8100

However, a participant in the bug comments, argues that this doesn't
really violate standards compliance, just that a C99 feature is not
implemented yet, and that a warning will be triggered:

>> (quoting Richard Smith at bug report above):
>>
>> You are mistaken. Setting the rounding mode
>> without using #pragma STDC FENV_ACCESS ON
>> invokes undefined behavior. See C11 7.6.1/2. (This
>> pragma does not exist in C++, so <cfenv> is
>> unusable, but that's not our fault...)
>>
>> Clang doesn't support that pragma, making this
>> an unimplemented feature from C99, for which we
>> will produce a warning or error. That's the subject of
>> this enhancement request.

Now, and to the point that really interests me (generating safe code
from a clang+musl environment):

- What kind of math operations can be affected by this bug?

- Is there any workaround at this moment?

- Or is gcc the only compiler that can generate valid math code with
musl at this moment and we should better wait until clang gets bug
8100 fixed?

Thanks!

ardi

Re: Views on bare metal port

[Szabolcs Nagy]

* ardi <ardillasdelmonte@gmail.com> [2018-04-01 13:19:01 +0200]:
> On Wed, Jan 31, 2018 at 7:25 PM, Szabolcs Nagy <nsz@port70.net> wrote:
> >
> > 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/e7b0a63c190c7ecb475b09f41387a75952540f49
> > we don't have equivalent hacks in musl.
> 
> Being a clang user, this comment has worried me, because, according to
> this bug report, there's a risk of generating wrong code:
> 
> https://bugs.llvm.org/show_bug.cgi?id=8100
> 
> However, a participant in the bug comments, argues that this doesn't
> really violate standards compliance, just that a C99 feature is not
> implemented yet, and that a warning will be triggered:
> 
> >> (quoting Richard Smith at bug report above):
> >>
> >> You are mistaken. Setting the rounding mode
> >> without using #pragma STDC FENV_ACCESS ON
> >> invokes undefined behavior. See C11 7.6.1/2. (This
> >> pragma does not exist in C++, so <cfenv> is
> >> unusable, but that's not our fault...)
> >>

this is half true:

the default state of FENV_ACCESS is implementation defined,
when it's off then accessing the fenv is indeed ub.

in clang the default is off (which is fine) but there
is no way to turn it on (which is a conformance bug).

c++ is of course broken, unusable for numeric code.

> >> Clang doesn't support that pragma, making this
> >> an unimplemented feature from C99, for which we
> >> will produce a warning or error. That's the subject of
> >> this enhancement request.

this is false:

c99 fenv semantics is fully implementible without
supporting the pragma: never do code transformations
that break under fenv access, this is correct with
whatever pragma usage.
(musl code uses the pragma so there is no ub)

> 
> Now, and to the point that really interests me (generating safe code
> from a clang+musl environment):
> 
> - What kind of math operations can be affected by this bug?
> 
> - Is there any workaround at this moment?
> 
> - Or is gcc the only compiler that can generate valid math code with
> musl at this moment and we should better wait until clang gets bug
> 8100 fixed?
> 

in short:

most things will work even if musl is compiled by a
compiler without fenv access support, but it won't
be fully conforming when the caller changes or tests
the fenv.

in detail:

floating-point code may give wrong results in
non-nearest rounding mode, although in practice
optimizations that significantly break things are
rare (one example is const folding with nearest
rounding mode assumption)

floating-point code that itself changes rounding
mode can break badly, this is rare in practice,
but happened e.g in fma (which was indeed miscompiled
but we have a different algorithm now which has no
fenv access)

floating-point status flags may be wrong so code
that makes decisions based on that can be broken.

so if user code always calls libc apis with default
rounding mode and does not use the fenv status then
everything should work correctly with a miscompiled
musl, except fmaf and fmal which change the rounding
mode and lrint* and nearbyint* which check the status
flags can in principle be broken, however they are
written in a way that it's unlikely that the compiler
would do some code breaking transformation.

if you want to call libc functions with non-nearest
rounding mode then you can get wrong results or if
you test the status flags they may be wrong (even in
nearest rounding mode), but in those case you should
also worry about the calling code not just libc.

gcc does not support the fenv access pragma either
but it has -frounding-math which correctly compiles
all cases when a function must work with arbitrary
rounding mode (e.g. it does not do incorrect const
foldings), however it still miscompiles a few cases
when a function itself changes rounding mode
(floating-point operations must not be moved across
function calls in that case, but gcc does) and
sometimes it does not handle floating-point status
flags correctly (if the only side-effect of an
operation is the fenv status then gcc can optimize
it away so status flag settings may be missing,
there is an -ftrapping-math option which should take
care of this but it does not do anything useful)

Re: Views on bare metal port

[ardi]

On Sun, Apr 1, 2018 at 4:29 PM, Szabolcs Nagy <nsz@port70.net> wrote:
> in short:
>
> most things will work even if musl is compiled by a
> compiler without fenv access support, but it won't
> be fully conforming when the caller changes or tests
> the fenv.

Thanks a lot for your detailed clarifications! I never change the
rounding mode in my code, nor use the functions you mention, so I
think I'm safe to use clang with musl.

BTW, am I correct in assuming that these clang rounding mode issues
happen in all C runtimes in all OSs (MacOS included), or do some C
runtimes apply some hacks for preventing this behaviour? I feel a bit
puzzled about MacOS not saying a word about this in the docs. For
example, the MacOS manpages for fesetround() and for the functions you
mention, don't say a word about possible undesired behaviour with
clang.

Thanks!

ardi

Re: Views on bare metal port

[ardi]

Hi,

I'm also in need of a libc whose syscall interface was easily
hook-able. Not knowing of any libc that has all the syscalls clearly
encapsulated (and encapsulated at the C level rather than at assembly
level), but considering the clean design of musl, I've chosen musl as
probably the best option. You can check the thread I started in the
list last Christmas: http://www.openwall.com/lists/musl/2017/12/21/3

ardi


On Wed, Jan 31, 2018 at 2:38 PM, Jon Chesterfield
<jonathanchesterfield@gmail.com> 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?
>
> Cheers,
>
> Jon
>
>