Hi, As I have been researching what it would take to add floating-point support to the AArch64 port, I started realizing that it might be better (not necessarily easier) to upgrade musl. At first, I hoped I could just add fegetenv support (https://linux.die.net/man/3/fegetenv) by adding fenv.S from the latest musl. But very soon I have discovered we need to support LDBL_MANT_DIG=113 (please see comments in include/api/aarch64/bits/float.h) which triggers many missing symbols for LDBL_MANT_DIG == 113 (see also musl/src/math/__invtrigl.* for example) which I added manually from latest musl (would really require moving it to libc) but then there are 10 or so other math-related files like musl/src/math/lgammal.c and vfprintf.c-like ones that also need updates. And this is just for floating-point support (no signals, setjmp, and other goodies we also need to support AArch64 and might get from musl as well).
This led me to question this approach and realize that it might be better to simply upgrade musl to the latest version which has the latest AArch64 support plus all bugs fixed in the last 7 years. So I was wondering what you think about my pretty controversial idea? Obviously it is not a small effort and somewhat risky as things might break (what is a chance of that? any concrete examples?). But I think it is necessary and there is some concrete upside to that. Obviously we cannot simply update musl git subproject to the latest version as a significant number of files have been changed since and moved to libc subdirectory (or also somewhere else?) or were manually added from whatever version of musl at some point. So here is a high-level recipe on how we could do it: For each *.c|*.cc file (and probably headers) under libc/ find corresponding .c file under musl/src (sometimes the file will be .cc like libc/misc/getopt.cc where we had to add C++ code): - if file not found under musl nothing has to be done (correct?) - otherwise, find a delta between the two and apply to the copy in new musl (this would be in most cases manual step, as very often the old file in musl would have changed since 2013) As I understand many files under libc/ never came from musl - some were written from scratch (see libc/mman.cc) and some may have come from different place (see libc/locale/*_l.c which I think delegate to musl). Anything I have missed? How do we test all this? Besides unit tests we also have this - https://github.com/cloudius-systems/osv/wiki/Automated-Testing-Framework - which allows us to test OSv against 30+ apps. Do you have any suggestions for the strategy? Maybe something that would make future upgrades easier? What about reviewing the changes - how to make easier to review? Maybe a separate branch? Any step by step approach ideas? I think that Geraldo Netto started working on this at some point, but I am not sure where he left it off. Waldek PS. I am enclosing a file that is an approximation of a diff between libc and musl/src directories which I achieved more-less in this way: find libc/ -type f -name \*c > /tmp/libc #remove libc prefix find_diff (which is:) ------ #!/bin/bash execute_diff() { local NAME="$1" echo "-----------------------------------------" echo "DIFF: $NAME" diff musl/src$NAME libc$NAME 2>&1 } export -f execute_diff cat /tmp/libc2 | xargs -I{} bash -c "execute_diff {}" -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/d61435ae-dc51-48a4-938b-e77eb7f2725an%40googlegroups.com.
libc_musl_changes.gz
Description: GNU Zip compressed data
