* Views on bare metal port [not found] ` <CAOUYtQCHi6qR+=Jae--6M1VzeSiDBjj9_86hkpmN=XhSFDTTiQ@mail.gmail.com> @ 2018-01-31 13:38 ` Jon Chesterfield 2018-01-31 15:25 ` Rich Felker 2018-02-17 22:37 ` ardi 0 siblings, 2 replies; 10+ messages in thread From: Jon Chesterfield @ 2018-01-31 13:38 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Views on bare metal port 2018-01-31 13:38 ` Views on bare metal port Jon Chesterfield @ 2018-01-31 15:25 ` Rich Felker 2018-01-31 17:51 ` Jon Chesterfield 2018-02-17 22:37 ` ardi 1 sibling, 1 reply; 10+ messages in thread From: Rich Felker @ 2018-01-31 15:25 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Views on bare metal port 2018-01-31 15:25 ` Rich Felker @ 2018-01-31 17:51 ` Jon Chesterfield 2018-01-31 18:25 ` Szabolcs Nagy 0 siblings, 1 reply; 10+ messages in thread From: Jon Chesterfield @ 2018-01-31 17:51 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Views on bare metal port 2018-01-31 17:51 ` Jon Chesterfield @ 2018-01-31 18:25 ` Szabolcs Nagy 2018-01-31 18:37 ` Jon Chesterfield 2018-04-01 11:19 ` ardi 0 siblings, 2 replies; 10+ messages in thread From: Szabolcs Nagy @ 2018-01-31 18:25 UTC (permalink / raw) To: musl * 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Views on bare metal port 2018-01-31 18:25 ` Szabolcs Nagy @ 2018-01-31 18:37 ` Jon Chesterfield 2018-01-31 19:11 ` Rich Felker 2018-04-01 11:19 ` ardi 1 sibling, 1 reply; 10+ messages in thread From: Jon Chesterfield @ 2018-01-31 18:37 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Views on bare metal port 2018-01-31 18:37 ` Jon Chesterfield @ 2018-01-31 19:11 ` Rich Felker 0 siblings, 0 replies; 10+ messages in thread From: Rich Felker @ 2018-01-31 19:11 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Views on bare metal port 2018-01-31 18:25 ` Szabolcs Nagy 2018-01-31 18:37 ` Jon Chesterfield @ 2018-04-01 11:19 ` ardi 2018-04-01 14:29 ` Szabolcs Nagy 1 sibling, 1 reply; 10+ messages in thread From: ardi @ 2018-04-01 11:19 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Views on bare metal port 2018-04-01 11:19 ` ardi @ 2018-04-01 14:29 ` Szabolcs Nagy 2018-04-01 20:12 ` ardi 0 siblings, 1 reply; 10+ messages in thread From: Szabolcs Nagy @ 2018-04-01 14:29 UTC (permalink / raw) To: musl * 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) ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Views on bare metal port 2018-04-01 14:29 ` Szabolcs Nagy @ 2018-04-01 20:12 ` ardi 0 siblings, 0 replies; 10+ messages in thread From: ardi @ 2018-04-01 20:12 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Views on bare metal port 2018-01-31 13:38 ` Views on bare metal port Jon Chesterfield 2018-01-31 15:25 ` Rich Felker @ 2018-02-17 22:37 ` ardi 1 sibling, 0 replies; 10+ messages in thread From: ardi @ 2018-02-17 22:37 UTC (permalink / raw) To: musl, jonathanchesterfield 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 > > ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2018-04-01 20:12 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAOUYtQBwKmfwjmxUy+mfd0Qg+n78rCwKtK2=X6xgK-Cmt6EGXQ@mail.gmail.com> [not found] ` <CAOUYtQB4+8Yey+Q2yT3GWqTiobgPNf60G6dZHjUyjbj1SUC0TA@mail.gmail.com> [not found] ` <CAOUYtQD1LF03fbZ3U4e=s3uXiiY46jkuTjvzdfnz=c3mvzCrhw@mail.gmail.com> [not found] ` <CAOUYtQAZ-90b39f0Okz+KsnYK9G1FwdpTGtMSwJsWtsPwEWM-Q@mail.gmail.com> [not found] ` <CAOUYtQCNCU4rN74+HHmBTfgLTEdAhypWSL1L=Ooc1ocqjpEW_Q@mail.gmail.com> [not found] ` <CAOUYtQCCwhp-RSmod+dzLrFzqrR_Om-p6dD5kEkNtMT2B48FjQ@mail.gmail.com> [not found] ` <CAOUYtQDM4BW=WEXD5RK2YWf+3zj+opBuK8vsPwEPfyM3Hyo_6w@mail.gmail.com> [not found] ` <CAOUYtQCsJU_qczmjpH8NHbgqSHVLEAYOdpHVu7nmkie3zWAAyw@mail.gmail.com> [not found] ` <CAOUYtQDc8VHkH13Ah_+azk+goeOsthjFOhE4KfV6PCMoMKfukA@mail.gmail.com> [not found] ` <CAOUYtQCJD1Y-xV2bbBiGxE-W8jSWA9Qm=bzn1ri5Lq9+ACKSLw@mail.gmail.com> [not found] ` <CAOUYtQA3i8-z+LtzDbsUTJmLn76UXvDUpbKVHNfECSCMrPdiKA@mail.gmail.com> [not found] ` <CAOUYtQBDV0_0hkjtT3A+uOqnDkuKD-ZDr_DLo=DVSO5B6YZ3AA@mail.gmail.com> [not found] ` <CAOUYtQCHi6qR+=Jae--6M1VzeSiDBjj9_86hkpmN=XhSFDTTiQ@mail.gmail.com> 2018-01-31 13:38 ` Views on bare metal port Jon Chesterfield 2018-01-31 15:25 ` Rich Felker 2018-01-31 17:51 ` Jon Chesterfield 2018-01-31 18:25 ` Szabolcs Nagy 2018-01-31 18:37 ` Jon Chesterfield 2018-01-31 19:11 ` Rich Felker 2018-04-01 11:19 ` ardi 2018-04-01 14:29 ` Szabolcs Nagy 2018-04-01 20:12 ` ardi 2018-02-17 22:37 ` ardi
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).