[Android] [PATCH 5/8] contrib: ffmpeg: Use --extra-cflags='-mincoming-stack-boundary=4'

[Martin Storsjö]

On Wed, 25 Jul 2012, Rafaël Carré wrote:

> Le 2012-07-25 11:53, Martin Storsjö a écrit :
>> On Wed, 25 Jul 2012, Rafaël Carré wrote:
>>
>>> Le 2012-07-25 11:44, Martin Storsjö a écrit :
>>>> On Wed, 25 Jul 2012, Rafaël Carré wrote:
>>>>
>>>>> Le 2012-07-25 04:51, Edward Wang a écrit :
>>>>>> The issue here is that android-x86 doesn't guarantee an aligned stack, which means some of the inline asm functions will waste an extra register on realigning the stack.
>>>>>>
>>>>>> libavcodec does however have stuff in place in all entrypoints that realign the stack on all calls into the library. If you build with --extra-cflags='-mincoming-stack-boundary=4', gcc assumes that the stack actually is aligned already, which the entry points ensure, so this inline asm builds fine.
>>>>>>
>>>>>> Pointed-out-by: Martin Storsjö <martin at martin.st>
>>>>>> ---
>>>>>>  contrib/src/ffmpeg/rules.mak |    9 +++++++++
>>>>>>  1 files changed, 9 insertions(+), 0 deletions(-)
>>>>>>
>>>>>> diff --git a/contrib/src/ffmpeg/rules.mak b/contrib/src/ffmpeg/rules.mak
>>>>>> index ed6d8e8..fb069a3 100644
>>>>>> --- a/contrib/src/ffmpeg/rules.mak
>>>>>> +++ b/contrib/src/ffmpeg/rules.mak
>>>>>> @@ -82,6 +82,15 @@ endif
>>>>>>  # Linux
>>>>>>  ifdef HAVE_LINUX
>>>>>>  FFMPEGCONF += --target-os=linux --enable-pic
>>>>>> +
>>>>>> +ifeq ($(ANDROID_ABI), x86)
>>>>>> +ifdef HAVE_ANDROID
>>>>>> +# Android-x86 doesn't guarantee an aligned stack, so we tell gcc to
>>>>>> +# assume that the stack actually is aligned already
>>>>>
>>>>> The comment is a bit misleading, if Android-x86 doesn't guarantee
>>>>> alignement, then we can't assume that the stack is aligned (since it is
>>>>> not).
>>>>
>>>> Not sure if this is an objection against the patch or just the description
>>>> here. The info in the commit message has all the details - libavcodec has
>>>> entry point stuff which makes sure it is aligned on entry, and hopefully
>>>> gcc keeps it aligned across the calls within the library then.
>>>
>>> This was against the description, I think this option forces gcc to
>>> align stack, rather than assume an alignement
>>
>> Perhaps it does both, but for the out of register conditions in inline
>> asm, the critical part is that this tells gcc that the stack is aligned
>> already on entry into the functions, so that gcc doesn't need to waste one
>> register on aligning local stack arrays.
>
> What about this:
>
> # Android-x86 gcc doesn't guarantee an aligned stack, so we tell gcc to
> # align the stack on 16 bytes, so we don't need to waste a precious
> # register in assembly functions to realign it.

Almost - half of the magic is handled by 
__attribute__((force_align_arg_pointer)) which libavcodec has set on all 
entry points into the library already. Without this, we wouldn't be able 
to use -mincoming-stack-boundary safely I think.

So something like this might be good:

# Android-x86 gcc doesn't guarantee an aligned stack, but this is
# handled by __attribute__((force_align_arg_pointer)) in libavcodec 
# already, so we tell gcc to assume this alignment, so we don't need 
# to waste a precious register in assembly functions to realign it.

Not sure if we'd have to say assume/keep or if assume is enough, I don't 
know gcc well enough to know what it does by default in this case...

// Martin