[FFmpeg-cvslog] r11202 - trunk/configure

Måns Rullgård mans
Wed Dec 12 11:58:56 CET 2007


Michael Niedermayer wrote:
> On Wed, Dec 12, 2007 at 09:33:07AM +0000, M?ns Rullg?rd wrote:
>> Rich Felker <dalias at aerifal.cx> writes:
>>
>> > On Tue, Dec 11, 2007 at 09:02:09PM +0100, mru wrote:
>> >> Author: mru
>> >> Date: Tue Dec 11 21:02:09 2007
>> >> New Revision: 11202
>> >>
>> >> Log:
>> >> do not create copy relocations when linking to shared libs
>> >>
>> >>
>> >> Modified:
>> >>    trunk/configure
>> >>
>> >> Modified: trunk/configure
>> >> ==============================================================================
>> >> --- trunk/configure	(original)
>> >> +++ trunk/configure	Tue Dec 11 21:02:09 2007
>> >> @@ -1737,6 +1737,7 @@ enabled extra_warnings && check_cflags -
>> >>  check_ldflags -Wl,--warn-common
>> >>  check_ldflags $LDLATEFLAGS
>> >>  check_ldflags -Wl,-Bsymbolic
>> >> +check_ldflags -Wl,-z,nocopyreloc
>> >
>> > IMO this is a bad commit message. It does not tell the reason why the
>> > change was made, which I'm actually very curious about. Did this fix
>> > the weird bug after -Bsymbolic was added, and if so, how/why? I assume
>> > it must be working around some strange binutils bug...
>>
>> It could be considered a binutils bug, but I'm sure the binutils devs
>> would disagree.
>>
>> The problem arises when a non-PIC main executable references global
>> data in a shared library.  If the compiler, as is typical on x86-64,
>> uses a 32-bit offset to access the data, a simple text relocation will
>> not work if the offset after dynamic linking would need more than 32
>> bits.  Instead a copy relocation is created, whereby the dynamic
>> linker copies the global symbol to a position within range of the
>> non-PIC reference, and patches up the shared lib GOT to reference this
>> instead of the original location in the lib, redirecting accesses from
>> the lib to the newly made copy.
>>
>> With -Bsymbolic, intra-library accesses do not use the GOT, and the
>> executable and lib end up using different copies of the same symbol.
>> The -z nocopyreloc flag tells the linker not to create such copy
>> relocations, but rather a normal text relocation.  As we all know,
>> text relocations on x86-64 don't work very well (hard to fit a 64-bit
>> offset in a 32-bit space), so we must build the main executable as PIC
>> as well.  If we do this, the main GOT is pointed at the library symbol
>> (instead of the opposite), and everything works as intended.
>
> yes, alternative solutions would be
>
> somehow force accesses to the 5 global exported and non const variables
> to go through the GOT (i think this could be achived with linker scripts)

No, the type of access is determined by the compiler.

> change the API so we dont have any global exported and non const variables

Yes, those few variables shouldn't really be exported.  The first_avcodec
and friends can already be accessed by alternate means, and the rest are
ugly hacks that should go away regardless.

> also i think (or hope at least) that not the whole application must now
> be PIC but rather just the file(s) accessing global exported and non const
> variables from lavc*

The minimum requirement is that accesses to those variables be done in
a way that permits runtime relocations.  For x86-64 this means going
through the GOT, and the easiest way to achieve this is to compile the
relevant modules as PIC.  Files that do not access the affected variables
need no special treatment.

-- 
M?ns Rullg?rd
mans at mansr.com




More information about the ffmpeg-cvslog mailing list