[Ffmpeg-devel] Re: [Ffmpeg-cvslog] r8420 - trunk/libavcodec/dv.c

[Uoti Urpala]

On Sun, 2007-03-25 at 18:34 -0500, Rich Felker wrote:
> On Sun, Mar 25, 2007 at 03:40:22PM +0300, Uoti Urpala wrote:
> > The de facto ABI on current Linux is 16 byte stack alignment.
> 
> De facto my ass. ANY i386 ELF or a.out .o file is usable on current
> Linux, and may in fact be present. Just because no such objects come
> with your latest fedora/gentoo/ubuntu/whatever doesn't mean that you
> can pretend they don't exist.

Such files may exist somewhere. Trying to use them in various ways may
or may not work. That doesn't really affect my point.

>  The i386 ABI has 4 byte alignment.
> Period. This is all you can assume.

For what values of "can"? You can assume more, and have high likelihood
of that assumption working better than assuming just 4.

> > I think the only sane way to work with the current gcc is to assume that
> > the stack _will_ be 16-byte aligned inside FFmpeg. If there are problems
> 
> This is blatently incorrect though, and not dependent on gcc.

"incorrect" how? Do you understand what I was actually suggesting? More
about that below.

>  Even if
> you use gcc 4.x, my crt0/libc does not align the stack, and will not
> align the stack, ever. It's wasteful and stupid.

Your implementation is pretty much irrelevant. And gcc does explicitly
align stack when entering main() (I'm not sure since what version - at
least it does that in 4.1 already even though the user-settable
attribute for other functions only appears in 4.2). So if all the code
is compiled with gcc the stack will be aligned whatever broken code runs
before starting main().

>  You can't just make
> nonportable assumptions based on what one OS does incestuously with
> latest gcc.

It's more than "what one OS does". And I'm not assuming that just
relying on stack alignment would work without problems everywhere. In
the part of my message you snipped I explicitly talked about potential
problems, most likely occurring when called by external programs on
Windows. My point is that it's better to deal with those problems by
ensuring stack alignment while running FFmpeg code (for example by using
the gcc 4.2+ attributes, or clumsier ways with older compilers) rather
than by adding slower workarounds everywhere alignment is needed (and
likely missing some cases, especially if gcc increases the amount of
alignment-requiring code it generates automatically).