[FFmpeg-devel] [PATCH] put dispatch_tab* in .data (was Re: Build problem)

[Alexander Strange]

On Feb 11, 2009, at 2:58 PM, David DeHaven wrote:

>
> On Feb 11, 2009, at 11:37 AM, Alexander Strange wrote:
>
>>
>> On Feb 11, 2009, at 11:13 AM, Diego Biurrun wrote:
>>
>>> On Sun, Feb 08, 2009 at 07:10:33PM +0100, Dominik 'Rathann'
>>> Mierzejewski wrote:
>>>> On Wednesday, 04 February 2009 at 11:00, Reimar D?ffinger wrote:
>>>>> On Wed, Feb 04, 2009 at 09:25:46AM +0000, M?ns Rullg?rd wrote:
>>>>>> Art Clarke <aclarke at xuggle.com> writes:
>>>>>>
>>>>>>> I installed yasm on our Mac build boxes today, and noticed the
>>>>>>> following error doing x86_64 builds:
>>>>>>>
>>>>>>>>> ld: pointer in read-only segment not allowed in slidable
>>>>>>>>> image, used in dispatch_tab_sse from libavcodec/x86/fft_mmx.o
>>>>>>>
>>>>>>> I was wondering if people already knew why this occurs (a
>>>>>>> perusal of
>>>>>>> the archives suggested not).  If I don't have yasm installed or
>>>>>>> available on the path the build works fine.  Any thoughts or
>>>>>>> anyone
>>>>>>> else seeing this?
>>>>>>
>>>>>> Yes, Apple is stupid as usual.  What that error message means is
>>>>>> that
>>>>>> it doesn't allow relocations in read-only sections, which is
>>>>>> utterly
>>>>>> silly.
>>>>>
>>>>> Well, in that specific case it might also be because the data gets
>>>>> placed in .text and not .rodata on OSX, supposedly because of
>>>>> alignment
>>>>> issues.
>>>>> Try changing libavcodec/x86/x86inc.asm to use .rodata or .data,
>>>>> maybe
>>>>> one of them work...
>>>>
>>>> FWIW, the original code results in a shared library with text
>>>> relocations
>>>> in read-only segment on x86_64. Putting dispatch_tab* in .rodata
>>>> doesn't
>>>> change that, because both .text and .rodata end up in the same
>>>> segment
>>>> that has READ and EXECUTE bits set. Putting dispatch_tab* in .data
>>>> gets rid of them. IOW, what about the attached patch?
>>>>
>>>> +++ ffmpeg-20090204/libavcodec/x86/fft_mmx.asm	2009-02-08
>>>> 18:51:15.000000000 +0100
>>>> @@ -446,8 +446,9 @@ fft %+ n %+ %3%2:
>>>> %endrep
>>>> %undef n
>>>>
>>>> -align 8
>>>> +section .data
>>>> dispatch_tab%3%2: pointer list_of_fft
>>>> +section .text
>>>
>>> What about this?
>>>
>>> Diego
>>
>> Removing the 'align 8' breaks Darwin again (unless you remove the
>> SECTION_RODATA hack). This one fixes that; I'll apply it after
>> building x86_64 again:
>> <dispatch-tab-rodata.diff>
>
> Keep in mind the section alignment bug affected *all* sections, not
> just rodata... so even if you "align 8" in .data there's no guarantee
> it'll be aligned if your yasm doesn't have the alignment fix. The only
> reason .text was aligned properly is because it's the currently always
> first section created in the object file so it lands at virtual
> address 0.

Yeah, I realized that afterwards. Luckily it's just a performance  
penalty in this case.
I tried it on linux x86-32 and found that the file doesn't even  
compile with PIC, so there's no point in reducing cache locality to  
get a few less text relocations.
So I've commited (nearly) the original patch.