Hi, 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. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
