[FFmpeg-cvslog] r11202 - trunk/configure

Michael Niedermayer michaelni
Wed Dec 12 12:18:12 CET 2007


On Wed, Dec 12, 2007 at 10:58:56AM -0000, M?ns Rullg?rd wrote:
> 
> 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.

you missunderstood me i didnt mean the app but the lib, if the lib woul
access these 5 variables so that they are overrideable then there wouldnt
be a problem with copy relocations
a -Bsymbolic NOT first_avcodec, ... is what i meant and i think that can be
achived with linker scripts


> 
> > 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.

iam not opposed to approve a patch which would get rid of these variables and
replace them by some other API where one doesnt exist yet


> 
> > 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.

thats what i thought as well, i just wasnt sure if there wouldnt be other
binutil bugs causing PIC infection

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Thouse who are best at talking, realize last or never when they are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20071212/34136571/attachment.pgp>



More information about the ffmpeg-cvslog mailing list