On Thu, Mar 26, 2020 at 1:26 PM Adrian Bunk <[email protected]> wrote: > > On Thu, Mar 26, 2020 at 12:53:08PM -0700, Andre McCurdy wrote: > > On Thu, Mar 26, 2020 at 12:16 PM Adrian Bunk <[email protected]> wrote: > > > > > > On Thu, Mar 26, 2020 at 05:26:29PM +0200, Stefan Ghinea wrote: > > > >... > > > > When compiling for Thumb or Thumb2, frame pointers _must_ be disabled > > > > since the Thumb frame pointer in r7 > > > >... > > > > > > How are you reproducing the problem in pulseaudio? > > > > > > This sounds like a workaround for a bug in musl that was fixed 2 years > > > ago. > > > > The problem can show up anywhere that inline asm is trying to use r7. > > In this case it looks like: > > > > > > https://github.com/pulseaudio/pulseaudio/blob/master/src/pulsecore/remap_neon.c#L50 > >... > > After looking at the pulseaudio code I suspected the patch description > claiming pulseaudio syscall code would be the problem was rubbish, and > that this NEON code was the problem.
Yes, the comment looks like it was copied and pasted and doesn't really apply in this case (since pulseaudio isn't making syscalls). That should be updated. > But when I tried to reproduce the problem it built for me with both > glibc and musl in master (the patch didn't mention that this was a > musl-only problem). > > Then I saw that this was fixed in musl upstream 2 years ago: > https://git.musl-libc.org/cgit/musl/commit/?id=e3c682ab5257aaa6739ef242a9676d897370e78e Right, it's not related to musl or glibc. I suspect it can be reproduced by building for an ARM target which supports NEON, ensuring that DEFAULTTUNE doesn't forcefully disable Thumb (e.g. it should be armv7vethf-neon, not armv7vehf-neon), setting ARM_INSTRUCTION_SET to thumb and then compiling with frame pointers enabled (e.g. by adding -fno-omit-frame-pointer to CFLAGS). In terms of a fix, then changing the code to use r12 instead of r7 is probably the best solution (assuming it works), but would need careful testing. Appending -fomit-frame-pointer to CFLAGS for ARM machines building for Thumb is safe and should fix the issue too. Presumably limiting the -fomit-frame-pointer workaround to ARM machines which support NEON building for Thumb would be an even more targeted solution.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#136786): https://lists.openembedded.org/g/openembedded-core/message/136786 Mute This Topic: https://lists.openembedded.org/mt/72566057/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
