[Ffmpeg-devel] Re: [Ffmpeg-cvslog] r8420 - trunk/libavcodec/dv.c
Roman Shaposhnik
rvs
Sun Mar 25 05:47:27 CEST 2007
On Sun, 2007-03-25 at 13:04 +1000, John Dalgliesh wrote:
> It works for me on my platform (x86, Mac OS X, gcc 4.0.1 (Apple)). The
> problem does not seem to occur on linux. The reporter of the bug was on
> Mac OS X too IIRC.
Well, it could accidentally work -- I guess you really have to see
what assembly code was generated for the function prologue to make
sure (although since the function is inline it gets a bit more
complicated). Here's a test of gcc 4.0.2:
$ cat q.c
#define TEST(x) int foo##x(char i) { volatile char a[128] \
__attribute__((aligned(x))); a[0] = i; }
TEST(8)
TEST(16)
TEST(32)
$ gcc -S -O2 q.c
$ cat q.s
....
foo8:
pushl %ebp
movl %esp, %ebp
addl $-128, %esp
movl 8(%ebp), %eax
movb %al, -128(%ebp)
leave
ret
....
foo16:
pushl %ebp
movl %esp, %ebp
subl $136, %esp
movl 8(%ebp), %eax
movb %al, -136(%ebp)
leave
ret
....
foo32:
pushl %ebp
movl %esp, %ebp
subl $136, %esp
movl 8(%ebp), %eax
movb %al, -136(%ebp)
leave
ret
Which looks rather wrong to me.
> > I see no way of aligning anything on the
> > x86 stack for more than 8.
>
> What do you mean by 'no way'?
Sorry I was more precise in my reply to Rich. I meant there's no way
unless you generate extra code for function prologue re-aligning the
stack.
> The code above should work - the compiler
> should defintiely be able to align something on the stack even when the
> function is called with less alignment. If it hadn't worked I would have
> increased the size of the array to cope with any misalignment and set a
> pointer to the appropriate place... but happily I didn't need to.
I believe it'll be the best way to handle this.
> Also, where do you get that 8 from?
While implementing the same functionality for Sun compilers we've gone
through looking at the code generated by various versions of gcc and
that's where that 8 came from. It could be a bug in a particular version
of gcc, though.
> Anyway, the code should ask for the alignment it actually requires, even
> if the compiler isn't up to it. So IMHO this change is correct. If it
> doesn't work in some places (resulting in bug reports), then we can
> investigate workarounds then.
Well, if we *know* that gcc doesn't do the right thing I see no reason
to rely on the code, but rather pull the same trick manually.
Thanks,
Roman.
More information about the ffmpeg-devel
mailing list