[Bug ld/6443] New: -pie issues with TLS relocations
__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.
--
Summary: -pie issues with TLS relocations
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: jakub at redhat dot com
CC: bug-binutils at gnu dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=6443
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6443] -pie issues with TLS relocations
--- Additional Comments From jakub at redhat dot com 2008-04-22 09:23 --- Created an attachment (id=2715) --> (http://sourceware.org/bugzilla/attachment.cgi?id=2715&action=view) bz6443.patch Attached is just very lightly tested x86_64 set of changes, but i386, ppc, ppc64 and other arches need similar changes. For now glibc will use a workaround, but it would be good to have this fixed soon. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6443 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6443] -pie issues with TLS relocations
-- What|Removed |Added CC||drepper at redhat dot com http://sourceware.org/bugzilla/show_bug.cgi?id=6443 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug ld/6430] --sort-common Not Implemented Per Documentation
Hi Guys, You are correct in that this way a gap would be avoided when the size changes. But given that all like-sized symbols are laid out back to back, this only happens when the size changes. So, either the manual must be changed or the code. I, for one, would rather have the code changed... But this might break existing applications which rely upon the current behaviour. Better I feel would be to fix the documentation and then provide a extended version of the --sort-common switch which takes an argument which specifies the direction of the sorting. eg: --sort-common=biggest-first [this would be the default] --sort-common=smallest-first Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6430] --sort-common Not Implemented Per Documentation
--- Additional Comments From nickc at redhat dot com 2008-04-22 14:45 --- Subject: Re: --sort-common Not Implemented Per Documentation Hi Guys, > You are correct in that this way a gap would be avoided when the size > changes. > But given that all like-sized symbols are laid out back to back, this only > happens when the size changes. > > So, either the manual must be changed or the code. I, for one, would rather > have the code changed... But this might break existing applications which rely upon the current behaviour. Better I feel would be to fix the documentation and then provide a extended version of the --sort-common switch which takes an argument which specifies the direction of the sorting. eg: --sort-common=biggest-first [this would be the default] --sort-common=smallest-first Cheers Nick -- http://sourceware.org/bugzilla/show_bug.cgi?id=6430 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6430] --sort-common Not Implemented Per Documentation
--- Additional Comments From hjl dot tools at gmail dot com 2008-04-22 16:06 --- To prevent gaps between symbols due to alignment constraints, shouldn't we sort common symbols by their alignments? -- http://sourceware.org/bugzilla/show_bug.cgi?id=6430 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6443] -pie issues with TLS relocations
--- Additional Comments From amodra at bigpond dot net dot au 2008-04-22 16:10 --- I'll take a look at ppc. The obvious change doesn't help much as enabling ppc_elf_tls_optimize for pie results in us hitting the bfd_error_bad_value at elf32-ppc.c:6577 when we try to make a dynamic reloc for the edited LD->LE tls reloc. That is, if you use an old enough compiler. gcc 4.2 and later reschedule the tls sequences and ppc_elf_tls_optimize gives up. We really need some way of tying together relocs on arg setup for __tls_get_addr and the call to __tls_get_addr itself. One way that occurred to me is to emit a call to the tls variable involved instead of __tls_get_addr, and of course restore the real call in the linker. eg. instead of addi 3,30,[EMAIL PROTECTED]@tlsld bl __tls_get_addr emit addi 3,30,[EMAIL PROTECTED]@tlsld bl foo This would allow the linker to edit the sequence as the tls symbol foo on both relocs ties things together. A real call to a tls symbol can't happen, so all bl some_tls_symbol means bl __tls_get_addr. Unfortunately this is an ABI change. Alternatively, disable scheduling of tls sequences involving __tls_get_addr in gcc. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6443 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6430] --sort-common Not Implemented Per Documentation
--- Additional Comments From evandro at yahoo dot com 2008-04-22 16:56 --- As a matter of fact, the current implementation actually sorts by alignment. I like Nick's suggestion, only I prefer terser wording, such as "ascending" or "descending". But that's me. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6430 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6430] --sort-common Not Implemented Per Documentation
--- Additional Comments From hjl dot tools at gmail dot com 2008-04-22 17:17 --- (In reply to comment #8) > As a matter of fact, the current implementation actually sorts by alignment. > > I like Nick's suggestion, only I prefer terser wording, such as "ascending" or > "descending". But that's me. In that case, we need to fix the typo in the linker manual first: `--sort-common' should be sorted by alignment, not by size. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6430 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6446] New: Handling of EF_FRV_PIC
Another bug found by inspection. The ABI says: The linker should warn and clear EF_FRV_PIC when linking FDPIC binaries if it finds any inter-segment relocation, and set it otherwise. But in fact the linker sets EF_FRV_PIC if it sees any inter-segment relocations. There's hardcoded checks for files named "crt0.o" directly above that, too. -- Summary: Handling of EF_FRV_PIC Product: binutils Version: 2.19 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassigned at sources dot redhat dot com ReportedBy: drow at sources dot redhat dot com CC: bug-binutils at gnu dot org GCC target triplet: frv-uclinux http://sourceware.org/bugzilla/show_bug.cgi?id=6446 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6446] Handling of EF_FRV_PIC
-- What|Removed |Added CC||aoliva at sourceware dot org http://sourceware.org/bugzilla/show_bug.cgi?id=6446 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6431] ld says: invalid version 3 (max 0)
--- Additional Comments From niki dot waibel at gmx dot net 2008-04-22 20:28 --- similar error reported here: http://osdir.com/ml/package-management.openpkg.user/2006-06/msg00046.html -- http://sourceware.org/bugzilla/show_bug.cgi?id=6431 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6431] ld says: invalid version 3 (max 0)
--- Additional Comments From niki dot waibel at gmx dot net 2008-04-22 21:22 --- ... and here: http://forums.mysql.com/read.php?11,199436,199436 http://lists.boost.org/boost-testing/2007/03/4242.php http://mail.gnome.org/archives/gtk-list/2007-October/msg00145.html http://mail.gnome.org/archives/gtk-devel-list/2007-July/msg00060.html http://gcc.gnu.org/ml/gcc/2001-01/msg01468.html -- http://sourceware.org/bugzilla/show_bug.cgi?id=6431 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
