"Ronald S. Bultje" <[email protected]> writes: > Hi, > > 2012/1/9 Måns Rullgård <[email protected]>: >> "Ronald S. Bultje" <[email protected]> writes: >>> 2012/1/9 Måns Rullgård <[email protected]>: >>>> "Ronald S. Bultje" <[email protected]> writes: >>>>> Fixes bug 78. I'd normally prefer a -mno-red-zone per-function >>>>> attribute, but it seems gcc doesn't support that yet (it's not in the >>>>> docs, and trying what should work extrapolating from other -m options >>>>> generated compiler errors saying it didn't recognize that attribute). >>>>> >>>>> Sean confirmed it fixes the crash. >>>>> >>>>> Ronald >>>>> >>>>> From 9908ee0200ee3911452f10c6214d9ba0425b1da7 Mon Sep 17 00:00:00 2001 >>>>> From: Ronald S. Bultje <[email protected]> >>>>> Date: Sun, 20 Nov 2011 15:54:15 -0800 >>>>> Subject: [PATCH] swscale: fix crash in fast_bilinear code when compiled >>>>> with -mred-zone. >>>>> >>>>> --- >>>>> libswscale/x86/swscale_template.c | 48 >>>>> +++++++++++++++++++++++++++++++++++++ >>>>> 1 files changed, 48 insertions(+), 0 deletions(-) >>>>> >>>>> diff --git a/libswscale/x86/swscale_template.c >>>>> b/libswscale/x86/swscale_template.c >>>>> index 5e7df5c..c6d7e98 100644 >>>>> --- a/libswscale/x86/swscale_template.c >>>>> +++ b/libswscale/x86/swscale_template.c >>>>> @@ -1656,10 +1656,22 @@ static void RENAME(hyscale_fast)(SwsContext *c, >>>>> int16_t *dst, >>>>> #if defined(PIC) >>>>> DECLARE_ALIGNED(8, uint64_t, ebxsave); >>>>> #endif >>>>> +#if ARCH_X86_64 >>>>> + DECLARE_ALIGNED(8, uint64_t, retsave); >>>>> +#endif >>>>> >>>>> __asm__ volatile( >>>>> #if defined(PIC) >>>>> "mov %%"REG_b", %5 \n\t" >>>>> +#if ARCH_X86_64 >>>>> + "mov -8(%%rsp), %%"REG_a" \n\t" >>>>> + "mov %%"REG_a", %6 \n\t" >>>>> +#endif >>>>> +#else >>>>> +#if ARCH_X86_64 >>>>> + "mov -8(%%rsp), %%"REG_a" \n\t" >>>>> + "mov %%"REG_a", %5 \n\t" >>>>> +#endif >>>> >>>> This is broken. The compiler is perfectly free to allocate "retsave" in >>>> the red zone, even in the very location you are trying to save. >>> >>> But it wouldn't matter. >>> >>> First of all, we do a call. The called function doesn't call other >>> function, is pure assembly and doesn't use stack. So we only worry >>> about the ptrsize bytes taken up by the return address in the call >>> itself. >>> >>> Then, for these bytes, three options exist for the ptrsize bytes >>> present in the call return address before we do the call: >>> A) it is irrelevant memory. We don't care what it does. >>> B) it is retsave itself. See A). >>> C) it is important memory of a variable we want to save. If so, this >>> is not retsave. Thus, we can save it in retsave (regardless of whether >>> that's above rsp or somewhere below in the deeper red zone), pop later >>> and voila, the memory was restored properly. >>> >>> Now, I fully agree that it's a hack. It's commented as such. It will >>> disappear when ported to yasm. But, porting to yasm takes time and the >>> code should work now. So I'd like to apply this as a temp workaround. >> >> Just disable this nasty code for x86_64 then. > > It works with the workaround.
But the workaround is horrible. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
