[Bug binutils/24768] Stop using __gnu_lto_slim symbol as a detection of a slim LTO object
https://sourceware.org/bugzilla/show_bug.cgi?id=24768 --- Comment #3 from Martin Liška --- > > The layout of this struct depends on the host compiler. Won't that cause > problems in object file portability? You are right, I will change streaming of the structure to be always LE in a ELF file. I'll then send patches to binutils mailing list. -- 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/24809] objcopy to not add SECTION symbols if section .note.gnu.gold-version present
https://sourceware.org/bugzilla/show_bug.cgi?id=24809 Tom de Vries changed: What|Removed |Added Component|tools |binutils Version|unspecified |2.33 (HEAD) Product|elfutils|binutils Summary|eu-unstrip to drop SECTION |objcopy to not add SECTION |symbols if section |symbols if section |.note.gnu.gold-version |.note.gnu.gold-version |present |present --- Comment #2 from Tom de Vries --- (In reply to Mark Wielaard from comment #1) > I can replicate this if I use objcopy to produce the hello.debug and > hello.stripped binaries. But why don't you just use eu-strip? > I think the idea here is to have the tools from the two "products" to play nice together. > Doing: > $ eu-strip -f hello.debug -o hello.stripped hello > $ eu-unstrip hello.stripped hello.debug -o hello.unstripped > > Produces: > $ ls -la > -rwxrwxr-x. 1 mark mark 10416 Jul 15 14:50 hello > -rw-rw-r--. 1 mark mark92 Jul 15 14:50 hello.c > -rwxrwxr-x. 1 mark mark 6840 Jul 15 14:52 hello.debug > -rwxrwxr-x. 1 mark mark 6488 Jul 15 14:52 hello.stripped > -rwxrwxr-x. 1 mark mark 10416 Jul 15 14:52 hello.unstripped > > $ readelf -s hello.debug | grep -c SECTION > 0 > $ readelf -s hello.stripped | grep -c SECTION > 0 > $ readelf -s hello.unstripped | grep -c SECTION > 0 > > Which seems much more reasonable than what objcopy does. > Right, I noticed that. > I am not sure eu-unstrip should remove extra stuff objcopy adds. It seems > that if the user created these bigger than necessary .debug and .stripped > files, then they wanted that for some reason. It seems unwise to second > guess the user. > > If there is a bug, then I think it is simply a bug in objcopy, which can be > prevented by using eu-strip instead. OK, changing product to binutils. -- 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/24784] elf_x86_64_check_tls_transition should allow R_X86_64_GOTPCREL (-fno-plt)
https://sourceware.org/bugzilla/show_bug.cgi?id=24784 --- Comment #6 from H.J. Lu --- The psABI also says For the occurrence of name@GOTPCREL in the following assembler instructions: call *name@GOTPCREL(%rip) ... the R_X86_64_GOTPCRELX relocation, or the R_X86_64_REX_GOTPCRELX relocation if the REX prefix is present, should be generated. R_X86_64_GOTPCRELX should be generated for: call __tls_get_addr@GOTPCREL(%rip) -- 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/24784] elf_x86_64_check_tls_transition should allow R_X86_64_GOTPCREL (-fno-plt)
https://sourceware.org/bugzilla/show_bug.cgi?id=24784 --- Comment #7 from Fangrui Song --- > For the occurrence of name@GOTPCREL in the following assembler instructions: > call *name@GOTPCREL(%rip) I agree, yet it also says: > (PIC) the base of GOT is within 2GB an indirect call to the GOT entry might > be implemented like so: > foo (); call *(foo@GOT); R_X86_64_GOTPCREL :) -- 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
