Thank you to anyone who has already donated - your generous donations helped make three months of treatment possible.

My brother Nate continues to fight stage IV Hodgkin's lymphoma. He's just 31, with a wife and baby girl. They have no active income (since he's been unable to return to work), no insurance, and cannot afford the treatment he needs. Nate and his family need your help. Please consider a donation, every dollar helps. Thanks.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
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