From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31112 invoked from network); 18 Dec 2020 07:18:14 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 18 Dec 2020 07:18:14 -0000 Received: (qmail 7622 invoked by uid 550); 18 Dec 2020 07:18:12 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 7601 invoked from network); 18 Dec 2020 07:18:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uDUIz2F5fZFoHXGynJC+RSVo2msDd1hWuHXh76SYDoM=; b=kExuIeciNq7b1qXDOB0z0AfkNZq+XfCFfHh80SIt8Xi+pwdZ5klNPSGLECdOt3gOEu y2OVqgZ2oz5Mt3rW1elYYLDbO67GYFuqZhvy1Tuoa+9zpvLBzg8DAfqxNh/1ZxSJgjxZ fch6+BgT77jvopub9MmiO1j5lbj7gO6QGYHcCkiEzB8S+3GiACjCFDWoacK1U290zu6t LbU54BiC64/E309NGSoEnOHsxZ7xhma21exYCELebaxprQokDqKawVBxbcvN2K8IcSOQ jHVMflUX/wFXV7MoUR0+17HCRs3ZpmrtuZY0zFTB2L+s5iYvn/iBhj0Sl1IFELyM4Wpe JR1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uDUIz2F5fZFoHXGynJC+RSVo2msDd1hWuHXh76SYDoM=; b=uJG852w3jtRGGS3tDLFqS85D9+VCn4temPZnfSf4uFuwZYrE3cNu4d7sCcBli9UjJ1 qESyeclvEb2EBetqRUOFbORMh0XeSzgMc3k/0KuiEhG0IyKbSxqVBHRsg2q9o9U19ix2 AdvNppNO4BzPp1nYTc0sSSwLwGhBtF6EaIPwwSymirthn/r0pDPFZ6S16yoMcbdwQVdj +x4dr0Dn4EVQQAqBoNV24Zffc2/49hh59YInOuqQV+A6L7Am/XkEVoPaGGhMH/ricGFP F5JrFqe4Q1kK+EOSFlV8B96YEUfgZAJwz0nVwEJc5G3TK4wKb2srevSNRHy0/NG5IH/h iJog== X-Gm-Message-State: AOAM532iBecMxr+mAC6z13VbCIEwBJX0Nyv/OydeMpX0DrWVmNxhoZ9h FvGZ8QuKclsVc4Q2f3KW2w0Uigt4wQcXwoHv/QDFxKTyLao= X-Google-Smtp-Source: ABdhPJxya1OjUsQ0WwMwy8WilF5B4FVTbt+S/siEzFLMG3ddx3FkF8Txf2Qy/gAxs9Tig/ToR8dGvutsuJxYaVKprY8= X-Received: by 2002:a5e:d70a:: with SMTP id v10mr2685973iom.172.1608275879403; Thu, 17 Dec 2020 23:17:59 -0800 (PST) MIME-Version: 1.0 References: <20201217002348.GO534@brightrain.aerifal.cx> In-Reply-To: From: Jesse DeGuire Date: Fri, 18 Dec 2020 02:17:50 -0500 Message-ID: To: Patrick Oppenlander Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] Musl on Cortex-M Devices On Thu, Dec 17, 2020 at 12:10 AM Patrick Oppenlander wrote: > > On Thu, Dec 17, 2020 at 3:55 PM Patrick Oppenlander > wrote: > > > > On Thu, Dec 17, 2020 at 11:24 AM Rich Felker wrote: > > > > > > On Wed, Dec 16, 2020 at 06:43:15PM -0500, Jesse DeGuire wrote: > > > > 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. > > > > > > I had assumed the thumb1[-ish?] subset wouldn't be interesting, but if > > > it is, let's have a look. > > > > > > > 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. > > > > > > Are there places where clang's linker is failing to make substitutions > > > that the GNU one can do, that would make this simpler? For example I > > > know the GNU one can replace bx rn by mov pc,rn if needed (based on a > > > relocation the assembler emits on the insn). > > > > > > > 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"). > > > > > > Is __ARM_ARCH_ISA_ARM universally available (even on old compilers)? > > > If not this may need an alternate detection. But I'd like to drop as > > > much as possible and just make the code compatible rather than having > > > 2 versions of it. I don't think there are any places where the > > > performance or size is at all relevant. > > > > > > > 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 > > > > > > Unless this is an ISA level that can't be executed on a normal (non-M) > > > ARM profile, it still needs all the backends that might be needed and > > > runtime selection of which to use. This is okay. I believe Linux for > > > nommu ARM has a syscall for get_tp, which is rather awful but probably > > > needs to be added as a backend. The right way to do this would have > > > been with trap-and-emulate (of cp15) I think... > > > > Linux emulates mrc 15 on old -A cores but they decided not to on -M > > for some reason. BTW, the syscall is called get_tls. > > > > Is there any option other than supporting the get_tls syscall? Even if > > someone puts in the effort to wire up the trap-and-emulate backend, > > musl linked executables will still only run on new kernels. > > > > I took the trap-and-emulate approach in Apex RTOS to avoid opening > > this can of worms. It's the only missing link for musl on armv7-m. > > Everything else works beautifully. > > Another consideration is qemu-user: Currently it aborts when > encountering an mrc 15 instruction while emulating armv7-m. I guess > that would probably also be solved by supporting the syscall. > > Patrick ARMv6-M and v8-M.base do not support the MRC instruction at all. Could that play into why Linux and qemu bail? Jesse