[Bug ld/16934] New: gc-sections fails to remove unused C++ member functions
https://sourceware.org/bugzilla/show_bug.cgi?id=16934 Bug ID: 16934 Summary: gc-sections fails to remove unused C++ member functions Product: binutils Version: 2.23 Status: NEW Severity: enhancement Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: curaga at operamail dot com Created attachment 7595 --> https://sourceware.org/bugzilla/attachment.cgi?id=7595&action=edit Tarball of the testcase. This is an enhancement request. In ld 2.23.1, gc-sections fails to remove some unused C++ class members. This is causing binaries linked with static C++ libs to be megs larger than they could be. Each function is correctly in a separate section, and is not referenced anywhere in the app. Attaching a reduced testcase, and also posting the code as comments. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/16934] gc-sections fails to remove unused C++ member functions
https://sourceware.org/bugzilla/show_bug.cgi?id=16934
--- Comment #1 from curaga at operamail dot com ---
lib.h:
#ifndef FOO_H
#define FOO_H
class interface {
public:
virtual void foo() = 0;
virtual void bar() = 0;
};
interface* getclass();
#endif
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/16934] gc-sections fails to remove unused C++ member functions
https://sourceware.org/bugzilla/show_bug.cgi?id=16934
--- Comment #3 from curaga at operamail dot com ---
app.cpp:
#include "lib.h"
int main() {
interface *i = getclass();
i->bar();
return 0;
}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/16934] gc-sections fails to remove unused C++ member functions
https://sourceware.org/bugzilla/show_bug.cgi?id=16934
--- Comment #2 from curaga at operamail dot com ---
lib.cpp:
#include
#include "lib.h"
class myclass: public interface {
public:
void foo() { puts("foo"); }
void bar() { puts("bar"); }
};
interface *getclass() {
return new myclass;
}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/15574] Gold is overly pedantic for dynamic references to symbols with hidden visibility
https://sourceware.org/bugzilla/show_bug.cgi?id=15574 John Marino changed: What|Removed |Added CC||binutils at marino dot st --- Comment #1 from John Marino --- Is there a patch or workaround for this? I definitely want to turn off this warning. I'm still seeing this on binutils 2.24 gold linker. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/16936] New: $ORIGIN in shared library's rpath not used to find library dependencies at link time
https://sourceware.org/bugzilla/show_bug.cgi?id=16936
Bug ID: 16936
Summary: $ORIGIN in shared library's rpath not used to find
library dependencies at link time
Product: binutils
Version: 2.23
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: sdvormwa at mtu dot edu
On Linux x86_64, it looks like ld does not respect $ORIGIN when used in a
library's DT_RPATH entry, unlike the runtime loader. This leads to link errors
due to undefined symbols, which the runtime loader can actually find.
Additionally, adding directories to the linker's search path with -L does not
suffice to find these dependent libraries, --rpath-link must be used. A short
example is below:
$ cat lib/libbar.c
int bar( void )
{
return 0;
}
$ cat lib/libfoo.c
extern int bar( void );
int foo( void )
{
return bar();
}
$ cat main.c
extern int foo();
int main()
{
return foo();
}
$ readelf -d lib/libfoo_fullpath.so
Dynamic section at offset 0x798 contains 23 entries:
TagType Name/Value
0x0001 (NEEDED) Shared library: [libbar.so]
0x0001 (NEEDED) Shared library: [libc.so.6]
0x000e (SONAME) Library soname: [libfoo_fullpath.so]
0x000f (RPATH) Library rpath:
[/ptmp/sdvormwa/ld_bug/lib]
0x000c (INIT) 0x4c8
0x000d (FINI) 0x6a8
0x0004 (HASH) 0x158
0x0005 (STRTAB) 0x2f8
0x0006 (SYMTAB) 0x1a8
0x000a (STRSZ) 212 (bytes)
0x000b (SYMENT) 24 (bytes)
0x0003 (PLTGOT) 0x200970
0x0002 (PLTRELSZ) 48 (bytes)
0x0014 (PLTREL) RELA
0x0017 (JMPREL) 0x498
0x0007 (RELA) 0x408
0x0008 (RELASZ) 144 (bytes)
0x0009 (RELAENT)24 (bytes)
0x6ffe (VERNEED)0x3e8
0x6fff (VERNEEDNUM) 1
0x6ff0 (VERSYM) 0x3cc
0x6ff9 (RELACOUNT) 1
0x (NULL) 0x0
$ readelf -d lib/libfoo_origin.so
Dynamic section at offset 0x798 contains 23 entries:
TagType Name/Value
0x0001 (NEEDED) Shared library: [libbar.so]
0x0001 (NEEDED) Shared library: [libc.so.6]
0x000e (SONAME) Library soname: [libfoo.so]
0x000f (RPATH) Library rpath: [$ORIGIN]
0x000c (INIT) 0x4c8
0x000d (FINI) 0x6a8
0x0004 (HASH) 0x158
0x0005 (STRTAB) 0x2f8
0x0006 (SYMTAB) 0x1a8
0x000a (STRSZ) 208 (bytes)
0x000b (SYMENT) 24 (bytes)
0x0003 (PLTGOT) 0x200970
0x0002 (PLTRELSZ) 48 (bytes)
0x0014 (PLTREL) RELA
0x0017 (JMPREL) 0x498
0x0007 (RELA) 0x408
0x0008 (RELASZ) 144 (bytes)
0x0009 (RELAENT)24 (bytes)
0x6ffe (VERNEED)0x3e8
0x6fff (VERNEEDNUM) 1
0x6ff0 (VERSYM) 0x3c8
0x6ff9 (RELACOUNT) 1
0x (NULL) 0x0
$ ldd lib/libfoo_fullpath.so
linux-vdso.so.1 => (0x781cb000)
libbar.so => /ptmp/sdvormwa/ld_bug/lib/libbar.so (0x7fc04c466000)
libc.so.6 => /lib64/libc.so.6 (0x7fc04c08c000)
/lib64/ld-linux-x86-64.so.2 (0x7fc04c86a000)
$ ldd lib/libfoo_origin.so
linux-vdso.so.1 => (0x7fff0e3ff000)
libbar.so => /ptmp/sdvormwa/ld_bug/lib/libbar.so (0x7f027c5de000)
libc.so.6 => /lib64/libc.so.6 (0x7f027c203000)
/lib64/ld-linux-x86-64.so.2 (0x7f027c9e1000)
$ gcc main.c -Llib/ -lfoo_fullpath && echo PASS
PASS
$ gcc main.c -Llib/ -lfoo_origin && echo PASS
${CUSTOM_LD_PATH}/x86_64-unknown-linux-gnu/bin/ld: warning: libbar.so, needed
by lib//libfoo.so, not found (try using -rpath or -rpath-link)
lib//libfoo.so: undefined reference to `bar'
collect2: ld returned 1 exit status
$ gcc main.c -Llib/ -lfoo_origin -Wl,--rpath-link=lib/ && echo PASS
PASS
$ ${CUSTOM_LD_PATH}/x86_64-unknown-linux-gnu/bin/ld --version
GNU ld (GNU Binutils) 2.23.1
Copyright 2012 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 warran
[Bug ld/16936] $ORIGIN in shared library's rpath not used to find library dependencies at link time
https://sourceware.org/bugzilla/show_bug.cgi?id=16936
--- Comment #1 from Steven Vormwald ---
(In reply to Steven Vormwald from comment #0)
> ${CUSTOM_LD_PATH}/x86_64-unknown-linux-gnu/bin/ld: warning: libbar.so,
> needed by lib//libfoo.so, not found (try using -rpath or -rpath-link)
> lib//libfoo.so: undefined reference to `bar'
> collect2: ld returned 1 exit status
Oops, cut-and-paste error here. I copied and edited (to remove
employer-specific paths) the failure from before I tried building a version of
the library without $ORIGIN. Here's the correct error:
${CUSTOM_LD_PATH}/x86_64-unknown-linux-gnu/bin/ld: warning: libbar.so, needed
by lib//libfoo_origin.so, not found (try using -rpath or -rpath-link)
lib//libfoo_origin.so: undefined reference to `bar'
collect2: ld returned 1 exit status
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/16937] New: aarch64: issue about executable exporting TLS class static member variable
https://sourceware.org/bugzilla/show_bug.cgi?id=16937
Bug ID: 16937
Summary: aarch64: issue about executable exporting TLS class
static member variable
Product: binutils
Version: 2.25 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: jingyuuiuc at gmail dot com
I have a piece of code behaves wrong on aarch64. The scenario is that both
executable and shared library define a TLS class static member variable.
On aarch64, the executable exports the symbol to dynamic symbol stable
with GLOBAL DEFAULT attribute. When shared library is dlopened, dynamic loader
finds the symbol in executable's symbol table and binds to it. Thus
both dynamic library and executable share the same copy of this
variable, which is wrong.
It's generally not expected that the linker will export a symbol in the
executable's dynamic symbol table unless it sees a reference from a shared
library.
$ g++ var_exe.cc -ldl -o var
$ g++ -shared -fPIC var_l.cc -o libvar1.so
$ g++ -shared -fPIC var_l.cc -o libvar2.so
On aarch64:
$ ./var
exe: live += 5
exe: live = 5
Calling libentry in ./libvar1.so...
lib: live += 3
lib: live = 8
Calling libentry in ./libvar2.so...
lib: live += 3
lib: live = 11
$ readelf --dyn-syms -W var | grep _ZN3var4liveE
11: 4 TLS GLOBAL DEFAULT 18 _ZN3var4liveE
$ readelf --dyn-syms -W libvar1.so | grep _ZN3var4liveE
16: 4 TLS GLOBAL DEFAULT 16 _ZN3var4liveE
$ readelf --dyn-syms -W libvar2.so | grep _ZN3var4liveE
16: 4 TLS GLOBAL DEFAULT 16 _ZN3var4liveE
On x86:
$ ./var
exe: live += 5
exe: live = 5
Calling libentry in ./libvar1.so...
lib: live += 3
lib: live = 3
Calling libentry in ./libvar2.so...
lib: live += 3
lib: live = 3
$ readelf --dyn-syms -W var | grep _ZN3var4liveE
$ readelf --dyn-syms -W libvar1.so | grep _ZN3var4liveE
13: 4 TLS GLOBAL DEFAULT 16 _ZN3var4liveE
$ readelf --dyn-syms -W libvar2.so | grep _ZN3var4liveE
13: 4 TLS GLOBAL DEFAULT 16 _ZN3var4liveE
var.h:
#include
class var{
public:
var(){};
static void output(const char* prefix) {
printf("%s: live = %d\n", prefix, live);
};
static void inc(const char* prefix, int i) {
printf("%s: live += %d\n", prefix, i);
live += i;
};
private:
static __thread int live;
};
var_l.cc:===
#include
#include
#include "var.h"
__thread int var::live=0;
extern "C" void libentry() {
var libvar;
libvar.inc("lib", 3);
libvar.output("lib");
}
var_exe.cc:=
#include
#include
#include
#include "var.h"
__thread int var::live=0;
void* load_lib_and_call(const char* libname) {
void* handle = dlopen(libname, RTLD_LOCAL | RTLD_NOW);
if (handle == NULL) {
printf("Can not open shared library %s\n", libname);
return 0;
}
typedef void (*lib_fun_t)();
lib_fun_t lib_entry_ = (lib_fun_t)(dlsym(handle, "libentry"));
const char *dlsym_error = dlerror();
if (dlsym_error) {
printf("Can not load symbol libentry: %s\n", dlsym_error);
dlclose(handle);
return 0;
}
printf("Calling libentry in %s...\n", libname);
lib_entry_();
return handle;
}
int main() {
var mainvar;
mainvar.inc("exe", 5);
mainvar.output("exe");
void* handle1 = load_lib_and_call("./libvar1.so");
void* handle2 = load_lib_and_call("./libvar2.so");
if (handle1)
dlclose(handle1);
if (handle2)
dlclose(handle2);
return 0;
}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/16937] aarch64: issue about executable exporting TLS class static member variable
https://sourceware.org/bugzilla/show_bug.cgi?id=16937 --- Comment #2 from Paul Pluzhnikov --- Google ref: b/14064062 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/16937] aarch64: issue about executable exporting TLS class static member variable
https://sourceware.org/bugzilla/show_bug.cgi?id=16937 Paul Pluzhnikov changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #1 from Paul Pluzhnikov --- Class static member variable is likely a distraction: you should get the exact same behavior with a simple "__thread int foo;" variable. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/16936] $ORIGIN in shared library's rpath not used to find library dependencies at link time
https://sourceware.org/bugzilla/show_bug.cgi?id=16936 --- Comment #2 from Steven Vormwald --- (In reply to Steven Vormwald from comment #0) > GNU ld (GNU Binutils) 2.23.1 This problem also occurs in 2.24. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
