[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

--- Comment #12 from Tanu Kaskinen <tanuk at iki.fi> ---
I found out the reason for the get_cpuid() crash. The function looks like this
(slightly edited for readability):

static void get_cpuid(uint32_t op,
                      uint32_t *a, uint32_t *b, uint32_t *c, uint32_t *d) {
    __asm__ __volatile__ (
        "  push %%rbx          \n\t"
        "  cpuid               \n\t"
        "  mov %%ebx, %%esi    \n\t"
        "  pop %%rbx           \n\t"

        : "=a" (*a), "=S" (*b), "=c" (*c), "=d" (*d)
        : "0" (op)
    );
}

When building without optimizations, the function parameters are saved in the
stack. The stack pointer register isn't updated, however, so our push
instruction ends up overwriting the op and a parameters! Before that happens,
the op parameter is saved in the eax register, and the stack memory for op
won't be needed after that, so that's fine, but the a parameter is replaced
with whatever happened to be in the rbx register. When trying to save the cpuid
result in the memory pointed to by a, a segfault happens, because a is an
invalid pointer at that point.

If the stack pointer was updated when the compiler wrote the parameters in the
stack, this would have been avoided. So is this a compiler bug? I'm not sure. I
found out that the AMD64 ABI allows the compiler to not update the stack
pointer in functions that don't call other functions. However, if the stack
pointer is not updated, inline assembly that relies on the stack pointer will
not work as intended (as seen here), so maybe the compiler should always update
the stack pointer if it sees that the function contains inline assembly code
that has push/pop instructions?

This code happens to work on a "normal" 64-bit system by chance, because the
memory layout for the pointers is a bit different, and the push operation will
only overwrite the op parameter, which does no harm. When building with
optimizations, I guess the function parameters aren't saved in the stack, so
that will also avoid the crash.

I guess I'll have to prepare a bug report for GCC next (I'm not sure if it's a
compiler bug, but hopefully they'll tell me).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pulseaudio-bugs/attachments/20170118/f319ca69/attachment-0001.html>