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

[David DeHaven]

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.

-DrD-