FTBFS on i386 in quantal
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SDL_gfx |
Unknown
|
Unknown
|
|||
libsdl-perl (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
sdlgfx (Debian) |
Fix Released
|
Unknown
|
|||
sdlgfx (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
libsdl-perl fails on i386 in quantal due to a test failure:
# Failed test 'MMX_detect (MMX is same as at start)'
# at t/gfx_imagefilter.t line 53.
# got: '1'
# expected: '0'
# Looks like you failed 1 test of 8.
t/gfx_imagefilter.t .............
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/8 subtests
Which is really a failure in sdlgfx's SDL_imageFilter
Its code is:
asm volatile ("pusha \n\t" "mov %1, %%eax \n\t" /* request feature flag */
"cpuid \n\t" /* get CPU ID flag */
"mov %%edx, %0 \n\t" /* move result to mmx_bit */
"popa \n\t":"=m" (flags) /* %0 */
:"i"(0x00000001) /* %1 */
);
And when I write a test program, whether that assembly happens to be inside a function or not affects its output. Which seems bad. The following assembly that I found online [1] seems more robust:
#define cpuid(func,
__asm__ __volatile__ ("cpuid":\
"=a" (ax), "=b" (bx), "=c" (cx), "=d" (dx) : "a" (func));
int a, b, c, d;
cpuid(1, a, b, c, d);
But I don't know enough assembly to propose a patch to the original code or explain why it is failing.
[1] http://
Changed in libsdl-perl (Ubuntu): | |
status: | New → Invalid |
affects: | libsdl-perl (Debian) → sdlgfx (Debian) |
Changed in sdlgfx (Debian): | |
status: | Unknown → Fix Released |
Disassembly of the _cpuFlags function on i386:
Dump of assembler code for function _cpuFlags:
=> 0xf7425030 <+0>: sub $0x10,%esp
0xf7425033 <+3>: pusha
0xf7425034 <+4>: mov $0x1,%eax
0xf7425039 <+9>: cpuid
0xf742503b <+11>: mov %edx,0xc(%esp)
0xf742503f <+15>: popa
0xf7425040 <+16>: mov 0xc(%esp),%eax
0xf7425044 <+20>: add $0x10,%esp
0xf7425047 <+23>: ret
The problem here is that popa modifies the stack pointer, so at +16 when we try to copy back off the stack into %eax, we're copying from the wrong place - pulling an arbitrary value off the stack.
I've prepared a patch for sdlgfx that appears to correct this.