[llvm-bugs] [Bug 48186] New: libunwind does not support rax as CFA register
https://bugs.llvm.org/show_bug.cgi?id=48186
Bug ID: 48186
Summary: libunwind does not support rax as CFA register
Product: libc++abi
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedb...@nondot.org
Reporter: man...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
libunwind does not understand the
.cfi_def_cfa_register %rax
instruction.
This is because register rax has number zero.
The code in DwarfInstructions.hpp in getCFA function is the following:
https://github.com/llvm/llvm-project/blob/master/libunwind/src/DwarfInstructions.hpp#L66
The value of prolog.cfaRegister comes from:
https://github.com/llvm/llvm-project/blob/master/libunwind/src/DwarfParser.hpp#L581
If libunwind was build with assertions, assertion will be triggered.
If libunwind was build without assertions, undefined behaviour will happen due
to __builtin_unreachable, and it goes down to the branch where cfaExpression is
evaluated, then segfaults in getULEB128 (by nullptr dereference).
AFAIK, the usage of rax for CFA register is legitimate.
Surprisingly it is not used by the code generated by clang or gcc.
But it happens to be present in some manually written assembly code.
Note that both:
- gcc's builtin unwinder from libgcc;
- HP's "nongnu" libunwind;
work correctly in this case.
Example 1 is OpenSSL and the same in BoringSSL:
https://github.com/openssl/openssl/pull/9624#issuecomment-566309194
It generates asm code during build. The code of crypto/sha/asm/sha256-x86_64.s,
function sha256_block_data_order_ssse3 starts with:
sha256_block_data_order_ssse3:
.cfi_startproc
.Lssse3_shortcut:
movq%rsp,%rax
.cfi_def_cfa_register %rax
pushq %rbx
.cfi_offset %rbx,-16
pushq %rbp
.cfi_offset %rbp,-24
pushq %r12
.cfi_offset %r12,-32
pushq %r13
.cfi_offset %r13,-40
pushq %r14
.cfi_offset %r14,-48
pushq %r15
.cfi_offset %r15,-56
shlq$4,%rdx
subq$96,%rsp
leaq(%rsi,%rdx,4),%rdx
andq$-64,%rsp
movq%rdi,64+0(%rsp)
movq%rsi,64+8(%rsp)
movq%rdx,64+16(%rsp)
movq%rax,88(%rsp)
.cfi_escape 0x0f,0x06,0x77,0xd8,0x00,0x06,0x23,0x08
If we do asynchronous unwinding from somewhere between lines
.cfi_def_cfa_register and .cfi_escape, segfault or assertion will happen.
To trigger the error you need to create a program that will do asynchronous
unwinding quite frequently. This is possible by using timer signals. Note that
libunwind functions are not signal-safe (and neither gcc's or HP's libunwind
are). But it is unrelated from this issue.
Minimal reproducing example:
unwind_test.cpp:
#include
#include
#include
#include
#include
#include
typedef enum {
_URC_NO_REASON = 0,
_URC_OK = 0,
_URC_FOREIGN_EXCEPTION_CAUGHT = 1,
_URC_FATAL_PHASE2_ERROR = 2,
_URC_FATAL_PHASE1_ERROR = 3,
_URC_NORMAL_STOP = 4,
_URC_END_OF_STACK = 5,
_URC_HANDLER_FOUND = 6,
_URC_INSTALL_CONTEXT = 7,
_URC_CONTINUE_UNWIND = 8,
} _Unwind_Reason_Code;
typedef struct _Unwind_Context _Unwind_Context;
typedef _Unwind_Reason_Code (*_Unwind_Trace_Fn)(struct _Unwind_Context *, void
*);
extern "C" _Unwind_Reason_Code _Unwind_Backtrace(_Unwind_Trace_Fn, void *);
extern "C" void test();
[[noreturn]] void __attribute__((__noinline__)) loop()
{
while (true)
test();
}
size_t i = 0;
void handler(int, siginfo_t * info, void *)
{
if (info && info->si_overrun)
return;
++i;
if (i % 1000 == 0)
(void)write(2, ".", 1);
size_t num_frames = 0;
_Unwind_Backtrace([](struct _Unwind_Context *, void * ptr) {
++*static_cast(ptr); return _URC_NO_REASON; }, &num_frames);
if (i % 1 == 0)
std::cerr << num_frames << "\n";
}
[[noreturn]] void error(const char * message)
{
std::cerr << message << "\n";
exit(1);
}
void setupTimer()
{
struct sigaction sa{};
sa.sa_sigaction = handler;
sa.sa_flags = SA_SIGINFO | SA_RESTART;
if (sigemptyset(&sa.sa_mask))
error("Failed to clean signal mask for query profiler");
if (sigaddset(&sa.sa_mask, SIGPROF))
error("Failed to add signal to mask for query profiler");
if (sigaction(SIGPROF, &sa, nullptr))
error("Failed to setup signal handler for query profiler");
struct sigevent sev {};
sev.sigev_notify = SIGEV_SIGNAL;
sev.sigev_signo = SIGPROF;
timer_t timer_id = nullptr;
if (timer_create(CLOCK_MONOTONIC, &sev, &timer_id))
error("Failed to create thread timer");
struct timespec interval{.tv_sec = 0, .tv_nsec = 5};
struct timespec offset{.tv_sec = 0, .tv_nsec = 1};
struct itimerspec timer_spec = {.it_interval = interval, .it_value =
offset};
if (timer_
[llvm-bugs] [Bug 47791] Strange note when calling lvalue-qualified operator member on rvalue
https://bugs.llvm.org/show_bug.cgi?id=47791 Aaron Puchert changed: What|Removed |Added Fixed By Commit(s)||6f84779674a9764c6adee29b9a4 ||8ed3b3f0d5132 Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48187] New: Clang-Unit :: DirectoryWatcher/./DirectoryWatcherTests.exe/DirectoryWatcherTest.ModifyFile flaky on clang-x64-windows-msvc bot
https://bugs.llvm.org/show_bug.cgi?id=48187 Bug ID: 48187 Summary: Clang-Unit :: DirectoryWatcher/./DirectoryWatcherTests.exe/Directory WatcherTest.ModifyFile flaky on clang-x64-windows-msvc bot Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Tooling Assignee: unassignedclangb...@nondot.org Reporter: florian_h...@apple.com CC: llvm-bugs@lists.llvm.org It appears like the test below is flaky on the clang-x64-windows-msvc bot (http://lab.llvm.org:8011/#/builders/123) Clang-Unit :: DirectoryWatcher/./DirectoryWatcherTests.exe/DirectoryWatcherTest.ModifyFile Looking at the recent builds, it seems this causes roughly half of the builds to be red, like http://lab.llvm.org:8011/#/builders/123/builds/909 http://lab.llvm.org:8011/#/builders/123/builds/907 http://lab.llvm.org:8011/#/builders/123/builds/905 http://lab.llvm.org:8011/#/builders/123/builds/903 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48188] New: Assertion failed: (TmpVec.size() > 1), function buildUnmerge, llvm/lib/CodeGen/GlobalISel/MachineIRBuilder.cpp, line 609
https://bugs.llvm.org/show_bug.cgi?id=48188 Bug ID: 48188 Summary: Assertion failed: (TmpVec.size() > 1), function buildUnmerge, llvm/lib/CodeGen/GlobalISel/MachineIRBuilder.cpp, line 609 Product: new-bugs Version: 11.0 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jake.gould...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 24164 --> https://bugs.llvm.org/attachment.cgi?id=24164&action=edit LLVM IR to reproduce the crash ``` % ./bin/llc ../build/bugpoint-reduced-simplified.ll -filetype=obj -mcpu=apple-a12 -march=arm64 -O0 Assertion failed: (TmpVec.size() > 1), function buildUnmerge, file /Users/shepmaster/Projects/llvm-project/llvm/lib/CodeGen/GlobalISel/MachineIRBuilder.cpp, line 609. PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: ./bin/llc ../build/bugpoint-reduced-simplified.ll -filetype=obj -mcpu=apple-a12 -march=arm64 -O0 1. Running pass 'Function Pass Manager' on module '../build/bugpoint-reduced-simplified.ll'. 2. Running pass 'Legalizer' on function '@_ZN3std2io5stdio8print_to17h83af8c48359573cfE' 0 llc 0x000106c22658 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 76 1 llc 0x000106c22b68 PrintStackTraceSignalHandler(void*) + 32 2 llc 0x000106c20bd8 llvm::sys::RunSignalHandlers() + 124 3 llc 0x000106c24ac4 SignalHandler(int) + 208 4 libsystem_platform.dylib 0x00018941cc44 _sigtramp + 56 5 libsystem_pthread.dylib 0x0001893d4c24 pthread_kill + 292 6 libsystem_c.dylib0x00018931c864 abort + 104 7 libsystem_c.dylib0x00018931bb68 err + 0 8 llc 0x00010729d1dc llvm::MachineIRBuilder::buildUnmerge(llvm::ArrayRef, llvm::SrcOp const&) + 168 9 llc 0x00010724c894 llvm::LegalizerHelper::extractParts(llvm::Register, llvm::LLT, int, llvm::SmallVectorImpl&) + 248 10 llc 0x000107244c08 llvm::LegalizerHelper::narrowScalar(llvm::MachineInstr&, unsigned int, llvm::LLT) + 8564 11 llc 0x000107241ec0 llvm::LegalizerHelper::legalizeInstrStep(llvm::MachineInstr&) + 492 12 llc 0x00010722bf48 llvm::Legalizer::legalizeMachineFunction(llvm::MachineFunction&, llvm::LegalizerInfo const&, llvm::ArrayRef, llvm::LostDebugLocObserver&, llvm::MachineIRBuilder&) + 1104 13 llc 0x00010722da2c llvm::Legalizer::runOnMachineFunction(llvm::MachineFunction&) + 964 14 llc 0x00010552ce70 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 460 15 llc 0x000105d4a29c llvm::FPPassManager::runOnFunction(llvm::Function&) + 548 16 llc 0x000105d51a68 llvm::FPPassManager::runOnModule(llvm::Module&) + 116 17 llc 0x000105d4ab08 (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) + 688 18 llc 0x000105d4a6a0 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 272 19 llc 0x000105d51e84 llvm::legacy::PassManager::run(llvm::Module&) + 36 20 llc 0x000104597258 compileModule(char**, llvm::LLVMContext&) + 5304 21 llc 0x000104595590 main + 1288 22 libdyld.dylib0x0001893f0f54 start + 4 ``` Doing some light debugging, I see that `NumParts` is `1`; this is what triggers the assertion. This is computed from `SizeOp0 / NarrowSize` when `SizeOp0` is `120` and `NarrowSize` is `64`. The Rust fork is currently at 2e10b7a39b930ef8d9c4362509d8835b221fbc0a. git-bisect says that the attached LLVM IR compiles successfully starting at db464a3dbf0e8fed363a7b2b9a5b320514ca60f8. However, I don't believe that the bug is actually *fixed*, merely hidden. The commit in question performs more transformations to the code and causes `SizeOp0` to be 128. When I cherry-picked that commit back to the Rust fork, the problems continue to manifest. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48169] Non-Type Template Parameter Passed to Function Crash
https://bugs.llvm.org/show_bug.cgi?id=48169 Richard Smith changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)||dc58cd1480374a6d5dbf87e8a24 ||24811c0003ce3 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48147] Possible bug with expandload.v8i64 for avx512 with zmm disabled.
https://bugs.llvm.org/show_bug.cgi?id=48147 Deepak Rajendrakumaran changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Deepak Rajendrakumaran --- https://reviews.llvm.org/rGa4124e455e641db1e18d4221d2dacb31953fd13b commit fixes the issue. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48189] New: Unsigned Integer Overflow when comparing strings (|s1|<|s2|)
https://bugs.llvm.org/show_bug.cgi?id=48189 Bug ID: 48189 Summary: Unsigned Integer Overflow when comparing strings (|s1|<|s2|) Product: clang Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: jerryc...@gmail.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Sample code: ```cpp bool b = std::string() < "1"; ``` Run this with UBSAN enabled, I got the following output: (`clang 11 using libstdc++, -std=c++20`) ``` /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/basic_string.h:403:51: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned long' #0 0x428a8e in std::__cxx11::basic_string, std::allocator >::_S_compare(unsigned long, unsigned long) /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/basic_string.h:403:51 #1 0x42870c in std::__cxx11::basic_string, std::allocator >::compare(char const*) const /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/basic_string.tcc:1429:8 #2 0x4273b7 in decltype(__detail::__char_traits_cmp_cat >(0)) std::operator<=>, std::allocator >(std::__cxx11::basic_string, std::allocator > const&, char const*) /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/basic_string.h:6216:61 #3 0x4271f5 in main *** #4 0x7f13e917dcc9 in __libc_start_main csu/../csu/libc-start.c:308:16 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/basic_string.h:403:51 in ``` See: https://github.com/google/sanitizers/issues/1346 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97844 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
