[Bug lto/87698] [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot com Resolution|--- |MOVED --- Comment #8 from H.J. Lu --- This is a linker bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23818
[Bug lto/87698] [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-24 CC||hjl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Richard Biener --- Confirmed. The linker resolution fed to the WPA stage is the same. The issue goes away when not using -g or when using gold as the linker. HJ, this looks like a BFD linker issue to me - not sure where that .dynsym for 'f' comes from. It looks like being a left-over from the fat object part but it's weird that it only happens with -g (maybe the fat debug somehow keeps it live). There is a .rela.text relocation in test2.o (fat) to f. But a ABS dynsym is weird in any case.
[Bug lto/87698] [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698 --- Comment #6 from Romain Geissler --- Versions of gcc and ld: > gcc --version gcc (GCC) 8.2.1 20181011 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > ld --version GNU ld (GNU Binutils) 2.31.1.20181011 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty.
[Bug lto/87698] [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698
--- Comment #5 from Romain Geissler ---
Reduced test case:
> cat test.c
void f() {}
> cat test2.c
void f();
void g()
{
f();
}
> cat test.ver
{
local: *;
};
> gcc -g -flto -ffat-lto-objects -fPIC -o test.fat-objects.o -c test.c
> gcc -g -flto -ffat-lto-objects -fPIC -o test2.fat-objects.o -c test2.c
> gcc -g -flto -ffat-lto-objects -fPIC -shared -o test.fat-objects.so
> test.fat-objects.o test2.fat-objects.o -Wl,-version-script=test.ver
> gcc -g -flto -fno-fat-lto-objects -fPIC -o test.slim-objects.o -c test.c
> gcc -g -flto -fno-fat-lto-objects -fPIC -o test2.slim-objects.o -c test2.c
> gcc -g -flto -fno-fat-lto-objects -fPIC -shared -o test.slim-objects.so
> test.slim-objects.o test2.slim-objects.o -Wl,-version-script=test.ver
> readelf -a test.fat-objects.so|grep ABS
5: 0 NOTYPE GLOBAL DEFAULT ABS f <--- unexpected
symbol here
29: 0 FILELOCAL DEFAULT ABS crtstuff.c
37: 0 FILELOCAL DEFAULT ABS
40: 0 FILELOCAL DEFAULT ABS crtstuff.c
42: 0 FILELOCAL DEFAULT ABS
77: 0 FILELOCAL DEFAULT ABS
> readelf -a test.slim-objects.so|grep ABS
29: 0 FILELOCAL DEFAULT ABS crtstuff.c
37: 0 FILELOCAL DEFAULT ABS
40: 0 FILELOCAL DEFAULT ABS crtstuff.c
42: 0 FILELOCAL DEFAULT ABS
65: 0 FILELOCAL DEFAULT ABS
[Bug lto/87698] [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698 --- Comment #4 from rguenther at suse dot de --- On Tue, 23 Oct 2018, romain.geissler at amadeus dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698 > > --- Comment #3 from Romain Geissler --- > Well I might not understand everything but no I don't think I am comparing > uncomparable things. > > I never build/link with -fno-lto, -flto is *always* provided. OK, so both libraries do not contain LTO bytecode then. Indeed there should be zero differences in that case. A (smaller) testcase showing such differences would be appreciated.
[Bug lto/87698] [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698 --- Comment #3 from Romain Geissler --- Well I might not understand everything but no I don't think I am comparing uncomparable things. I never build/link with -fno-lto, -flto is *always* provided. See for example the case with fat objects: compile command line is: libtool: compile: gcc -DHAVE_CONFIG_H -I../include -I../src -I/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/OpenSSL/ssl/latest/osp/include -I/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/OpenSSL/crypto/latest/osp/include -I/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/ZLib/latest/osp/include -std=gnu11 -fno-working-directory -ggdb3 -flto -ffat-lto-objects -fuse-linker-plugin -I/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/OpenSSL/ssl/latest/osp/include -I/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/OpenSSL/crypto/latest/osp/include -I/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/ZLib/latest/osp/include -MT openssl.lo -MD -MP -MF .deps/openssl.Tpo -c openssl.c -fPIC -DPIC -o .libs/openssl.o link command line is: libtool: link: gcc -shared -fPIC -DPIC .libs/channel.o .libs/comp.o .libs/crypt.o .libs/hostkey.o .libs/kex.o .libs/mac.o .libs/misc.o .libs/packet.o .libs/publickey.o .libs/scp.o .libs/session.o .libs/sftp.o .libs/userauth.o .libs/transport.o .libs/version.o .libs/knownhost.o .libs/agent.o .libs/openssl.o .libs/pem.o .libs/keepalive.o .libs/global.o -Wl,-rpath -Wl,/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/OpenSSL/ssl/latest/osp/lib -Wl,-rpath -Wl,/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/ZLib/latest/osp/lib -L/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/OpenSSL/ssl/latest/osp/lib -lssl -lcrypto -L/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/ZLib/latest/osp/lib -lz -L/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/OpenSSL/crypto/latest/osp/lib -ggdb3 -flto -fuse-linker-plugin -g -O3 -ggdb3 -flto -fuse-linker-plugin -Wl,-soname -Wl,libssh2.so.1 -Wl,-version-script -Wl,.libs/libssh2.ver -o .libs/libssh2.so.1.0.1
[Bug lto/87698] [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698 Richard Biener changed: What|Removed |Added Keywords||lto CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Aren't you comparing apples and oranges? A shared library build with -flto -ffat-lto-objects but linked with -fno-lto will produce a shared library as built _without_ -flto but with LTO bytecode sections. A shared library build with -flto -fno-fat-lto-objects will be a shared library as built with -flto. So of course the actual shared library .text will differ?
[Bug lto/87698] [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698 --- Comment #1 from Romain Geissler --- Note: this is the source of the following error when linking with ld.lld 7.0: ld.lld: error: corrupt input file: version definition index 0 for symbol _libssh2_ntohu32 is out of bounds >>> defined in >>> /projects/combld/delivery/continuous/components.osp/osp/SSH2/18-0-0-0/lib/x86_64-2.6.32-v4/Debug/libssh2.so Don't know if this particular behavior is a ld.lld bug though, I actually don't expect these symbols to be even defined in the final libssh2.so.
