[Bug gprofng/29663] gprofng fails to find libgp-collector.so
https://sourceware.org/bugzilla/show_bug.cgi?id=29663 Kurt Goebel changed: What|Removed |Added Status|NEW |ASSIGNED CC||kurt.goebel at oracle dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29667] gprofng build with srcdir != builddir writes into the source dir
https://sourceware.org/bugzilla/show_bug.cgi?id=29667 Kurt Goebel changed: What|Removed |Added Status|NEW |ASSIGNED CC||kurt.goebel at oracle dot com --- Comment #1 from Kurt Goebel --- similar if not duplicate of https://sourceware.org/bugzilla/show_bug.cgi?id=29465 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29107] gas testsuite parallel jobs fail (gprofng?)
https://sourceware.org/bugzilla/show_bug.cgi?id=29107 Kurt Goebel changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED CC||kurt.goebel at oracle dot com Ever confirmed|0 |1 Last reconfirmed||2022-10-10 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29667] New: gprofng build with srcdir != builddir writes into the source dir
https://sourceware.org/bugzilla/show_bug.cgi?id=29667 Bug ID: 29667 Summary: gprofng build with srcdir != builddir writes into the source dir Product: binutils Version: 2.40 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: doko at debian dot org Target Milestone: --- seen with the 2.39 branch and the trunk, the gprofng build writes the file gprofng/doc/version.texi into the srcdir instead of the builddir. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29666] New: [2.40 Regression] gas/riscv/insn fails on riscv64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=29666 Bug ID: 29666 Summary: [2.40 Regression] gas/riscv/insn fails on riscv64-linux-gnu Product: binutils Version: 2.40 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: doko at debian dot org Target Milestone: --- seen with trunk 20221004 on riscv64-linux-gnu, succeeding with 2.39 Running /<>/gas/testsuite/gas/riscv/riscv.exp ... FAIL: gas/riscv/insn-na FAIL: gas/riscv/insn -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29665] New: objcopy should display the original name, not a temporary name
https://sourceware.org/bugzilla/show_bug.cgi?id=29665 Bug ID: 29665 Summary: objcopy should display the original name, not a temporary name Product: binutils Version: 2.39 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: doko at debian dot org Target Milestone: --- forwarded from https://bugs.debian.org/960686 That "gibberish" name is an internal name used in objcopy and it makes more sense to fix this bug at its roots (which would be in objcopy itself), reassigning accordingly. Reproducer: """ $ cd /tmp $ cp /bin/ls . $ objcopy --add-gnu-debuglink /bin/test ls objcopy: stnJQXz3: debuglink section already exists """ The "stnJQXz3" name is indeed not very helpful and should have said "ls" (or "/tmp/ls" in this case) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29663] New: gprofng fails to find libgp-collector.so
https://sourceware.org/bugzilla/show_bug.cgi?id=29663 Bug ID: 29663 Summary: gprofng fails to find libgp-collector.so Product: binutils Version: 2.39 Status: NEW Severity: normal Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: doko at debian dot org Target Milestone: --- seen on a multiarch Linux system (Debian / Ubuntu): https://bugs.debian.org/1016725 It looks like the *only* way to find the plugin directory is the configuration file, which currently lists: # Set path where the gprofng libraries are installed preload_libdirs ../lib:../lib32:../lib64 Changing that to preload_libdirs ../lib/x86_64-linux-gnu:../lib:../lib32:../lib64 lets gprofng work (although the configuration file is then architecture dependent, which creates another problem for an Multi-Arch: all package. lib32 and lib64 are deprecated on multiarch systems, making this ../lib32 ../lib64 biarch dirs obsolete on Debian and Ubuntu. gprofng should have a default path, derived from the --libdir configure option which is also used for a lookup. Relying on a config file for default operation should not be necessary. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29655] s390x gas generates PC32DBL instead of PLT32DBL for function call
https://sourceware.org/bugzilla/show_bug.cgi?id=29655 --- Comment #19 from Andreas Krebbel --- (In reply to Rui Ueyama from comment #18) > Was there any reason to limit it to R_390_64 and R_390_PC32DBL? These were the only relocs which made sense to me as 64 bit pointers. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29655] s390x gas generates PC32DBL instead of PLT32DBL for function call
https://sourceware.org/bugzilla/show_bug.cgi?id=29655 --- Comment #18 from Rui Ueyama --- Was there any reason to limit it to R_390_64 and R_390_PC32DBL? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29655] s390x gas generates PC32DBL instead of PLT32DBL for function call
https://sourceware.org/bugzilla/show_bug.cgi?id=29655 --- Comment #17 from Andreas Krebbel --- I have attached a patch for the testcase in Comment 14. Turns out that we also have to zero out the symbol value in order to avoid function pointer references in the main binary to be wired up to the main binary PLT slot. The patch also helps with my non-pic testcase from Comment 12. However, here it relies on the @PLT marker on the symbol in the function call. I think with that we are circling back to Rui's original question from Comment 2. How should the linker recognize whether a symbol is used only as part of direct function calls or whether its address is taken? All the linker can look at are the relocations. Mold currently relies on symbols in direct function calls to use a PLT32DBL reloc while function pointer references use PC32DBL or R_390_64. With the attached patch the same will apply to ld. Clang always adds the @PLT marker and GCC starts doing this with version 12. So I think we are ok. I would rather not want to backport the GCC patch to older versions. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29655] s390x gas generates PC32DBL instead of PLT32DBL for function call
https://sourceware.org/bugzilla/show_bug.cgi?id=29655 --- Comment #16 from Andreas Krebbel --- Created attachment 14386 --> https://sourceware.org/bugzilla/attachment.cgi?id=14386=edit Experimental Fix This patch fixes the testcase from comment 14. No testsuite regressions in the Binutils testsuite. -- You are receiving this mail because: You are on the CC list for the bug.
