Re: LTO and version scripts
On Wed, Aug 6, 2014 at 11:07 PM, Alan Modra wrote: > Both Fedora 19 and 20 have the patch needed for this to work. Hmm, I > suppose the other thing necessary is a gcc that implements > LDPT_GET_SYMBOLS_V2. You may be lacking that. Here's what I see with > mainline gcc and ld. It's been a while since I tried it and this was a larger project. I can confirm that with the current binutils on Fedora 19 it does work as expected. I'll keep an eye out for this.
Re: LTO and version scripts
On Tue, Aug 05, 2014 at 08:18:06PM -0400, Ulrich Drepper wrote:
> On Tue, Aug 5, 2014 at 12:57 AM, Alan Modra wrote:
> > What version linker? In particular, do you have the fix for PR12975?
>
> The Fedora 19 version. I think it hasn't changed since then which
> means it is 2.23.88.0.1-13 (from the RPM version number). No idea
> whether that fix is included and unfortunately won't have time to try
> before the weekend.
Both Fedora 19 and 20 have the patch needed for this to work. Hmm, I
suppose the other thing necessary is a gcc that implements
LDPT_GET_SYMBOLS_V2. You may be lacking that. Here's what I see with
mainline gcc and ld.
cat > ltoshare.c <<\EOF
int
cond (void)
{
return 0;
}
extern void something (void);
int
main (void)
{
if (cond ())
something ();
return 0;
}
EOF
cat > ltoshare.ver <<\EOF
{
global: main;
local: *;
};
EOF
~/build/gcc-current/gcc/xgcc -B ~/build/gcc-current/gcc/ -B ld/tmpdir/ld -O2
-fPIC -flto -c ltoshare.c
~/build/gcc-current/gcc/xgcc -B ~/build/gcc-current/gcc/ -B ld/tmpdir/ld
-shared -flto -o ltoshare.so ltoshare.o
nm -D ltoshare.so | grep something
U something
~/build/gcc-current/gcc/xgcc -B ~/build/gcc-current/gcc/ -B ld/tmpdir/ld
-shared -flto -o ltoshare.so ltoshare.o -Wl,--version-script=ltoshare.ver
nm -D ltoshare.so | grep something
--
Alan Modra
Australia Development Lab, IBM
Re: LTO and version scripts
On Tue, Aug 5, 2014 at 12:57 AM, Alan Modra wrote: > What version linker? In particular, do you have the fix for PR12975? The Fedora 19 version. I think it hasn't changed since then which means it is 2.23.88.0.1-13 (from the RPM version number). No idea whether that fix is included and unfortunately won't have time to try before the weekend.
Re: LTO and version scripts
> What version linker? In particular, do you have the fix for PR12975? It seems to work with gold and the LLVM plugin. I have added a test to make sure it stays that way: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140804/229493.html Cheers, Rafael
Re: LTO and version scripts
On Mon, Jul 07, 2014 at 11:04:17AM +0200, Richard Biener wrote: > On Mon, Jun 30, 2014 at 2:35 PM, Ulrich Drepper wrote: > > Using LTO to create a DSO works fine (i.e., it performs the expected > > optimizations) for symbols which are marked with visibility > > attributes. It does not work, though, when the symbol is not > > restricted in its visibility in the source file but instead is > > prevented from being exported from the DSO by a version script (ld > > --version-script=FILE). > > > > Is this known? I only found general problems related to linker > > scripts although version script parameters do not cause any other > > failures. > > Yes, I've run into this as well. IMHO the issue is that the linker(s) > do not process the linker script "properly" when handing off > the resolution data to the linker plugin. So it's a linker bug AFAIU. What version linker? In particular, do you have the fix for PR12975? -- Alan Modra Australia Development Lab, IBM
Re: LTO and version scripts
On Mon, Jun 30, 2014 at 2:35 PM, Ulrich Drepper wrote: > Using LTO to create a DSO works fine (i.e., it performs the expected > optimizations) for symbols which are marked with visibility > attributes. It does not work, though, when the symbol is not > restricted in its visibility in the source file but instead is > prevented from being exported from the DSO by a version script (ld > --version-script=FILE). > > Is this known? I only found general problems related to linker > scripts although version script parameters do not cause any other > failures. Yes, I've run into this as well. IMHO the issue is that the linker(s) do not process the linker script "properly" when handing off the resolution data to the linker plugin. So it's a linker bug AFAIU. Richard.
