mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Jesse DeGuire <jesse.a.deguire@gmail.com>
To: musl@lists.openwall.com
Subject: [musl] Musl on Cortex-M Devices
Date: Wed, 16 Dec 2020 18:43:15 -0500	[thread overview]
Message-ID: <CALqyXLhmcdaQDmPjK7GWOwh+2Vgd0C2bzQZFAEeOhjeJYCc2Nw@mail.gmail.com> (raw)

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

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

[-- Attachment #2: musl_cortexm.diff --]
[-- Type: application/octet-stream, Size: 22666 bytes --]

             reply	other threads:[~2020-12-16 23:43 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-16 23:43 Jesse DeGuire [this message]
2020-12-17  0:23 ` Rich Felker
2020-12-17  4:55   ` Patrick Oppenlander
2020-12-17  5:10     ` Patrick Oppenlander
2020-12-18  7:17       ` Jesse DeGuire
2020-12-22 21:43         ` Patrick Oppenlander
2021-01-06  3:24           ` Jesse DeGuire
2021-01-06  4:01             ` Patrick Oppenlander
2021-01-13 23:51               ` Jesse DeGuire
2020-12-18  7:15   ` Jesse DeGuire
2020-12-18 17:30     ` Rich Felker
2020-12-21 23:58       ` Jesse DeGuire
2020-12-22  1:39         ` Rich Felker
2020-12-18 19:38   ` Markus Wichmann
2020-12-18 20:34     ` Rich Felker
2020-12-22  0:00       ` Jesse DeGuire
2020-12-22  1:40         ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALqyXLhmcdaQDmPjK7GWOwh+2Vgd0C2bzQZFAEeOhjeJYCc2Nw@mail.gmail.com \
    --to=jesse.a.deguire@gmail.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).