Date: Wed, 12 Sep 2018 21:24:10 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Cortex-M support On Thu, Sep 13, 2018 at 03:06:52AM +0200, Pierluigi Passaro wrote: > This looks a good starting point: I'm targeting Cortex-M4 / M7 and > maybe Cortex-R. > I'm inspecting the code and trying to get a build. > I have a few questions: > > 1) NOMMU support looks disabled > I'm wondering if in the file arch/arm/reloc.h, some code should be > added (or not). > Somthing like > #if (__ARM_ARCH_PROFILE == 'M') || (__ARM_ARCH_PROFILE == 'R') > #define DL_NOMMU_SUPPORT 1 > #endif This is only going to matter if you want to do dynamic linking, which is *really* bad without fdpic/shared-text. You'll have a whole copy of each shared lib for each process. Once fdpic support is added and dynamic linking makes sense, it should probably be fixed, but I'd like to rethink some of this and make it so the dynamic linker doesn't need to be aware of whether it's nommu-compatible. > 2) trying to enable hardfp support, the build fails > - fabs try calling vabs.f64 assembly instruction > - sqrt try calling vsqrt.f64 assembly instruction > As far as I understood, vXXX.f64 instructions are only available > with single/double precision FPU, not with half precision. > I'm wondering if the assembly optimization should be wrapped by > something like > #if ... && (__ARM_FP > 7) > > I'm still trying to setup a reasonable build/test environment, but I > suppose I need some suggestions on how to proceed. > Any hints? Configurations where float and double are anything other than IEEE single and double with IEEE-conforming semantics, or where long double does not have IEEE-conforming semantics, are not supported/supportable by musl, by intent. I would assume there's some way to configure the compiler to offer a separate half-precision hardfloat type on an otherwise soft-float EABI target with conforming float/double, but if not this is a compiler deficiency that makes it impossible to use at this time. There were some SH4 models that also had this limitation (only single-precision FPU) and since GCC's only profile for them redefines double as single, rather than doing hard-single and soft-double, we just don't support hardfloat at all on them. In principle you could build musl as soft-float (with a softfloat toolchain) but use a separate toolchain with half-precision hardfloat for your applications. There would be no way to call stdlib interfaces that take floating point arguments without a glue layer though. Use of setjmp/longjmp might also be problematic (failure to restore float regs) but this could possibly be mitigated. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.