On Thu, 2020-03-26 at 14:23 -0700, Andre McCurdy wrote:
> On Thu, Mar 26, 2020 at 1:26 PM Adrian Bunk <b...@stusta.de> 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 <b...@stusta.de> 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.
I finally found time to test fixing the assembly code to use r12
instead of r7. Seems to work fine (I was first baffled by incorrect
behaviour, because I changed "{r4-r7}" to "{r4-r12}" without realizing
that "r4-r12" meant a range of all registers from r4 to r12).
Can you enlighten me: why did you choose r12 instead of r8? Why did the
original author use registers r4-r7 instead of r0-r3? Is it somehow
advisable to avoid registers r0-r3 and r8-r11? The code seems to work
fine with any set of registers, except r7.
--
Tanu
https://www.patreon.com/tanuk
https://liberapay.com/tanuk
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#140750):
https://lists.openembedded.org/g/openembedded-core/message/140750
Mute This Topic: https://lists.openembedded.org/mt/72566057/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
