[Bug gprofng/30195] [display text] Source code location can not be found
https://sourceware.org/bugzilla/show_bug.cgi?id=30195 --- Comment #4 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Vladimir Mezentsev : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f4bcff7caea39dd033c9faac050b1a6520406248 commit f4bcff7caea39dd033c9faac050b1a6520406248 Author: Vladimir Mezentsev Date: Fri Mar 10 13:25:44 2023 -0800 gprofng: PR30195 [display text] Source code location can not be found gprofng/ChangeLog 2023-03-10 Vladimir Mezentsev PR gprofng/30195 gprofng/src/DwarfLib.cc (DwrLineRegs::reset): Set 'file = 1;'. -- You are receiving this mail because: You are on the CC list for the bug.
[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 Fangrui Song changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #13 from Fangrui Song --- Fixed for 2.41 -- You are receiving this mail because: You are on the CC list for the bug.
[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 #12 from cvs-commit at gcc dot gnu.org ---
The master branch has been updated by Fangrui Song :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2cef48423031d23d319692ceced5ad0110625f69
commit 2cef48423031d23d319692ceced5ad0110625f69
Author: Fangrui Song
Date: Fri Mar 10 11:55:09 2023 -0800
ld: Allow R_386_GOT32 for call *__tls_get_addr@GOT(%reg)
Similar to d58854b6dd88e05dbf2a5d1c32c5acb7bd6ea274 for x86_64.
_Thread_local int a;
int main() { return a; }
% gcc -m32 -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
/usr/bin/ld.bfd: /tmp/ccR8Yexy.o: TLS transition from R_386_TLS_GD to
R_386_TLS_IE_32 against `a' at 0x15 in section `.text' failed
/usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status
This commit fixes the issue.
There is an argument that the -fno-plt TLS sequence was added after
R_386_GOT32X was required for call *func@GOT(%ebx), so R_386_GOT32 was
intended to be unsupported.
Unfortunately this standpoint has caused interop difficulty: some
projects specify -mrelax-relocations=no to build relocatable object
files compatible with older linkers (e.g.
https://github.com/IHaskell/IHaskell/issues/636) or do so by accident
(e.g. https://github.com/rust-lang/rust/pull/106511 not addressed as of
today). Many uses have not been cleaned up in practice, and compiling
with -fno-plt will lead to the `TLS transition from R_386_TLS_GD ...`
error which is hard to reason about.
It seems easier to apply this simple change to prevent the footgun.
PR ld/24784
* bfd/elf32-i386.c (elf_i386_check_tls_transition): Allow R_386_GOT32.
--
You are receiving this mail because:
You are on the CC list for the bug.
[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 #11 from cvs-commit at gcc dot gnu.org ---
The master branch has been updated by Fangrui Song :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d58854b6dd88e05dbf2a5d1c32c5acb7bd6ea274
commit d58854b6dd88e05dbf2a5d1c32c5acb7bd6ea274
Author: Fangrui Song
Date: Fri Mar 10 11:53:32 2023 -0800
ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)
_Thread_local int a;
int main() { return a; }
% gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
/usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to
R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
/usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status
This commit fixes the issue.
There is an argument that the -fno-plt TLS sequence was added after
R_X86_64_GOTPCRELX was required for call, so R_X86_64_GOTPCREL was
intended to be unsupported.
Unfortunately this standpoint has caused interop difficulty: some
projects specify -mrelax-relocations=no to build relocatable object
files compatible with older linkers (e.g.
https://github.com/IHaskell/IHaskell/issues/636) or do so by accident
(e.g. https://github.com/rust-lang/rust/pull/106511 not addressed as of
today). Many uses have not been cleaned up in practice, and compiling
with -fno-plt will lead to the `TLS transition from R_X86_64_TLSGD ...`
error which is hard to reason about.
There is another argument which may be weaker but relevant to the
necessity of -mrelax-relocations=no: HWAddressSanitizer x86-64 will
likely need some assembler support to disable relaxation. Without the
support and if the compiler needs to support many gas version, the
simplest solution would be to use -Wa,-mrelax-relocations=no.
PR ld/24784
* bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
R_X86_64_GOTPCREL.
--
You are receiving this mail because:
You are on the CC list for the bug.
Issue 56863 in oss-fuzz: binutils:fuzz_as: Use-of-uninitialized-value in S_IS_DEFINED
Updates: Labels: -restrict-view-commit Comment #3 on issue 56863 by sheriffbot: binutils:fuzz_as: Use-of-uninitialized-value in S_IS_DEFINED https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=56863#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 56791 in oss-fuzz: binutils:fuzz_objdump_safe: Out-of-memory in fuzz_objdump_safe
Updates: Labels: -restrict-view-commit Comment #3 on issue 56791 by sheriffbot: binutils:fuzz_objdump_safe: Out-of-memory in fuzz_objdump_safe https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=56791#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 56797 in oss-fuzz: binutils:fuzz_as: Unexpected-exit in xexit
Updates: Labels: -restrict-view-commit Comment #3 on issue 56797 by sheriffbot: binutils:fuzz_as: Unexpected-exit in xexit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=56797#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug gold/30217] New: PowerPC: R_PPC64_JMP_SLOT relocation on local std::map symbol when using -mlongcall and --version-script
https://sourceware.org/bugzilla/show_bug.cgi?id=30217
Bug ID: 30217
Summary: PowerPC: R_PPC64_JMP_SLOT relocation on local std::map
symbol when using -mlongcall and --version-script
Product: binutils
Version: 2.40
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: dante at cadence dot com
CC: ian at airs dot com
Target Milestone: ---
Created attachment 14743
--> https://sourceware.org/bugzilla/attachment.cgi?id=14743=edit
Reproducer program
runme.sh:
-
#!/bin/sh
#GCC_ROOT=/home/dante/gcc/v9.3.0
GCC_ROOT=/home/dante/gcc/v12.2.0
BINUTILS_ROOT=/home/dante/binutils/v2.40
export PATH="${BINUTILS_ROOT}/bin:${GCC_ROOT}/bin:$PATH"
export LD_LIBRARY_PATH="${GCC_ROOT}/lib64"
LD=gold
ld.$LD -V | head -1
rm *.cpp *.so exe mapfile >& /dev/null
cat > exe.cpp <<- EOM
extern "C" {
int fooPublic();
int main() {
return fooPublic();
}
}
EOM
cat > libfoo.cpp <<- EOM
#include
static std::map fooMap;
extern "C" {
int fooPublic() { return 0; }
}
EOM
cat > mapfile <<- EOM
{
global: fooPublic;
local: *;
};
EOM
g++ -B${BINUTILS_ROOT}/bin \
-mlongcall -fPIC libfoo.cpp \
-Wl,--version-script=mapfile \
-fuse-ld=$LD \
-shared \
-o libfoo.so
g++ -B${BINUTILS_ROOT}/bin -L. -Wl,-rpath=`pwd` -lfoo exe.cpp -o exe
echo symbols:
nm libfoo.so | grep _ZNSt3mapIiiSt4lessIiESaISt4pairIKiiEEEC1Ev
echo relocations:
readelf -W -r libfoo.so | grep _ZNSt3mapIiiSt4lessIiESaISt4pairIKiiEEEC1Ev
./exe
-
gcc 12.2.0 on ppc64le (bug also happens on gcc 9.3.0):
$ ./runme.sh
GNU gold (GNU Binutils 2.40.0.20230310) 1.16
symbols:
17d8 t _ZNSt3mapIiiSt4lessIiESaISt4pairIKiiEEEC1Ev
relocations:
00020248 00070015 R_PPC64_JMP_SLOT 17d8
_ZNSt3mapIiiSt4lessIiESaISt4pairIKiiEEEC1Ev + 0
./exe: symbol lookup error: /home/dante/tst/pltseq/libfoo.so: undefined symbol:
_ZNSt3mapIiiSt4lessIiESaISt4pairIKiiEEEC1Ev
-
Works when LD=bfd.
Also works when compiling with -mno-pltseq.
Running binutils v2.40 configured with:
./configure --prefix=/home/dante/binutils/v2.40 --enable-shared
--enable-plugins --enable-gold --enable-threads
Confirmed to also fail on binutils 2.38 and 2.39.
--
You are receiving this mail because:
You are on the CC list for the bug.
