[clang] [RFC] [clang][Toolchain] Treat "pc"/"unknown" vendor interchangeable (PR #97802)
https://github.com/azat created https://github.com/llvm/llvm-project/pull/97802
Right now if you have runtime libraries under
lib/x86_64-unknown-linux-gnu you should use --target x86_64-unknown-linux-gnu,
x86_64-pc-linux-gnu will not work.
Treat the interchangeable so that you can use any.
The initial reason for this patch is that debian packages uses
x86_64-pc-linux-gnu, and after they enabled
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR [1], clang cannot find runtime libraries for
sanitizers.
[1]:
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/9ca35f30383d89e4fdd45d15e0eb82c832df4b8c
>From dd290ddc48fd60d29e2c0eb839f9e9a08746d5f2 Mon Sep 17 00:00:00 2001
From: Azat Khuzhin
Date: Fri, 5 Jul 2024 11:15:15 +0200
Subject: [PATCH] [clang][Toolchain] Treat "pc"/"unknown" vendor
interchangeable
Right now if you have runtime libraries under
lib/x86_64-unknown-linux-gnu you should use --target
x86_64-unknown-linux-gnu, x86_64-pc-linux-gnu will not work.
Treat the interchangeable so that you can use any.
The initial reason for this patch is that debian packages uses
x86_64-pc-linux-gnu, and after they enabled
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR [1], clang cannot find runtime
libraries for sanitizers.
[1]:
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/9ca35f30383d89e4fdd45d15e0eb82c832df4b8c
---
clang/lib/Driver/ToolChain.cpp | 21 +
clang/test/Driver/pc-unknown-toolchain.c | 4
2 files changed, 25 insertions(+)
create mode 100644 clang/test/Driver/pc-unknown-toolchain.c
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 977e08390800d..716cbfb43232b 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -765,6 +765,27 @@ ToolChain::getTargetSubDirPath(StringRef BaseDir) const {
if (auto Path = getPathForTriple(getTriple()))
return *Path;
+ // Treat "pc" and "unknown" vendors interchangeable
+ switch (getTriple().getVendor())
+ {
+case Triple::UnknownVendor: {
+ llvm::Triple TripleFallback = Triple;
+ TripleFallback.setVendor(Triple::PC);
+ if (auto Path = getPathForTriple(TripleFallback))
+return *Path;
+ break;
+}
+case Triple::PC: {
+ llvm::Triple TripleFallback = Triple;
+ TripleFallback.setVendor(Triple::UnknownVendor);
+ if (auto Path = getPathForTriple(TripleFallback))
+return *Path;
+ break;
+}
+default:
+ break;
+ }
+
// When building with per target runtime directories, various ways of naming
// the Arm architecture may have been normalised to simply "arm".
// For example "armv8l" (Armv8 AArch32 little endian) is replaced with "arm".
diff --git a/clang/test/Driver/pc-unknown-toolchain.c
b/clang/test/Driver/pc-unknown-toolchain.c
new file mode 100644
index 0..a7e9bb80b0f2d
--- /dev/null
+++ b/clang/test/Driver/pc-unknown-toolchain.c
@@ -0,0 +1,4 @@
+// RUN: %clang -### %s -fsanitize=address --target=x86_64-pc-linux-gnu 2>&1 |
FileCheck -check-prefix=CHECK-ASAN-PC %s
+// CHECK-ASAN-PC: x86_64-unknown-linux-gnu/libclang_rt.asan_static.a
+// RUN: %clang -### %s -fsanitize=address --target=x86_64-unknown-linux-gnu
2>&1 | FileCheck -check-prefix=CHECK-ASAN-UNKNOWN %s
+// CHECK-ASAN-UNKNOWN: x86_64-unknown-linux-gnu/libclang_rt.asan_static.a
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RFC] [clang][Toolchain] Treat "pc"/"unknown" vendor interchangeable (PR #97802)
https://github.com/azat edited https://github.com/llvm/llvm-project/pull/97802 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RFC] [clang][Toolchain] Treat "pc"/"unknown" vendor interchangeable (PR #97802)
https://github.com/azat updated https://github.com/llvm/llvm-project/pull/97802
>From c2d4c4649004262569a7f1d17077ebd48bb35269 Mon Sep 17 00:00:00 2001
From: Azat Khuzhin
Date: Fri, 5 Jul 2024 11:15:15 +0200
Subject: [PATCH] [clang][Toolchain] Treat "pc"/"unknown" vendor
interchangeable
Right now if you have runtime libraries under
lib/x86_64-unknown-linux-gnu you should use --target
x86_64-unknown-linux-gnu, x86_64-pc-linux-gnu will not work.
Treat the interchangeable so that you can use any.
The initial reason for this patch is that debian packages uses
x86_64-pc-linux-gnu, and after they enabled
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR [1], clang cannot find runtime
libraries for sanitizers.
[1]:
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/9ca35f30383d89e4fdd45d15e0eb82c832df4b8c
---
clang/lib/Driver/ToolChain.cpp | 20
clang/test/Driver/pc-unknown-toolchain.c | 4
2 files changed, 24 insertions(+)
create mode 100644 clang/test/Driver/pc-unknown-toolchain.c
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 977e08390800d..43ec3c234ba14 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -765,6 +765,26 @@ ToolChain::getTargetSubDirPath(StringRef BaseDir) const {
if (auto Path = getPathForTriple(getTriple()))
return *Path;
+ // Treat "pc" and "unknown" vendors interchangeable
+ switch (getTriple().getVendor()) {
+ case Triple::UnknownVendor: {
+llvm::Triple TripleFallback = Triple;
+TripleFallback.setVendor(Triple::PC);
+if (auto Path = getPathForTriple(TripleFallback))
+ return *Path;
+break;
+ }
+ case Triple::PC: {
+llvm::Triple TripleFallback = Triple;
+TripleFallback.setVendor(Triple::UnknownVendor);
+if (auto Path = getPathForTriple(TripleFallback))
+ return *Path;
+break;
+ }
+ default:
+break;
+ }
+
// When building with per target runtime directories, various ways of naming
// the Arm architecture may have been normalised to simply "arm".
// For example "armv8l" (Armv8 AArch32 little endian) is replaced with "arm".
diff --git a/clang/test/Driver/pc-unknown-toolchain.c
b/clang/test/Driver/pc-unknown-toolchain.c
new file mode 100644
index 0..a7e9bb80b0f2d
--- /dev/null
+++ b/clang/test/Driver/pc-unknown-toolchain.c
@@ -0,0 +1,4 @@
+// RUN: %clang -### %s -fsanitize=address --target=x86_64-pc-linux-gnu 2>&1 |
FileCheck -check-prefix=CHECK-ASAN-PC %s
+// CHECK-ASAN-PC: x86_64-unknown-linux-gnu/libclang_rt.asan_static.a
+// RUN: %clang -### %s -fsanitize=address --target=x86_64-unknown-linux-gnu
2>&1 | FileCheck -check-prefix=CHECK-ASAN-UNKNOWN %s
+// CHECK-ASAN-UNKNOWN: x86_64-unknown-linux-gnu/libclang_rt.asan_static.a
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RFC] [clang][Toolchain] Treat "pc"/"unknown" vendor interchangeable (PR #97802)
https://github.com/azat updated https://github.com/llvm/llvm-project/pull/97802
>From 1d78d8362a4a10c8d8c2d5a78171e3fb5774daef Mon Sep 17 00:00:00 2001
From: Azat Khuzhin
Date: Fri, 5 Jul 2024 11:15:15 +0200
Subject: [PATCH] [clang][Toolchain] Treat "pc"/"unknown" vendor
interchangeable
Right now if you have runtime libraries under
lib/x86_64-unknown-linux-gnu you should use --target
x86_64-unknown-linux-gnu, x86_64-pc-linux-gnu will not work.
Treat the interchangeable so that you can use any.
The initial reason for this patch is that debian packages uses
x86_64-pc-linux-gnu, and after they enabled
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR [1], clang cannot find runtime
libraries for sanitizers.
[1]:
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/9ca35f30383d89e4fdd45d15e0eb82c832df4b8c
---
clang/lib/Driver/ToolChain.cpp | 20
clang/test/Driver/pc-unknown-toolchain.c | 6 ++
2 files changed, 26 insertions(+)
create mode 100644 clang/test/Driver/pc-unknown-toolchain.c
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 977e08390800d..43ec3c234ba14 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -765,6 +765,26 @@ ToolChain::getTargetSubDirPath(StringRef BaseDir) const {
if (auto Path = getPathForTriple(getTriple()))
return *Path;
+ // Treat "pc" and "unknown" vendors interchangeable
+ switch (getTriple().getVendor()) {
+ case Triple::UnknownVendor: {
+llvm::Triple TripleFallback = Triple;
+TripleFallback.setVendor(Triple::PC);
+if (auto Path = getPathForTriple(TripleFallback))
+ return *Path;
+break;
+ }
+ case Triple::PC: {
+llvm::Triple TripleFallback = Triple;
+TripleFallback.setVendor(Triple::UnknownVendor);
+if (auto Path = getPathForTriple(TripleFallback))
+ return *Path;
+break;
+ }
+ default:
+break;
+ }
+
// When building with per target runtime directories, various ways of naming
// the Arm architecture may have been normalised to simply "arm".
// For example "armv8l" (Armv8 AArch32 little endian) is replaced with "arm".
diff --git a/clang/test/Driver/pc-unknown-toolchain.c
b/clang/test/Driver/pc-unknown-toolchain.c
new file mode 100644
index 0..01eaebb6d0eec
--- /dev/null
+++ b/clang/test/Driver/pc-unknown-toolchain.c
@@ -0,0 +1,6 @@
+// UNSUPPORTED: system-windows
+
+// RUN: %clang -### %s -fsanitize=address --target=x86_64-pc-linux-gnu 2>&1 |
FileCheck -check-prefix=CHECK-ASAN-PC %s
+// CHECK-ASAN-PC: x86_64-unknown-linux-gnu/libclang_rt.asan_static.a
+// RUN: %clang -### %s -fsanitize=address --target=x86_64-unknown-linux-gnu
2>&1 | FileCheck -check-prefix=CHECK-ASAN-UNKNOWN %s
+// CHECK-ASAN-UNKNOWN: x86_64-unknown-linux-gnu/libclang_rt.asan_static.a
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RFC] [clang][Toolchain] Treat "pc"/"unknown" vendor interchangeable (PR #97802)
azat wrote: I've excluded new test for windows (https://buildkite.com/llvm-project/github-pull-requests/builds/78458) https://github.com/llvm/llvm-project/pull/97802 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] [libunwind] fix unwinding from signal handler (PR #92291)
azat wrote: Can someone take a look? Maybe @MaskRay @compnerd (according to the most frequent reviewers from `Reviewed By` tag) https://github.com/llvm/llvm-project/pull/92291 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] [libunwind] fix unwinding from signal handler (PR #92291)
@@ -365,7 +365,12 @@ int DwarfInstructions::stepWithDwarf(A &addressSpace, pint_t pc, // Return address is address after call site instruction, so setting IP to // that does simulates a return. - newRegisters.setIP(returnAddress); + // + // In case of this is frame of signal handler, the IP should be + // incremented, because the IP saved in the signal handler points to + // first non-executed instruction, while FDE/CIE expects IP to be after + // the first non-executed instruction. + newRegisters.setIP(returnAddress + cieInfo.isSignalFrame); azat wrote: >The idea here is that cieInfo.isSignalFrame is a boolean and will increment by >1 Correct >However, how do we ensure that the IP should be incremented by 1 and not say 4 >or some other size for the instruction? This is only needed to execute proper CFI here - https://github.com/llvm/llvm-project/blob/23d1d959583c35e6eab7e3e70d4c16449b418563/libunwind/src/DwarfParser.hpp#L433-L437 So 1 is enough https://github.com/llvm/llvm-project/pull/92291 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RFC] [clang][Toolchain] Treat "pc"/"unknown" vendor interchangeable (PR #97802)
azat wrote: >How is Rust built? If the system compiler-rt libraries are installed to >/usr/lib/llvm-18/lib/clang/18/lib/x86_64-pc-linux-gnu, which means that >LLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-linux-gnu, the Rust build should also use >x86_64-pc-linux-gnu. The problem is not only with Rust, it is any invocation with non-default `--target` (`--target` != `LLVM_DEFAULT_TARGET_TRIPLE`), and I was fixing a C++ issue not a Rust issue, but I guess it will be covered Here is an example of a problem (assuming `LLVM_DEFAULT_TARGET_TRIPLE` is `x86_64-pc-linux-gnu` (in packages from apt.llvm.org)): - without explicit `-target` - everything is correct, it uses `/usr/lib/llvm-18/lib/clang/18/lib/x86_64-pc-linux-gnu/libclang_rt.asan.a` ``` $ docker run --rm -it clickhouse/binary-builder:9e5aa3a43749 clang-18 -### -xc - -fsanitize=address Ubuntu clang version 18.1.8 (++20240615103753+3b5b5c1ec4a3-1~exp1~20240615223858.136) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin "/usr/lib/llvm-18/bin/clang" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-emit-obj" "-mrelax-all" "-dumpdir" "a-" "-disable-free" "-clear-ast-before-backend" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "-" "-mrelocation-model" "pic" "-pic-level" "2" "-pic-is-pie" "-mframe-pointer=all" "-fmath-errno" "-ffp-contract=on" "-fno-rounding-math" "-mconstructor-aliases" "-funwind-tables=2" "-target-cpu" "x86-64" "-tune-cpu" "generic" "-debugger-tuning=gdb" "-fdebug-compilation-dir=/workdir" "-fcoverage-compilation-dir=/workdir" "-resource-dir" "/usr/lib/llvm-18/lib/clang/18" "-internal-isystem" "/usr/lib/llvm-18/lib/clang/18/include" "-internal-isystem" "/usr/local/include" "-internal-isystem" "/usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include" "-internal-externc-isystem" "/usr/include/x86_64-linux-gnu" "-internal-externc-isystem" "/include" "-internal-externc-isystem" "/usr/include" "-ferror-limit" "19" "-fmessage-length=295" "-fsanitize=address" "-fsanitize-system-ignorelist=/usr/lib/llvm-18/lib/clang/18/share/asan_ignorelist.txt" "-fno-sanitize-memory-param-retval" "-fsanitize-address-use-after-scope" "-fsanitize-address-globals-dead-stripping" "-fno-assume-sane-operator-new" "-fgnuc-version=4.2.1" "-fskip-odr-check-in-gmf" "-fcolor-diagnostics" "-faddrsig" "-D__GCC_HAVE_DWARF2_CFI_ASM=1" "-o" "/tmp/--ed21dd.o" "-x" "c" "-" "/usr/bin/ld" "-z" "relro" "--hash-style=gnu" "--build-id" "--eh-frame-hdr" "-m" "elf_x86_64" "-pie" "-dynamic-linker" "/lib64/ld-linux-x86-64.so.2" "-o" "a.out" "/lib/x86_64-linux-gnu/Scrt1.o" "/lib/x86_64-linux-gnu/crti.o" "/usr/bin/../lib/gcc/x86_64-linux-gnu/11/crtbeginS.o" "-L/usr/lib/llvm-18/lib/clang/18/lib/x86_64-pc-linux-gnu" "-L/usr/bin/../lib/gcc/x86_64-linux-gnu/11" "-L/usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../lib64" "-L/lib/x86_64-linux-gnu" "-L/lib/../lib64" "-L/usr/lib/x86_64-linux-gnu" "-L/usr/lib/../lib64" "-L/lib" "-L/usr/lib" "--whole-archive" "/usr/lib/llvm-18/lib/clang/18/lib/x86_64-pc-linux-gnu/libclang_rt.asan_static.a" "--no-whole-archive" "--whole-archive" "/usr/lib/llvm-18/lib/clang/18/lib/x86_64-pc-linux-gnu/libclang_rt.asan.a" "--no-whole-archive" "--dynamic-list=/usr/lib/llvm-18/lib/clang/18/lib/x86_64-pc-linux-gnu/libclang_rt.asan.a.syms" "/tmp/--ed21dd.o" "--no-as-needed" "-lpthread" "-lrt" "-lm" "-ldl" "-lresolv" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/bin/../lib/gcc/x86_64-linux-gnu/11/crtendS.o" "/lib/x86_64-linux-gnu/crtn.o" ``` - but with explicit `-target=x86_64-unknown-linux-gnu`, it try to use `/usr/lib/llvm-18/lib/clang/18/lib/linux/libclang_rt.asan-x86_64.a` (because there is no such file `/usr/lib/llvm-18/lib/clang/18/lib/x86_64-unknown-linux-gnu/libclang_rt.asan.a`), which obviously does not exists, and it will fail eventually ``` $ docker run --rm -it clickhouse/binary-builder:9e5aa3a43749 clang-18 -target x86_64-unknown-linux-gnu -### -xc - -fsanitize=address Ubuntu clang version 18.1.8 (++20240615103753+3b5b5c1ec4a3-1~exp1~20240615223858.136) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin "/usr/lib/llvm-18/bin/clang" "-cc1" "-triple" "x86_64-unknown-linux-gnu" "-emit-obj" "-mrelax-all" "-dumpdir" "a-" "-disable-free" "-clear-ast-before-backend" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "-" "-mrelocation-model" "pic" "-pic-level" "2" "-pic-is-pie" "-mframe-pointer=all" "-fmath-errno" "-ffp-contract=on" "-fno-rounding-math" "-mconstructor-aliases" "-funwind-tables=2" "-target-cpu" "x86-64" "-tune-cpu" "generic" "-debugger-tuning=gdb" "-fdebug-compilation-dir=/workdir" "-fcoverage-compilation-dir=/workdir" "-resource-dir" "/usr/lib/llvm-18/lib/clang/18" "-internal-isystem" "/usr/lib/llvm-18/lib/clang/18/include" "-internal-isystem" "/usr/local/include" "-internal-isystem" "/usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../x8
[libunwind] [libunwind] fix unwinding from signal handler (PR #92291)
@@ -365,7 +365,12 @@ int DwarfInstructions::stepWithDwarf(A &addressSpace, pint_t pc, // Return address is address after call site instruction, so setting IP to // that does simulates a return. - newRegisters.setIP(returnAddress); + // + // In case of this is frame of signal handler, the IP should be + // incremented, because the IP saved in the signal handler points to + // first non-executed instruction, while FDE/CIE expects IP to be after + // the first non-executed instruction. + newRegisters.setIP(returnAddress + cieInfo.isSignalFrame); azat wrote: >Could the register state not being used for anything else in between and thus >be misleading? Hm, I don't see how it is possible... https://github.com/llvm/llvm-project/pull/92291 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] [libunwind] fix unwinding from signal handler (PR #92291)
@@ -365,7 +365,12 @@ int DwarfInstructions::stepWithDwarf(A &addressSpace, pint_t pc, // Return address is address after call site instruction, so setting IP to // that does simulates a return. - newRegisters.setIP(returnAddress); + // + // In case of this is frame of signal handler, the IP should be + // incremented, because the IP saved in the signal handler points to + // first non-executed instruction, while FDE/CIE expects IP to be after + // the first non-executed instruction. + newRegisters.setIP(returnAddress + cieInfo.isSignalFrame); azat wrote: OK, I see, thanks. I can move this logic into `DwarfInstructions::stepWithDwarf`, but still, the IP will be different in case of regular unwind (after first non executed instruction) and unwind from signal (before first non-executed instruction) https://github.com/llvm/llvm-project/pull/92291 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] [libunwind] fix unwinding from signal handler (PR #92291)
@@ -365,7 +365,12 @@ int DwarfInstructions::stepWithDwarf(A &addressSpace, pint_t pc, // Return address is address after call site instruction, so setting IP to // that does simulates a return. - newRegisters.setIP(returnAddress); + // + // In case of this is frame of signal handler, the IP should be + // incremented, because the IP saved in the signal handler points to + // first non-executed instruction, while FDE/CIE expects IP to be after + // the first non-executed instruction. + newRegisters.setIP(returnAddress + cieInfo.isSignalFrame); azat wrote: So you think moving this logic into `stepWithDwarf` will not cause any concerns? https://github.com/llvm/llvm-project/pull/92291 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] [libunwind] fix unwinding from signal handler (PR #92291)
https://github.com/azat updated https://github.com/llvm/llvm-project/pull/92291
>From 7066c0d3c7e84ccfdaeebd3b279bcdd91955ec7b Mon Sep 17 00:00:00 2001
From: Azat Khuzhin
Date: Wed, 15 May 2024 08:17:22 +0200
Subject: [PATCH] [libunwind] fix unwinding from signal handler
In case of this is frame of signal handler, the IP should be
incremented, because the IP saved in the signal handler points to first
non-executed instruction, while FDE/CIE expects IP to be after the
first non-executed instruction.
v2: move the increment from DwarfInstructions::stepWithDwarf()
into the UnwindCursor::setInfoBasedOnIPRegister() to avoid
exposing posslibly unaligned IP (also note, that this matches with gcc
implementation as well)
Refs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
---
libunwind/src/UnwindCursor.hpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libunwind/src/UnwindCursor.hpp b/libunwind/src/UnwindCursor.hpp
index 677e842d8a22b..feaadb58f5f6e 100644
--- a/libunwind/src/UnwindCursor.hpp
+++ b/libunwind/src/UnwindCursor.hpp
@@ -2589,6 +2589,12 @@ void UnwindCursor::setInfoBasedOnIPRegister(bool
isReturnAddress) {
--pc;
#endif
+ // In case of this is frame of signal handler, the IP saved in the signal
+ // handler points to first non-executed instruction, while FDE/CIE expects IP
+ // to be after the first non-executed instruction.
+ if (_isSignalFrame)
+++pc;
+
// Ask address space object to find unwind sections for this pc.
UnwindInfoSections sects;
if (_addressSpace.findUnwindSections(pc, sects)) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] [libunwind] fix unwinding from signal handler (PR #92291)
@@ -365,7 +365,12 @@ int DwarfInstructions::stepWithDwarf(A &addressSpace, pint_t pc, // Return address is address after call site instruction, so setting IP to // that does simulates a return. - newRegisters.setIP(returnAddress); + // + // In case of this is frame of signal handler, the IP should be + // incremented, because the IP saved in the signal handler points to + // first non-executed instruction, while FDE/CIE expects IP to be after + // the first non-executed instruction. + newRegisters.setIP(returnAddress + cieInfo.isSignalFrame); azat wrote: @compnerd I've moved this logic into `UnwindCursor::setInfoBasedOnIPRegister`, and verified it with the initial reproducer (it is too complex to convert it to a test) - the patch works correctly https://github.com/llvm/llvm-project/pull/92291 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RFC] [clang][Toolchain] Treat "pc"/"unknown" vendor interchangeable (PR #97802)
azat wrote: @MaskRay you still think that it does not worth to make this two targets (`x86_64-**pc**-linux-gnu` and `x86_64-**unknown**-linux-gnu`) interchangeable? https://github.com/llvm/llvm-project/pull/97802 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RFC] [clang][Toolchain] Treat "pc"/"unknown" vendor interchangeable (PR #97802)
azat wrote: >If you specify the wrong --target= (avoid -target , deprecated since Clang >3.4), clangDriver will not find the compiler-rt library. >This works as intended. But isn't this odd, that you depends on `LLVM_DEFAULT_TARGET_TRIPLE`? https://github.com/llvm/llvm-project/pull/97802 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] [libunwind] fix unwinding from signal handler (PR #92291)
https://github.com/azat created https://github.com/llvm/llvm-project/pull/92291 In case of this is frame of signal handler, the IP should be incremented, because the IP saved in the signal handler points to first non-executed instruction, while FDE/CIE expects IP to be after the first non-executed instruction. Refs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208 >From 5e3635c1852ac280f06f9e54793d4181d2845b64 Mon Sep 17 00:00:00 2001 From: Azat Khuzhin Date: Wed, 15 May 2024 08:17:22 +0200 Subject: [PATCH] [libunwind] fix unwinding from signal handler In case of this is frame of signal handler, the IP should be incremented, because the IP saved in the signal handler points to first non-executed instruction, while FDE/CIE expects IP to be after the first non-executed instruction. Refs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208 --- libunwind/src/DwarfInstructions.hpp | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/libunwind/src/DwarfInstructions.hpp b/libunwind/src/DwarfInstructions.hpp index bd9ece60ee588..5ea535be4b974 100644 --- a/libunwind/src/DwarfInstructions.hpp +++ b/libunwind/src/DwarfInstructions.hpp @@ -365,7 +365,12 @@ int DwarfInstructions::stepWithDwarf(A &addressSpace, pint_t pc, // Return address is address after call site instruction, so setting IP to // that does simulates a return. - newRegisters.setIP(returnAddress); + // + // In case of this is frame of signal handler, the IP should be + // incremented, because the IP saved in the signal handler points to + // first non-executed instruction, while FDE/CIE expects IP to be after + // the first non-executed instruction. + newRegisters.setIP(returnAddress + cieInfo.isSignalFrame); // Simulate the step by replacing the register set with the new ones. registers = newRegisters; ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] [libunwind] fix unwinding from signal handler (PR #92291)
azat wrote: >[Build and Test libc++ / stage3 (generic-ubsan, libcxx-runners-8-set) >(pull_request) Failing after >10m](https://github.com/llvm/llvm-project/actions/runs/9099207645/job/25013031369?pr=92291) Looks like unrelated? ``` 2024-05-15T17:48:22.3468783Z ##[error]The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled. ``` https://github.com/llvm/llvm-project/pull/92291 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RFC] [clang][Toolchain] Treat "pc"/"unknown" vendor interchangeable (PR #97802)
https://github.com/azat closed https://github.com/llvm/llvm-project/pull/97802 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
