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 10968 invoked from network); 6 Jan 2021 04:01:30 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 6 Jan 2021 04:01:30 -0000 Received: (qmail 32563 invoked by uid 550); 6 Jan 2021 04:01:28 -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 32542 invoked from network); 6 Jan 2021 04:01:28 -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=qVU4RP/oFbda2usKsIp2FgBuQ/Z5d2GDoUvA5daf1PE=; b=f7J5ycz+fuIV2GdvEMD66EH1W+ulvs29oXr2kGn+XXgpwYVyR5Y43t0yZJb3QQf6nk kbRXryZ6qDK9jem/08jUuEBGGyPhELySAdBzrBxs7RKSOdkihHPjXSIqkwe1vrHImhsr nk8jp4e5VCkqifwl229kR1l5bXaz5jdPruZ5KsF8AD6D4Ia7kX/zFQro68gM/LKzbBdc H9W3rEZryNISWL1M+fv+oZ42aZotWJ+iToAgbkKhHkUiXBG6OhOqpXXDk01kKBXnXRzp LU8Q1nOrMc4Z4YtYQV4Ve+qvh+Fd+Kzw5Vm+gcba9icssAohr4ZnyE+MZSaSSQqE099U iebg== 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=qVU4RP/oFbda2usKsIp2FgBuQ/Z5d2GDoUvA5daf1PE=; b=ItOgbHt80UC2WLOXvjRXCxgJek5Acvot6ILeaJnqM1vDesX6HiqSANs96DbaRIZ4Px gykjbDi0UtlVCVEmZxFkg/Uq/rUpT+batQ5mDnz46qVygVSqPoZowcVQ6mGhCPjHN64e FA5MawR9R2fSS1EYq0Qh4JEOnfIy0eaQMiCY2uUX3uemUc56Qas0xPWvYKSxVPPRu4rj +R/igG0QKA0yX0GapunM8bcrUfgcmzRciCty59v7zhTufjUzXmT5wAmd8HJXS0WwJSdW 2BiBk7EQxosrxZpIbluhXscsj8daMQbDIOaElggKhqRvVVTh8yxr35QxMIwGUyfKHcxE K2mQ== X-Gm-Message-State: AOAM533qd1AOaEaZRDG53qHpry//q3kLPcvvcdgXOMdOvBusJfizQ71p pd3GY+8edk8kU7AXSi2GHxongn57zIWMw+GEXpg= X-Google-Smtp-Source: ABdhPJwPeLn2yaccH5yfVVehIt+aJaHeQG7Vqc+/lyYIRK6kKX5Xj+oP7dGb8NAa+89DSJ7hVVyKrltMkP5HEBd5dY4= X-Received: by 2002:a17:906:d9c7:: with SMTP id qk7mr1670637ejb.384.1609905676504; Tue, 05 Jan 2021 20:01:16 -0800 (PST) MIME-Version: 1.0 References: <20201217002348.GO534@brightrain.aerifal.cx> In-Reply-To: From: Patrick Oppenlander Date: Wed, 6 Jan 2021 15:01:05 +1100 Message-ID: To: Jesse DeGuire Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] Musl on Cortex-M Devices On Wed, Jan 6, 2021 at 2:25 PM Jesse DeGuire 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