Re: runtime linker on 9.x/i386: clang vs. gcc

[Dimitry Andric]

On Oct 14, 2013, at 22:42, "Mikhail T."  wrote:
> 10/14/13 4:31 PM, Dimitry Andric написав(ла):
>> There is a problem when clang does tail-call optimization on i386 with
>> PIC in effect, and it emits GOT relocations for the tail-called
>> functions, instead of PLT relocations.  In some scenarios, such as with
>> the way X.org does lazy dynamic linking, this can cause problems.  See
>> also 
>> http://llvm.org/PR15086
>>  (which I unfortunately did not get much
>> response on).
>> 
> Ouch... That seems like a show-stopper for clang-adoption... At least, on 
> i386.

Well, the scenario is very difficult to reproduce, at least when I tried
it.  You must have a very specific way of dynamically loading objects,
and you must load them in the "wrong" order, or the problem will not
occur.  Normally linked .so's do not have this problem at all.  So
hardly a showstopper, 10.0 is being released with clang as we speak. :-)


>> For now, a workaround is to recompile the affected .so files with
>> -fno-optimize-sibling-calls (if you are optimizing).
>> 
> Maybe, our clang (both src/ and ports/) should be compiled with that being in 
> effect by default on i386?

For the specific cases where it occurs (as far as I knew until know,
only certain X.org drivers) it might be enough to just use
-fno-optimize-sibling-calls.  If this problem occurs more often, I will
see if I can make it the default for i386-with-PIC.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: runtime linker on 9.x/i386: clang vs. gcc

[Mikhail T.]

10/14/13 4:31 PM, Dimitry Andric ???(??):

There is a problem when clang does tail-call optimization on i386 with
PIC in effect, and it emits GOT relocations for the tail-called
functions, instead of PLT relocations.  In some scenarios, such as with
the way X.org does lazy dynamic linking, this can cause problems.  See
alsohttp://llvm.org/PR15086  (which I unfortunately did not get much
response on).
Ouch... That seems like a show-stopper for clang-adoption... At least, 
on i386.

For now, a workaround is to recompile the affected .so files with
-fno-optimize-sibling-calls (if you are optimizing).
Maybe, our clang (both src/ and ports/) should be compiled with that 
being in effect by default on i386?


   -mi

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: runtime linker on 9.x/i386: clang vs. gcc

[Dimitry Andric]

On Oct 14, 2013, at 18:22, Mikhail T.  wrote:
> I'm seeing a strange problem with clang-compiled binaries on 9.x/i386 system. 
> Here it is: if a shared library A needs a symbol provided by a shared library 
> B, libA will fail to load into a process even if the executable is linked 
> with libB. The only fix (work-around?) is to relink libA to explicitly depend 
> on libB. A temporary work-around is to use LD_PRELOAD to list all of the 
> necessary libBs...
> 
> One example of this is reported in ports/180473 
>  -- the 
> libprldap6.so refuses to load because of the symbols it needs from 
> libnspr4.so. For some reason, the fact, that -lnspr4 is linked into the 
> executable (seamonkey or thunderbird), is not sufficient... As the ticket 
> suggests, using gcc46 (Mozilla rejects gcc-4.2.x nowadays) instead of clang 
> solves the problem (though an even better solution is in place since this 
> weekend).
> 
> Another example is xorg-server, which, for me, can not load some of the 
> drivers because they complain of missing symbols:
> 
>   (EE) Failed to load /opt/lib/xorg/modules/drivers/vboxvideo_drv.so: 
> /opt/lib/xorg/modules/drivers/vboxvideo_drv.so: Undefined symbol 
> "DRIFinishScreenInit"
> 
> The DRIFinishScreenInit is provided by libdri.so, which the server also 
> loads... But, somehow, that is not sufficient. Rebuilding vboxvideo_drv.so 
> (provided by emulators/virtualbox-ose-additions 
> ) with the 
> stock cc (gcc-4.2.1) resolves the linking problem -- even if Xorg executable 
> and the libdri.so remain clang-compiled.
> 
> I am not prepared to argue, whether that's a "right" or "wrong" behavior -- 
> but it certainly is inconsistent, because it is only manifested on i386 and 
> only when the compiler is clang.
> 
> Any thoughts?


There are many possibilities here, and you might be running into
multiple different problems, but the X.org failures look familiar to me.

There is a problem when clang does tail-call optimization on i386 with
PIC in effect, and it emits GOT relocations for the tail-called
functions, instead of PLT relocations.  In some scenarios, such as with
the way X.org does lazy dynamic linking, this can cause problems.  See
also http://llvm.org/PR15086 (which I unfortunately did not get much
response on).

For now, a workaround is to recompile the affected .so files with
-fno-optimize-sibling-calls (if you are optimizing).  This is also the
approach taken for the X.org ports, see
http://svnweb.freebsd.org/ports?view=revision&revision=312583 for the
diff.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail