[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALqyXLhmcdaQDmPjK7GWOwh+2Vgd0C2bzQZFAEeOhjeJYCc2Nw@mail.gmail.com>
Date: Wed, 16 Dec 2020 18:43:15 -0500
From: Jesse DeGuire <jesse.a.deguire@...il.com>
To: musl@...ts.openwall.com
Subject: Musl on Cortex-M Devices
Hey everyone,
I'm working on putting together a Clang-based toolchain to use with
Microchip PIC32 (MIPS32) and SAM (Cortex-M) microcontrollers as an
alternative to their paid XC32 toolchain and I'd like to use Musl as
the C library. Currently, I'm trying to get it to build for a few
different Cortex-M devices and have found that Musl builds fine for
ARMv7-M, but not for ARMv6-M or v8-M Baseline because Musl uses
instructions not supported on the Thumb ISA subset used by v6-M and
v8-M Baseline devices. I'm using the v1.2.1 tag version of Musl, but
can easily switch to HEAD if needed. I am using a Python script to
build Musl (and eventually the rest of the toolchain), which you can
see on GitHub at the following link. It's a bit of a mess at the
moment, but the build_musl() function is what I'm currently using to
build Musl.
https://github.com/jdeguire/buildPic32Clang/blob/master/buildPic32Clang.py
Anyway, I have managed to get Musl to build for v6-M, v7-M, and v8-M
Baseline and have attached a diff to this email. If you like, I can go
into more detail as to why I made the changes I made; however, many
changes were merely the result of my attempts to correct errors
reported by Clang due to it encountering instruction sequences not
supported on ARMv6-M. A number of errors were simply the result of
ARMv6-M requiring one to use the "S" variant of an instruction that
sets status flags (such as "ADDS" vs "ADD" or "MOVS" vs "MOV"). A few
files I had to change from a "lower case s" to a "capital-S" file so
that I could use macros to check for either the Thumb1 ISA
("__thumb2__ || !__thumb__") or for an M-Profile device
("!__ARM_ARCH_ISA_ARM"). The changes under
"src/thread/arm/__set_thread_area.c" are different in that I made
those because I don't believe Cortex-M devices could handle what was
there (no M-Profile device has Coprocessor 15, for example) and so I
sort of punted for now and figured that a user's fault handler could
handle those "_kuser" calls given that there probably won't be a
kernel to do so.
Unfortunately, I'm not far enough yet in my project to build code that
would actually run on one of the micros I have with me, so I haven't
yet been able to properly try out these changes. Also, I should
mention that my eventual plan is to make a "baremetal" layer that
would provide stubs to handle syscalls or thread-related things that
you wouldn't normally have on a microcontroller, but I want to get
Musl building without that first because I think I'll be able to
utilize a lot of what's already present when I get to that point.
Hopefully, what's here is still somewhat useful as a starting point
should Musl want to support Cortex-M. I'll try to update this diff as
a result of feedback or my own eventual testing (I'm a long way from
that, though!).
Thanks,
Jesse
Download attachment "musl_cortexm.diff" of type "application/octet-stream" (22666 bytes)
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.
