[Bug ld/20475] Linking PIC executables with a linker script that does not place _GLOBAL_OFFSET_TABLE_ results in incorrect relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=20475 --- Comment #3 from whitequark at whitequark dot org --- Actually, I might be wrong about this, since the comment in elflink.c implies that the behavior is intentional. I'll attach another patch, which fixes the logic of relocating R_OR1K_GOTOFF_* instead, making it follow the logic in elflink.c. -- 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/20475] Linking PIC executables with a linker script that does not place _GLOBAL_OFFSET_TABLE_ results in incorrect relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=20475 --- Comment #4 from whitequark at whitequark dot org --- Created attachment 9442 --> https://sourceware.org/bugzilla/attachment.cgi?id=9442&action=edit OR1K target patch -- 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/20308] Gold should support i386 TLS code sequences without PLT
https://sourceware.org/bugzilla/show_bug.cgi?id=20308 ncahill_alt at yahoo dot com changed: What|Removed |Added CC||ncahill_alt at yahoo dot com --- Comment #4 from ncahill_alt at yahoo dot com --- Created attachment 9443 --> https://sourceware.org/bugzilla/attachment.cgi?id=9443&action=edit object files that then failed the test -- 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/20308] Gold should support i386 TLS code sequences without PLT
https://sourceware.org/bugzilla/show_bug.cgi?id=20308 --- Comment #5 from ncahill_alt at yahoo dot com --- Regarding this update, I'm getting a failure on "make testsuite/pr20308a_test": pr20308_gd.o:function test_gd: error: missing expected TLS relocation gcctestdir/ld: error: missing expected TLS relocation pr20308_ld.o:function test_ld: error: missing expected TLS relocation pr20308_ld.o:function test_ld: error: missing expected TLS relocation gcctestdir/ld: error: missing expected TLS relocation I see this message twice in i386.cc: -- line 634 -- ~Relocate() { if (this->skip_call_tls_get_addr_) { // FIXME: This needs to specify the location somehow. gold_error(_("missing expected TLS relocation")); } } -- line 2787 --- const elfcpp::Rel<32, false> rel(preloc); unsigned int r_type = elfcpp::elf_r_type<32>(rel.get_r_info()); if (this->skip_call_tls_get_addr_) { if ((r_type != elfcpp::R_386_PLT32 && r_type != elfcpp::R_386_GOT32X && r_type != elfcpp::R_386_PC32) || gsym == NULL || strcmp(gsym->name(), "___tls_get_addr") != 0) gold_error_at_location(relinfo, relnum, rel.get_r_offset(), _("missing expected TLS relocation")); else { this->skip_call_tls_get_addr_ = false; return false; } } --- One thing I notice is this: 0066 R_386_GOT32 ___tls_get_addr Hopefully that's the problem. Also I wonder if it would be helpful to make those two error messages slightly different so one could pick out which is which. Thank you. Neil. -- 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/20308] Gold should support i386 TLS code sequences without PLT
https://sourceware.org/bugzilla/show_bug.cgi?id=20308 --- Comment #6 from H.J. Lu --- Created attachment 9444 --> https://sourceware.org/bugzilla/attachment.cgi?id=9444&action=edit Try this -- 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/20308] Gold should support i386 TLS code sequences without PLT
https://sourceware.org/bugzilla/show_bug.cgi?id=20308 --- Comment #7 from ncahill_alt at yahoo dot com --- Created attachment 9445 --> https://sourceware.org/bugzilla/attachment.cgi?id=9445&action=edit result of changes It still fails: pr20308_gd.o:function test_gd: error: missing expected TLS relocation pr20308_ld.o:function test_ld: error: missing expected TLS relocation -- 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/20308] Gold should support i386 TLS code sequences without PLT
https://sourceware.org/bugzilla/show_bug.cgi?id=20308 --- Comment #8 from H.J. Lu --- (In reply to ncahill_alt from comment #7) > Created attachment 9445 [details] > result of changes > > It still fails: > > pr20308_gd.o:function test_gd: error: missing expected TLS relocation > pr20308_ld.o:function test_ld: error: missing expected TLS relocation Please show the output of "readelf -r pr20308_gd.o" -- 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/20308] Gold should support i386 TLS code sequences without PLT
https://sourceware.org/bugzilla/show_bug.cgi?id=20308 --- Comment #9 from ncahill_alt at yahoo dot com --- Relocation section '.rel.text' at offset 0x2ec contains 12 entries: Offset InfoTypeSym.Value Sym. Name 0002 0b02 R_386_PC32 __x86.get_pc_thunk.bx 0008 0c0a R_386_GOTPC _GLOBAL_OFFSET_TABLE_ 0012 0d12 R_386_TLS_GD gd 0017 0e04 R_386_PLT32 ___tls_get_addr 0022 0b02 R_386_PC32 __x86.get_pc_thunk.bx 0028 0c0a R_386_GOTPC _GLOBAL_OFFSET_TABLE_ 0031 0d12 R_386_TLS_GD gd 0036 0e04 R_386_PLT32 ___tls_get_addr 0051 1102 R_386_PC32 __x86.get_pc_thunk.cx 0057 0c0a R_386_GOTPC _GLOBAL_OFFSET_TABLE_ 0060 0d12 R_386_TLS_GD gd 0066 0e03 R_386_GOT32 ___tls_get_addr CFLAGS = -O2 -fno-tree-slsr -march=athlon64 -mtune=core2 -fno-inline -pipe -funroll-loops -funswitch-loops CXXFLAGS = -g -O2 LDFLAGS = -Wl,-O1 GCC is 5.2.0, i686-pc-linux-gnu-gcc -- 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/20308] Gold should support i386 TLS code sequences without PLT
https://sourceware.org/bugzilla/show_bug.cgi?id=20308 --- Comment #10 from H.J. Lu --- (In reply to ncahill_alt from comment #9) > Relocation section '.rel.text' at offset 0x2ec contains 12 entries: > Offset InfoTypeSym.Value Sym. Name > 0002 0b02 R_386_PC32 __x86.get_pc_thunk.bx > 0008 0c0a R_386_GOTPC _GLOBAL_OFFSET_TABLE_ > 0012 0d12 R_386_TLS_GD gd > 0017 0e04 R_386_PLT32 ___tls_get_addr > 0022 0b02 R_386_PC32 __x86.get_pc_thunk.bx > 0028 0c0a R_386_GOTPC _GLOBAL_OFFSET_TABLE_ > 0031 0d12 R_386_TLS_GD gd > 0036 0e04 R_386_PLT32 ___tls_get_addr > 0051 1102 R_386_PC32 __x86.get_pc_thunk.cx > 0057 0c0a R_386_GOTPC _GLOBAL_OFFSET_TABLE_ > 0060 0d12 R_386_TLS_GD gd > 0066 0e03 R_386_GOT32 ___tls_get_addr > > CFLAGS = -O2 -fno-tree-slsr -march=athlon64 -mtune=core2 -fno-inline -pipe > -funroll-loops -funswitch-loops > CXXFLAGS = -g -O2 > LDFLAGS = -Wl,-O1 > > GCC is 5.2.0, i686-pc-linux-gnu-gcc Please show the command line used to compile pr20308_gd.o. BTW, did you run "make clean" first? -- 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
Re: [Bug gold/20308] Gold should support i386 TLS code sequences without PLT
> Please show the command line used to compile pr20308_gd.o. > > BTW, did you run "make clean" first? Yeah, the build rules should also have a dependency on gcctestdir/as. Forgot that when fixing the x86_64 test, sorry. -cary ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/20308] Gold should support i386 TLS code sequences without PLT
https://sourceware.org/bugzilla/show_bug.cgi?id=20308 --- Comment #11 from Cary Coutant --- > Please show the command line used to compile pr20308_gd.o. > > BTW, did you run "make clean" first? Yeah, the build rules should also have a dependency on gcctestdir/as. Forgot that when fixing the x86_64 test, sorry. -cary -- 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/20481] New: ld.gold should fail when producing an elf32 so >4G
https://sourceware.org/bugzilla/show_bug.cgi?id=20481 Bug ID: 20481 Summary: ld.gold should fail when producing an elf32 so >4G Product: binutils Version: 2.24 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: tobiasjs at google dot com CC: ian at airs dot com Target Milestone: --- Created attachment 9448 --> https://sourceware.org/bugzilla/attachment.cgi?id=9448&action=edit readelf -e good output At the moment it succeeds without warning, but the resulting section header offset is wrong, and the output is unusable. In this case the library text is a comparatively sane 66M, but there is a quantity of debug information best described as somewhat less so. I've attached the readelf -e output for a version of the library where I stripped .o files until I got the result down to slightly under 4G. -- 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/20481] ld.gold should fail when producing an elf32 so >4G
https://sourceware.org/bugzilla/show_bug.cgi?id=20481 --- Comment #1 from Tobias Sargeant --- Created attachment 9449 --> https://sourceware.org/bugzilla/attachment.cgi?id=9449&action=edit readelf -e bad output -- 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/20308] Gold should support i386 TLS code sequences without PLT
https://sourceware.org/bugzilla/show_bug.cgi?id=20308 --- Comment #12 from ncahill_alt at yahoo dot com --- (In reply to H.J. Lu from comment #10) > (In reply to ncahill_alt from comment #9) > > Relocation section '.rel.text' at offset 0x2ec contains 12 entries: > > Offset InfoTypeSym.Value Sym. Name > > 0002 0b02 R_386_PC32 __x86.get_pc_thunk.bx > > 0008 0c0a R_386_GOTPC _GLOBAL_OFFSET_TABLE_ > > 0012 0d12 R_386_TLS_GD gd > > 0017 0e04 R_386_PLT32 ___tls_get_addr > > 0022 0b02 R_386_PC32 __x86.get_pc_thunk.bx > > 0028 0c0a R_386_GOTPC _GLOBAL_OFFSET_TABLE_ > > 0031 0d12 R_386_TLS_GD gd > > 0036 0e04 R_386_PLT32 ___tls_get_addr > > 0051 1102 R_386_PC32 __x86.get_pc_thunk.cx > > 0057 0c0a R_386_GOTPC _GLOBAL_OFFSET_TABLE_ > > 0060 0d12 R_386_TLS_GD gd > > 0066 0e03 R_386_GOT32 ___tls_get_addr > > > > CFLAGS = -O2 -fno-tree-slsr -march=athlon64 -mtune=core2 -fno-inline -pipe > > -funroll-loops -funswitch-loops > > CXXFLAGS = -g -O2 > > LDFLAGS = -Wl,-O1 > > > > GCC is 5.2.0, i686-pc-linux-gnu-gcc > > Please show the command line used to compile pr20308_gd.o. i686-pc-linux-gnu-gcc -Bgcctestdir/ -fPIE -O2 -fno-tree-slsr -march=athlon64 -mtune=core2 -fno-inline -pipe -funroll-loops -funswitch-loops -Bgcctestdir/ -Wl,-R,. -Wl,-O1 -o pr20308a_test pr20308a_test-pr20308_main.o pr20308a_test-pr20308_def.o pr20308_gd.o pr20308_ld.o -ldl > > BTW, did you run "make clean" first? Yes, I built binutils from scratch each time. This all looks odd but basically... 1. CFLAGS is very well tested, I won't go into it but it gives helpful profiling results, for example I was able to report performance issues with GCC. 2. CXXFLAGS should have been the same, I had a script that set everything but I had to recreate it and forgot to set CXXFLAGS. -- 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/20308] Gold should support i386 TLS code sequences without PLT
https://sourceware.org/bugzilla/show_bug.cgi?id=20308 --- Comment #13 from ncahill_alt at yahoo dot com --- Oh sorry, here it is: `echo i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../../binutils-2.27/gold/testsuite -I.. -I../../../binutils-2.27/gold/testsuite -I../../../binutils-2.27/gold/testsuite/.. -I../../../binutils-2.27/gold/testsuite/../../include -I../../../binutils-2.27/gold/testsuite/../../elfcpp -I.. -DLOCALEDIR="\"/usr/share/binutils-data/i686-pc-linux-gnu/2.27/locale\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fmerge-constants -O2 -fno-tree-slsr -march=athlon64 -mtune=core2 -fno-inline -pipe -funroll-loops -funswitch-loops | sed -e 's/-Wp,-D_FORTIFY_SOURCE=[0-9[0-9]]*//'` -Bgcctestdir/ -c -o pr20308_gd.o ../../../binutils-2.27/gold/testsuite/pr20308_gd.S which translates to i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../../binutils-2.27/gold/testsuite -I.. -I../../../binutils-2.27/gold/testsuite -I../../../binutils-2.27/gold/testsuite/.. -I../../../binutils-2.27/gold/testsuite/../../include -I../../../binutils-2.27/gold/testsuite/../../elfcpp -I.. -DLOCALEDIR="/usr/share/binutils-data/i686-pc-linux-gnu/2.27/locale" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fmerge-constants -O2 -fno-tree-slsr -march=athlon64 -mtune=core2 -fno-inline -pipe -funroll-loops -funswitch-loops -Bgcctestdir/ -c -o pr20308_gd.o ../../../binutils-2.27/gold/testsuite/pr20308_gd.S -- 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/20475] Linking PIC executables with a linker script that does not place _GLOBAL_OFFSET_TABLE_ results in incorrect relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=20475 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #5 from Alan Modra --- Yes, your second patch is much better. The first one probably would break some other target. Even better would be to use the value of _GLOBAL_OFFSET_TABLE_ relocation -= (htab->root.hgot->root.u.def.value + htab->root.hgot->root.u.def.section->output_offset + htab->root.hgot->root.u.def.section->output_section->vma); Assuming the or1k backend doesn't have other bugs in this area, that would allow a script to define _GLOBAL_OFFSET_TABLE_ at somewhere other than the start of .got.plt. If the above tests out OK, please post the patch to binut...@sourceware.org noting my preapproval, and commit. -- 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/20308] Gold should support i386 TLS code sequences without PLT
https://sourceware.org/bugzilla/show_bug.cgi?id=20308 --- Comment #14 from H.J. Lu --- (In reply to ncahill_alt from comment #13) > Oh sorry, here it is: > > `echo i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. > -I../../../binutils-2.27/gold/testsuite -I.. > -I../../../binutils-2.27/gold/testsuite > -I../../../binutils-2.27/gold/testsuite/.. > -I../../../binutils-2.27/gold/testsuite/../../include > -I../../../binutils-2.27/gold/testsuite/../../elfcpp -I.. > -DLOCALEDIR="\"/usr/share/binutils-data/i686-pc-linux-gnu/2.27/locale\"" > -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow > -Wstack-usage=262144 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > -fmerge-constants -O2 -fno-tree-slsr -march=athlon64 -mtune=core2 > -fno-inline -pipe -funroll-loops -funswitch-loops | sed -e > 's/-Wp,-D_FORTIFY_SOURCE=[0-9[0-9]]*//'` -Bgcctestdir/ -c -o pr20308_gd.o > ../../../binutils-2.27/gold/testsuite/pr20308_gd.S > > which translates to > > i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. > -I../../../binutils-2.27/gold/testsuite -I.. > -I../../../binutils-2.27/gold/testsuite > -I../../../binutils-2.27/gold/testsuite/.. > -I../../../binutils-2.27/gold/testsuite/../../include > -I../../../binutils-2.27/gold/testsuite/../../elfcpp -I.. > -DLOCALEDIR="/usr/share/binutils-data/i686-pc-linux-gnu/2.27/locale" -W > -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fmerge-constants -O2 > -fno-tree-slsr -march=athlon64 -mtune=core2 -fno-inline -pipe -funroll-loops > -funswitch-loops -Bgcctestdir/ -c -o pr20308_gd.o > ../../../binutils-2.27/gold/testsuite/pr20308_gd.S This should generate R_386_GOT32X, not R_386_GOT32 relocation. -- 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/20308] Gold should support i386 TLS code sequences without PLT
https://sourceware.org/bugzilla/show_bug.cgi?id=20308 --- Comment #15 from ncahill_alt at yahoo dot com --- (In reply to H.J. Lu from comment #14) > (In reply to ncahill_alt from comment #13) > > Oh sorry, here it is: > > > > `echo i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. > > -I../../../binutils-2.27/gold/testsuite -I.. > > -I../../../binutils-2.27/gold/testsuite > > -I../../../binutils-2.27/gold/testsuite/.. > > -I../../../binutils-2.27/gold/testsuite/../../include > > -I../../../binutils-2.27/gold/testsuite/../../elfcpp -I.. > > -DLOCALEDIR="\"/usr/share/binutils-data/i686-pc-linux-gnu/2.27/locale\"" > > -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow > > -Wstack-usage=262144 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > > -fmerge-constants -O2 -fno-tree-slsr -march=athlon64 -mtune=core2 > > -fno-inline -pipe -funroll-loops -funswitch-loops | sed -e > > 's/-Wp,-D_FORTIFY_SOURCE=[0-9[0-9]]*//'` -Bgcctestdir/ -c -o pr20308_gd.o > > ../../../binutils-2.27/gold/testsuite/pr20308_gd.S > > > > which translates to > > > > i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. > > -I../../../binutils-2.27/gold/testsuite -I.. > > -I../../../binutils-2.27/gold/testsuite > > -I../../../binutils-2.27/gold/testsuite/.. > > -I../../../binutils-2.27/gold/testsuite/../../include > > -I../../../binutils-2.27/gold/testsuite/../../elfcpp -I.. > > -DLOCALEDIR="/usr/share/binutils-data/i686-pc-linux-gnu/2.27/locale" -W > > -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 > > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fmerge-constants -O2 > > -fno-tree-slsr -march=athlon64 -mtune=core2 -fno-inline -pipe -funroll-loops > > -funswitch-loops -Bgcctestdir/ -c -o pr20308_gd.o > > ../../../binutils-2.27/gold/testsuite/pr20308_gd.S > > This should generate R_386_GOT32X, not R_386_GOT32 relocation. Could this be a glibc problem? I see this patch dated December 2015: > diff --git a/backends/ChangeLog b/backends/ChangeLog > index 4b604fd..cc0dd6f 100644 > --- a/backends/ChangeLog > +++ b/backends/ChangeLog > @@ -1,3 +1,8 @@ > +2015-12-28 Mark Wielaard ; > + > + * i386_reloc.def: Add GOT32X. > + * x86_64_reloc.def: Add GOTPCRELX and REX_GOTPCRELX. > + 2015-12-08 Jose E. Marchesi ; I'm using glibc-2.22 from 2015-08-14. In fact, I can confirm that elf.h defines R_386_GOT32 but not R_386_GOT32X: > #define R_68K_GOT32 7 /* 32 bit PC relative GOT entry */ > #define R_68K_GOT32O10 /* 32 bit GOT offset */ > #define R_386_GOT323/* 32 bit GOT entry */ > #define R_ARM_GOT32 26 /* 32 bit GOT entry */ > #define R_SH_GOT32 160 > #define R_390_GOT32 7 /* 32 bit GOT offset. */ > #define R_X86_64_GOT32 3 /* 32 bit GOT entry */ > #define R_MN10300_GOT32 17 /* 32-bit offset to GOT entry. */ I think this must be it. -- 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