[Bug gold/21090] gcc compiled with --enable-default-pie show errors in binutils testsuite
https://sourceware.org/bugzilla/show_bug.cgi?id=21090 --- Comment #24 from oneup40.bugzilla at bulletmail dot org --- Created attachment 10062 --> https://sourceware.org/bugzilla/attachment.cgi?id=10062&action=edit reduced testcase for gold incremental link internal error $ make 1.o 2.o main.o g++-c -o 1.o 1.cc g++-c -o 2.o 2.cc g++-c -o main.o main.cc $ g++ -Bbinutils-build/gold/testsuite/gcctestdir -fno-use-linker-plugin -Wl,--incremental-full,--incremental-patch=100 -Wl,-z,norelro 2.o main.o 1.o $ g++ -Bbinutils-build/gold/testsuite/gcctestdir -fno-use-linker-plugin -Wl,--incremental-update -Wl,-z,norelro 2.o main.o -Wl,--incremental-changed 1.o -Wl,--incremental-unknown binutils-build/gold/testsuite/gcctestdir/ld: internal error in relocate, at ../../gold/x86_64.cc:4300 collect2: error: 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 gold/21503] Gold doesn't create linker stub symbols on ppc64
https://sourceware.org/bugzilla/show_bug.cgi?id=21503 Eric Christopher changed: What|Removed |Added CC||echristo at gmail dot com -- 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 binutils/21507] objdump: Incorrect jump label in disassemble for arm object file
https://sourceware.org/bugzilla/show_bug.cgi?id=21507 --- Comment #2 from Michele Sardo --- Hi Nick, Thanks for the clarification. I agree with you that linker will resolve the relocation address to , thus no functional problem happens. My problem was related to label printed by objdump and, in this case, the bl instruction has argument 0 (relative to PC) which means that jump address is dummy and will be patched with correct address after linking. Nevertheless, I am still unclear why a label is printed which is misleading, in my opinion. I would have expected meaning that the jump is to the next instruction (dummy jump). In general, I noticed that every 'bl 0' instruction is printed with a label associated with function at the address 0 of the section, that in the particular example happen to be f itself. Don't you think it would make more sense to print the relocation address label ? In any case, thanks again for your feedback. Cheers Michele Il 22/mag/2017 01:16 PM, "nickc at redhat dot com" ha scritto: > https://sourceware.org/bugzilla/show_bug.cgi?id=21507 > > Nick Clifton changed: > >What|Removed |Added > > > Status|UNCONFIRMED |RESOLVED > CC||nickc at redhat dot com > Resolution|--- |INVALID > > --- Comment #1 from Nick Clifton --- > Hi Michele, > > >4: f7ff fffe bl 0 < This label should be > >> > > This is not a bug. Try adding the "-r" option to the objdump command line > in > order to see why: > > 4:f7ff fffe bl 0 > 4: R_ARM_THM_CALL g > > So the branch at address 4 is currently going to address 0, which is where > the > "f" symbol is located. But there is a relocation attached to that address > which > will change the branch to go to the address of symbol "g". > > If you link the program, the relocation will be processed and the > instruction > will be updated to point to the correct destination. > > Cheers > Nick > > -- > You are receiving this mail because: > You reported the bug. -- 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 binutils/21507] objdump: Incorrect jump label in disassemble for arm object file
https://sourceware.org/bugzilla/show_bug.cgi?id=21507 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |INVALID --- Comment #1 from Nick Clifton --- Hi Michele, >4: f7ff fffe bl 0 < This label should be >> This is not a bug. Try adding the "-r" option to the objdump command line in order to see why: 4:f7ff fffe bl 0 4: R_ARM_THM_CALL g So the branch at address 4 is currently going to address 0, which is where the "f" symbol is located. But there is a relocation attached to that address which will change the branch to go to the address of symbol "g". If you link the program, the relocation will be processed and the instruction will be updated to point to the correct destination. Cheers Nick -- 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 binutils/21505] objcopy fails --prefix-symbols on armv7
https://sourceware.org/bugzilla/show_bug.cgi?id=21505 Dave changed: What|Removed |Added Severity|normal |critical -- 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
