That's very interesting indeed. I too observed a segfault when trying to use the fastermdct patch on top of a libtremor used by an MPD server but couldn't pinpoint the reason. That's one of the reasons this patch hasn't hit upstream Tremor.
I know the code well but that line seems very mysterious (I.e. harmless - it should work unless something has corrupted the stack/address pointer, I think). Can any arm gurus see if I am misusing any registers in a way that prevents shared library usage, or anything along those lines? > Hi all! > > For some time I have been using tremor with fastermdct patch found on > http://www.rockbox.org/wiki/FasterMDCT. This patch gives huge speedup on > i686/x86_64 machines and smaller, but still significant, speedup on ARM. > > Everything works great until I compile tremor on ARM with -fPIC flag (I link > tremor into a shared object). In such case it segfaults in macro TRANSFORM_EQUAL > in file fft-ffmpeg_arm.h at line 158: > > asm volatile( "ldmia %[my_z], {%[t5],%[t6]}\n\t":[t5] "=r" (t5), [t6] "=r" > (t6):[my_z] "r" (z));\ > > When I compile tremor without -fPIC or with -U_ARM_ASSEM_, there is no segfault. > Tremor without fastermdct.patch also doesn't have this problem. > > I tried debugging the code for a moment, but this code (MDCT + > #defines + lots of > assmebly) is completely incomprehensible to me. > > Unfortunately, I don't have gdb built for this platform (I managed to find the > problematic line with `fprintf(stderr, ...)`, which itself could change the way > it segfaults). At first sight all variables are initialized to proper values. > > The ARM processor I'm using is (according to /proc/cpuinfo): > > Processor : ARMv6-compatible processor rev 4 (v6l) > CPU implementer : 0x41 > CPU architecture: 6TEJ > CPU variant : 0x0 > CPU part : 0xb36 > CPU revision : 4 > Hardware : Freescale MX31/MX32 3-Stack Board > > > Can you help me handle this issue? > > -- > regards, > Slawomir Testowy
