Re: [musl] Musl on Cortex-M Devices

[Jesse DeGuire <jesse.a.deguire@gmail.com>]

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

This version fixes a few warnings, fixes some CRLF line endings, and
changes the syscall variant of "__a_gettp" to a C function that uses
the __syscall() macro instead of hardcoded assembly. That last change
was done to better take advantage of what Musl already provides and
because it will let me more easily handle the thread pointer should I
make a "baremetal" target.

On another note, I notice that other thread subjects are tagged with
things like "[musl]" or "[patch]". Am I supposed to add those or is
OpenWall supposed to do that? The former seems rather redundant to me,
but the latter does make sense.

On Tue, Jan 5, 2021 at 11:01 PM Patrick Oppenlander
<patrick.oppenlander@gmail.com> wrote:
>
> On Wed, Jan 6, 2021 at 2:25 PM Jesse DeGuire <jesse.a.deguire@gmail.com> wrote:
> > >
> > > Sorry, I missed this reply.
> > >
> > > qemu-user refuses to translate the instruction because cp15 is not
> > > implemented on armv7-m, exactly the same issue as is being discussed
> > > here. If you run the same executable but tell qemu to emulate an A
> > > profile core instead it happily runs it.
> > >
> > > Linux will probably kill the executable with SIGILL or something like
> > > that (I haven't tried, just guessing).
> > >
> > > It's related to this discussion as changing musl to use the syscall
> > > will likely result in qemu-user working too.
> > >
> > > I would personally prefer to see a solution which doesn't use the
> > > syscall. It's possible to implement the trap-and-emulate much more
> > > efficiently than the syscall as it can quite easily be done without
> > > preserving any more registers than the core pushes on exception entry
> > > anyway. https://github.com/apexrtos/apex/blob/master/sys/arch/arm/v7m/emulate.S
> > > is what I came up with. That implementation could be even tighter as
> > > it can never run from handler mode, so the stack detection at the
> > > beginning is unnecessary. However, I haven't considered v6-m or v8-m.
> > >
> > > trap-and-emulate also gracefully degrades when running the same
> > > executable on A vs M cores.
> > >
> > > Patrick
> >
> > Any thoughts on what's shown in this patch? For your RTOS and v7m/v8m,
> > I'm thinking you'd be able to get the behavior you want by setting the
> > HWCAP_TLS flag early in your startup code. For my purposes, I plan to
> > use the syscall because I intend to eventually make a "baremetal" arch
> > in Musl that turns syscalls into simple function calls. Therefore, I'd
> > clear the flag in my startup code.
>
> What you've proposed (using HWCAP_TLS) sounds good to me. Apex tries
> very hard to look like Linux to userspace, so anything that works for
> Linux will work for it. As an aside, I also use a forked and reduced
> musl as the kernel libc - a baremetal target could be handy there.
>
> It might be nice to have a configure option to disable the syscall
> fallback completely (compile time constant test of some kind?) to
> allow inlining of the mrc instruction. If such an executable ever
> tried to run on an unsupported platform it would be killed with an
> invalid instruction exception.
>
> If it's acceptable to have that type of configure-time tuning we can
> also disable mutex & rwlock spins (set spins to 0) as an optimisation
> for uniprocessor targets.
>
> Patrick

I still need to figure out how I want to really handle a baremetal
target, though it does seem like Musl makes adding targets relatively
easy to add. I also don't mind adding more compile-time configuration
options, but I'll leave whether I should or not up to others. I
noticed that Musl doesn't really have those (except when needed to
figure out architecture variants), so I'm not sure if avoiding such
checks is part of an overall policy for Musl.

-Jesse

[-- Attachment #2: musl_cortexm_v4.patch --]
[-- Type: application/x-patch, Size: 13959 bytes --]