[Bug ld/26806] Suspected linker bug with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=26806 --- Comment #9 from Alan Modra --- Created attachment 12932 --> https://sourceware.org/bugzilla/attachment.cgi?id=12932&action=edit testcases -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26815] Unnecessary error on linking STV_PROTECTED library: relocation R_X86_64_PC32 against protected symbol `f' can not be used when making a shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=26815 Fabian Vogt changed: What|Removed |Added CC||fab...@ritter-vogt.de -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26703] Support x86 micro-architecture ISA level marker
https://sourceware.org/bugzilla/show_bug.cgi?id=26703 --- Comment #4 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b0ab06937385e0ae25cebf1991787d64f439bf12 commit b0ab06937385e0ae25cebf1991787d64f439bf12 Author: H.J. Lu Date: Fri Oct 30 06:49:57 2020 -0700 x86: Support GNU_PROPERTY_X86_ISA_1_BASELINE marker GCC 11 supports -march=x86-64-v[234] to enable x86 micro-architecture ISA levels: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250 X86 ISA markers are updated: https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/13 GNU_PROPERTY_X86_ISA_1_BASELINE is added and GNU_PROPERTY_X86_ISA_1_V[234] are updated: #define GNU_PROPERTY_X86_ISA_1_BASELINE (1U << 0) #define GNU_PROPERTY_X86_ISA_1_V2 (1U << 1) #define GNU_PROPERTY_X86_ISA_1_V3 (1U << 2) #define GNU_PROPERTY_X86_ISA_1_V4 (1U << 3) Add -z x86-64-baseline linker command line option to mark x86-64-baseline ISA level as needed. bfd/ PR gas/26703 * elfxx-x86.c (_bfd_x86_elf_link_setup_gnu_properties): Generate GNU_PROPERTY_X86_ISA_1_BASELINE for -z x86-64-baseline. binutils/ PR gas/26703 * readelf.c (decode_x86_isa): Handle * GNU_PROPERTY_X86_ISA_1_BASELINE. * testsuite/binutils-all/i386/empty.d: Updated. * testsuite/binutils-all/i386/ibt.d: Likewise. * testsuite/binutils-all/i386/pr21231a.d: Likewise. * testsuite/binutils-all/i386/pr21231b.d: Likewise. * testsuite/binutils-all/i386/shstk.d: Likewise. * testsuite/binutils-all/x86-64/empty-x32.d: Likewise. * testsuite/binutils-all/x86-64/empty.d: Likewise. * testsuite/binutils-all/x86-64/ibt-x32.d: Likewise. * testsuite/binutils-all/x86-64/ibt.d: Likewise. * testsuite/binutils-all/x86-64/pr21231a.d: Likewise. * testsuite/binutils-all/x86-64/pr21231b.d: Likewise. * testsuite/binutils-all/x86-64/pr23494a-x32.d: Likewise. * testsuite/binutils-all/x86-64/pr23494a.d: Likewise. * testsuite/binutils-all/x86-64/pr23494c-x32.d: Likewise. * testsuite/binutils-all/x86-64/pr23494c.d: Likewise. * testsuite/binutils-all/x86-64/pr23494d-x32.d: Likewise. * testsuite/binutils-all/x86-64/pr23494d.d: Likewise. * testsuite/binutils-all/x86-64/pr23494e-x32.d: Likewise. * testsuite/binutils-all/x86-64/pr23494e.d: Likewise. * testsuite/binutils-all/x86-64/shstk-x32.d: Likewise. * testsuite/binutils-all/x86-64/shstk.d: Likewise. gas/ PR gas/26703 * config/tc-i386.c (output_insn): Update for GNU_PROPERTY_X86_ISA_1_BASELINE. * testsuite/gas/i386/property-1.d: Updated. * testsuite/gas/i386/property-2.d: Likewise. * testsuite/gas/i386/property-3.d: Likewise. * testsuite/gas/i386/property-4.d: Likewise. * testsuite/gas/i386/property-5.d: Likewise. * testsuite/gas/i386/property-6.d: Likewise. * testsuite/gas/i386/property-11.d: Likewise. * testsuite/gas/i386/property-12.d: Likewise. * testsuite/gas/i386/x86-64-property-1.d: Likewise. * testsuite/gas/i386/x86-64-property-2.d: Likewise. * testsuite/gas/i386/x86-64-property-3.d: Likewise. * testsuite/gas/i386/x86-64-property-4.d: Likewise. * testsuite/gas/i386/x86-64-property-5.d: Likewise. * testsuite/gas/i386/x86-64-property-6.d: Likewise. * testsuite/gas/i386/x86-64-property-11.d: Likewise. * testsuite/gas/i386/x86-64-property-12.d: Likewise. include/ PR gas/26703 * elf/common.h (GNU_PROPERTY_X86_ISA_1_BASELINE): New. (GNU_PROPERTY_X86_ISA_1_V2): Uppdated. (GNU_PROPERTY_X86_ISA_1_V3): Likewise. (GNU_PROPERTY_X86_ISA_1_V4): Likewise. ld/ PR gas/26703 * NEWS: Mention -z x86-64-baseline. * ld.texi: Document -z x86-64-baseline. * emulparams/x86-64-level.sh: Handle -z x86-64-baseline. * testsuite/ld-elf/x86-feature-1a.rd: Update. * testsuite/ld-elf/x86-feature-1b.rd: Likewise. * testsuite/ld-elf/x86-feature-1c.rd: Likewise. * testsuite/ld-elf/x86-feature-1d.rd: Likewise. * testsuite/ld-elf/x86-feature-1e.rd: Likewise. * testsuite/ld-i386/pr23372c.d: Likewise. * testsuite/ld-i386/pr23486c.d: Likewise. * testsuite/ld-i386/pr23486d.d: Likewise. * testsuite/ld-i386/pr24322a.d: Likewise. * testsuite/ld-i386/pr24322b.d: Likewise. * testsuite/ld-i386/property-1a.r: Likewise. * testsuite
[Bug gold/18874] src/gold/gc.h:207: performance tweek ?
https://sourceware.org/bugzilla/show_bug.cgi?id=18874 Tom Tromey changed: What|Removed |Added CC||tromey at sourceware dot org Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #2 from Tom Tromey --- Looks like this was fixed by commit e173ea00c2941af42ea4e2267446d6039a70da6e Author: Joshua Oreman Date: Sat May 11 07:27:10 2019 +0800 Fix problem with ICF where diffs in EH frame info is ignored. PR gold/21066 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26806] Suspected linker bug with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=26806 --- Comment #10 from Nick Clifton --- (In reply to Alan Modra from comment #8) > Please show it to be broken it if you can! I doubt that I could do that myself. But for what it is worth I have applied your patch to the latest Fedora rawhide binutils: binutils-2.35.1-11.fc34 So if bug reports of builds being broken start to show up I will let you know... :-) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26822] New: How to prevent a STT_FILE with absolute path in the linked image
https://sourceware.org/bugzilla/show_bug.cgi?id=26822 Bug ID: 26822 Summary: How to prevent a STT_FILE with absolute path in the linked image Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- ld.bfd copies non-STT_SECTION local symbols from input object files. If an object file does not have STT_FILE symbols (no .file directive) but has non-STT_SECTION local symbols, ld.bfd synthesizes a STT_FILE symbol. bfd/elflink.c /* In the absence of debug info, bfd_find_nearest_line uses FILE symbols to determine the source file for local function symbols. Provide a FILE symbol here if input files lack such, so that their symbols won't be associated with a previous input file. It's not the source file, but the best we can do. */ The ELF spec says: > STT_FILE - Conventionally, the symbol's name gives the name of the source > file associated with the object file. A file symbol has STB_LOCAL binding, > its section index is SHN_ABS, and it precedes the other STB_LOCAL symbols for > the file, if it is present. Without the synthesized STT_FILE, consumers may attribute the copied STB_LOCAL symbols to the previous file (with STT_FILE). On ARM, mapping symbols (e.g. $a) can be everywhere. For crti.o and crtn.o, compiler drivers pass the absolute paths to ld, so the synthesized STT_FILE has an absolute path. However, if the user wants to pursue "Local determinism: Like incremental basic determinism, but builds are also independent of the name of the build directory" (https://blog.llvm.org/2019/11/deterministic-builds-with-clang-and-lld.html), the absolute path can actually get in the way. The usual -fdebug-prefix-map (-ffile-prefix-map) is not effective to the ld synthesized paths. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26808] [2.36 Regression] readelf: Warning: DIE at offset 0x232 refers to abbreviation number 77 which does not exist
https://sourceware.org/bugzilla/show_bug.cgi?id=26808 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from H.J. Lu --- Fixed for 2.36. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25882] .gnu.attributes are not checked for shared libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=25882 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #7 from Rich Felker --- This should be reverted. It breaks linking anything that uses libgcc_s.so.1 on musl libc, since gcc builds ld128 floating point functions into libgcc unconditionally, but musl's ABI does not use them. (And in general it breaks any use of -mlong-double-64 in a setting where shared libgcc will be used.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25882] .gnu.attributes are not checked for shared libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=25882 --- Comment #8 from Rich Felker --- Also note that while, for musl targets, this issue could also be fixed just by getting gcc not to build its ld128 functions in libgcc_s, there are also people using glibc's ld64 ABI, and glibc necessarily has (as ABI) both ld64 and ld128 functions in the same shared library. So I don't think there's any complete fix without reverting this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25882] .gnu.attributes are not checked for shared libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=25882 --- Comment #9 from Rich Felker --- OK, I should have read more before commenting. My comments in particular pertain specifically to powerpc64 although other archs might be affected too. I see that the error was downgraded to a warning since the breaking change first appeared in a release, which is an improvement, but it's still likely going to lead to people doing very wrong things based on that warning. For example, Alpine Linux got this merge request: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13547 which would have created a broken Frankenstein-ABI to make the error message go away rather than fixing the problem. I can envision folks doing the exact same sort of thing when they see a warning, because I get/see wrong "warning fix" patches all the time for compiler warnings. -- You are receiving this mail because: You are on the CC list for the bug.
