[Bug ld/6443] -pie issues with TLS relocations
http://sourceware.org/bugzilla/show_bug.cgi?id=6443 Jakub Jelinek jakub at redhat dot com changed: What|Removed |Added Blocks||14940 -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/14940] New: -pie issues with TLS relocations
http://sourceware.org/bugzilla/show_bug.cgi?id=14940
Bug #: 14940
Summary: -pie issues with TLS relocations
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: ja...@redhat.com
CC: bug-binutils@gnu.org, drepper@gmail.com,
hjl.to...@gmail.com
Depends on: 6443
Classification: Unclassified
+++ This bug was initially created as a clone of Bug #6443 +++
__thread int a;
__thread int b __attribute((tls_model (local-exec)));
__thread int c __attribute((tls_model (initial-exec)));
__thread int d __attribute((tls_model (local-dynamic)));
__thread int e __attribute((tls_model (global-dynamic)));
int
main (void)
{
return a + b + c + d + e;
}
compiled/linked with -O2 -pie -fpie on various arches either doesn't link at
all,
or makes completely unnecessarily a DT_TEXTREL PIE. Tried x86_64, i386, ppc,
ppc64. For the TLS transitions and relocations, PIEs should be handled like
other executables, so many info-shared checks need to be replaced with
!info-executable. For the TLS relocations, even when the executable is
position independent, the offsets within the PIE's TLS block are known at link
time and so relocations like R_X86_64_TPOFF32 can be relocated fully at link
time.
While this is now fixed on i?86/x86_64 and perhaps ppc/ppc64, it isn't fixed on
s390/s390x. See https://bugzilla.redhat.com/show_bug.cgi?id=872148
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- 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/14940] s390 -pie issues with TLS relocations
http://sourceware.org/bugzilla/show_bug.cgi?id=14940 Jakub Jelinek jakub at redhat dot com changed: What|Removed |Added Target||s390*-*-* Summary|-pie issues with TLS|s390 -pie issues with TLS |relocations |relocations -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/10238] Gold linker does not resolve symbols using indirect dependencies
http://sourceware.org/bugzilla/show_bug.cgi?id=10238
mattijs.janssens at gmail dot com changed:
What|Removed |Added
CC||mattijs.janssens at gmail
||dot com
Version|2.19|2.22
--- Comment #18 from mattijs.janssens at gmail dot com 2012-12-10 15:59:09 UTC
---
This feature is causing us quite a headache. We are developing an open source
application (OpenFOAM) which is chock full of models and models of models which
are in separate libraries. We have always used the facility of indirect linkage
so a library needs to link in only those libraries it directly calls, and not
those that those libraries need. Works great.
If we want to use gold we suddenly need to specify all the indirectly used
libraries. Why should a user of our libraries need to know that e.g. the
turbulence library internally depends on the liquid properties library (and
about 10 more)?
From my point of view: I have gone through all my dependencies and not link in
more than needed and have 'told' the linker so with --copy-dt-needed-entries,
--no-as-needed. But it seems to ignore these now.
Below a modification of the testscript which demonstrates the indirect linking
problem at the shared library level.
My question: can we please keep/have an option to tell the linker to do
indirect linkage.
Thanks,
Mattijs
# Build libl3.so with no dependents
echo 'l3() { ; }' l3.c
gcc -Xlinker --no-as-needed -Xlinker --copy-dt-needed-entries -Xlinker
-rpath=. -shared -fPIC -o libl3.so l3.c
# Build libl2.so that depends on libl3.so
echo 'l2() { l3(); }' l2.c
gcc -Xlinker --no-as-needed -Xlinker --copy-dt-needed-entries -Xlinker
-rpath=. -shared -fPIC -o libl2.so l2.c -L. -ll3
# Build libl1.so that depends on libl2.so
echo 'l1() { l2(); }' l1.c
gcc -Xlinker --no-as-needed -Xlinker --copy-dt-needed-entries -Xlinker
-rpath=. -shared -fPIC -o libl1.so l1.c -L. -ll2
# Build main source file which depends on l1 only (so indirectly on l2)
echo 'main() { l1(); }' top.c
gcc top.c -L. -ll1
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- 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/10238] Gold linker does not resolve symbols using indirect dependencies
http://sourceware.org/bugzilla/show_bug.cgi?id=10238 --- Comment #20 from Ian Lance Taylor ian at airs dot com 2012-12-10 17:22:17 UTC --- When using gold you need to list the shared libraries that define symbols that you refer to directly. You do not need to list libraries that define symbols that your shared libraries refer to. We have always used the facility of indirect linkage so a library needs to link in only those libraries it directly calls, and not those that those libraries need. Yes, that is how gold works. If it's not working for you, then something else is going on. One possibility is this: gold will warn about undefined symbols in shared libraries for which gold has seen all the DT_NEEDED entries. So if your shared libraries rely on picking up symbols from shared libraries that they do not explicitly depend on, you will get an undefined symbol error. You can avoid that by using the --allow-shlib-undefined option. Otherwise, you'll need to provide more details. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/10238] Gold linker does not resolve symbols using indirect dependencies
http://sourceware.org/bugzilla/show_bug.cgi?id=10238
--- Comment #19 from H.J. Lu hjl.tools at gmail dot com 2012-12-10 16:46:15
UTC ---
(In reply to comment #18)
# Build libl3.so with no dependents
echo 'l3() { ; }' l3.c
gcc -Xlinker --no-as-needed -Xlinker --copy-dt-needed-entries -Xlinker
-rpath=. -shared -fPIC -o libl3.so l3.c
# Build libl2.so that depends on libl3.so
echo 'l2() { l3(); }' l2.c
gcc -Xlinker --no-as-needed -Xlinker --copy-dt-needed-entries -Xlinker
-rpath=. -shared -fPIC -o libl2.so l2.c -L. -ll3
# Build libl1.so that depends on libl2.so
echo 'l1() { l2(); }' l1.c
gcc -Xlinker --no-as-needed -Xlinker --copy-dt-needed-entries -Xlinker
-rpath=. -shared -fPIC -o libl1.so l1.c -L. -ll2
# Build main source file which depends on l1 only (so indirectly on l2)
echo 'main() { l1(); }' top.c
gcc top.c -L. -ll1
Please re-try this with bfd linker on trunk. I just fixed a
--copy-dt-needed-entries -shared bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=14915
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- 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
