Add proper error handling for GPU packets #1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
clayborg
approved these changes
Jun 9, 2025
walter-erquinigo
merged commit 67da4ab
into
clayborg:llvm-server-plugins
2 checks passed
walter-erquinigo
added a commit
that referenced
this pull request
Sep 3, 2025
- Stop processing the events in a loop. For the same context we shouldn't get too many events together, so for this stage of the project, in which we just care about single kernels, we can keep it simple without a loop. This simplifies the code a bit. - Use a fake stop to notify the client that elf files have been loaded. This is done by ack'ing the event only after the autoresume has been received. Given that the ack'ing is delayed, no further events will appear for the given context for this stage of the project. ``` (lldb) target create "/home/werquinigo/samples/assert.out" Current executable set to '/home/werquinigo/samples/assert.out' (x86_64). (lldb) r Process 2769491 launched: '/home/werquinigo/samples/assert.out' (x86_64) Process 1 stopped * thread #1, name = 'NVIDIA GPU', stop reason = NVIDIA GPU is initializing frame #0: 0x00000000 ./assert.cu:29: void assert_one(unsigned int, unsigned int): block: [8,0,0], thread: [21,0,0] Assertion `fail_lane != threadIdx.x` failed. Target 0: (assert.out) stopped. Process 1 stopped * thread #1, name = 'GPU Thread (16, 0, 21)', stop reason = NVIDIA GPU Thread Stopped by Exception frame #0: 0x7fffd726a1a0 (lldb) image list [ 0] C2BEDE1D 0x00000000 cuda_elf_93825002571216.cubin [ 1] BDBBE6F7 0x00000000 cuda_elf_93825001386384.cubin [ 2] 3E12BE0F 0x00000000 cuda_elf_93825001420080.cubin [ 3] 27A05C6F 0x00000000 cuda_elf_93824999811952.cubin [ 4] C5345583 0x00000000 cuda_elf_93825002112032.cubin [ 5] A1E10B4B cuda_elf_93824998899888.cubin [ 6] 8B4B0CE3 cuda_elf_93824998857200.cubin [ 7] 2BC3D421 cuda_elf_93824998773248.cubin [ 8] A14C3EB2 cuda_elf_93824995686256.cubin [ 9] D6ED1226 0x00000000 cuda_elf_93824995476720.cubin [ 10] 2E5EC148 0x00000000 cuda_elf_93825001685984.cubin [ 11] 75A1B5A8 cuda_elf_93824995525440.cubin [ 12] 642E6780 cuda_elf_93824995424144.cubin [ 13] FF15F088 0x00000000 cuda_elf_93825002819712.cubin ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Bug Fixes** - Corrected the stop reason for GPU threads halted by the dynamic loader to display the appropriate status in the debugger. - **New Features** - Improved handling and notification of dynamic loader (dyld) events, including clearer reporting and simulated stop behavior for GPU processes. - **Enhancements** - Enhanced event logging and error reporting for GPU debugging events, providing better visibility during debugging sessions. - Refined GPU stop event handling and event filtering in tests for improved stability and traceability. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
walter-erquinigo
added a commit
that referenced
this pull request
Sep 3, 2025
This cleans up a bit the exception fetching code and prints the exception number in the bt. ``` * thread #1, name = 'GPU Thread (16, 0, 21)', stop reason = CUDA Exception 12 frame #0: 0x7fffd726a1a0 ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Improved handling and reporting of GPU thread exceptions, resulting in clearer and more descriptive exception messages. * Enhanced internal structure for capturing and conveying GPU exception information. * **Bug Fixes** * Updated test validation to expect the new, more specific exception message format for GPU thread stops. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
clayborg
pushed a commit
that referenced
this pull request
Sep 17, 2025
…), C)) (llvm#155141) Hi, I compared the following LLVM IR with GCC and Clang, and there is a small difference between the two. The LLVM IR is: ``` define i64 @test_smin_neg_one(i64 %a) { %1 = tail call i64 @llvm.smin.i64(i64 %a, i64 -1) %retval.0 = xor i64 %1, -1 ret i64 %retval.0 } ``` GCC generates: ``` cmp x0, 0 csinv x0, xzr, x0, ge ret ``` Clang generates: ``` cmn x0, #1 csinv x8, x0, xzr, lt mvn x0, x8 ret ``` Clang keeps flipping x0 through x8 unnecessarily. So I added the following folds to DAGCombiner: fold (xor (smax(x, C), C)) -> select (x > C), xor(x, C), 0 fold (xor (smin(x, C), C)) -> select (x < C), xor(x, C), 0 alive2: https://alive2.llvm.org/ce/z/gffoir --------- Co-authored-by: Yui5427 <785369607@qq.com> Co-authored-by: Matt Arsenault <arsenm2@gmail.com> Co-authored-by: Simon Pilgrim <llvm-dev@redking.me.uk>
clayborg
pushed a commit
that referenced
this pull request
Sep 26, 2025
A few improvements to logging when lldb-dap is started in **Server Mode** AND when the **`lldb-dap.logFolder`** setting is used (not `lldb-dap.log-path`). ### Improvement #1 **Avoid the prompt of restarting the server when starting each debug session.** That prompt is caused by the combination of the following facts: 1. The log filename changes every time a new debug session is starting (see [here](https://github.com/llvm/llvm-project/blob/9d6062c490548a5e6fea103e010ab3c9bc73a86d/lldb/tools/lldb-dap/src-ts/logging.ts#L47)) 2. The log filename is passed to the server via an environment variable called "LLDBDAP_LOG" (see [here](https://github.com/llvm/llvm-project/blob/9d6062c490548a5e6fea103e010ab3c9bc73a86d/lldb/tools/lldb-dap/src-ts/debug-adapter-factory.ts#L263-L269)) 3. All environment variables are put into the "spawn info" variable (see [here](https://github.com/llvm/llvm-project/blob/9d6062c490548a5e6fea103e010ab3c9bc73a86d/lldb/tools/lldb-dap/src-ts/lldb-dap-server.ts#L170-L172)). 4. The old and new "spawn info" are compared to decide if a prompt should show (see [here](https://github.com/llvm/llvm-project/blob/9d6062c490548a5e6fea103e010ab3c9bc73a86d/lldb/tools/lldb-dap/src-ts/lldb-dap-server.ts#L107-L110)). The fix is to remove the "LLDBDAP_LOG" from the "spawn info" variable, so that the same server can be reused if the log path is the only thing that has changed. ### Improvement #2 **Avoid log file conflict when multiple users share a machine and start server in the same second.** The problem: If two users start lldb-dap server in the same second, they will share the same log path. The first user will create the log file. The second user will find that they cannot access the same file, so their server will fail to start. The fix is to add a part of the VS Code session ID to the log filename. ### Improvement #3 **Avoid restarting the server when the order of environment variables changed.** This is done by sorting the environment variables before putting them into the "spawn info".
pveras
pushed a commit
to pveras/llvm-project
that referenced
this pull request
Sep 30, 2025
Specifically, `X & M ?= C --> (C << clz(M)) ?= (X << clz(M))` where M is a non-empty sequence of ones starting at the least significant bit with the remainder zero and C is a constant subset of M that cannot be materialised into a SUBS (immediate). Proof: https://alive2.llvm.org/ce/z/haqdJ4. This improves the comparison in isinf, for example: ```cpp int isinf(float x) { return __builtin_isinf(x); } ``` Before: ``` isinf: fmov w9, s0 mov w8, #2139095040 and w9, w9, #0x7fffffff cmp w9, w8 cset w0, eq ret ``` After: ``` isinf: fmov w9, s0 mov w8, #-16777216 cmp w8, w9, lsl clayborg#1 cset w0, eq ret ```
walter-erquinigo
added a commit
that referenced
this pull request
Sep 30, 2025
- Stop processing the events in a loop. For the same context we shouldn't get too many events together, so for this stage of the project, in which we just care about single kernels, we can keep it simple without a loop. This simplifies the code a bit. - Use a fake stop to notify the client that elf files have been loaded. This is done by ack'ing the event only after the autoresume has been received. Given that the ack'ing is delayed, no further events will appear for the given context for this stage of the project. ``` (lldb) target create "/home/werquinigo/samples/assert.out" Current executable set to '/home/werquinigo/samples/assert.out' (x86_64). (lldb) r Process 2769491 launched: '/home/werquinigo/samples/assert.out' (x86_64) Process 1 stopped * thread #1, name = 'NVIDIA GPU', stop reason = NVIDIA GPU is initializing frame #0: 0x00000000 ./assert.cu:29: void assert_one(unsigned int, unsigned int): block: [8,0,0], thread: [21,0,0] Assertion `fail_lane != threadIdx.x` failed. Target 0: (assert.out) stopped. Process 1 stopped * thread #1, name = 'GPU Thread (16, 0, 21)', stop reason = NVIDIA GPU Thread Stopped by Exception frame #0: 0x7fffd726a1a0 (lldb) image list [ 0] C2BEDE1D 0x00000000 cuda_elf_93825002571216.cubin [ 1] BDBBE6F7 0x00000000 cuda_elf_93825001386384.cubin [ 2] 3E12BE0F 0x00000000 cuda_elf_93825001420080.cubin [ 3] 27A05C6F 0x00000000 cuda_elf_93824999811952.cubin [ 4] C5345583 0x00000000 cuda_elf_93825002112032.cubin [ 5] A1E10B4B cuda_elf_93824998899888.cubin [ 6] 8B4B0CE3 cuda_elf_93824998857200.cubin [ 7] 2BC3D421 cuda_elf_93824998773248.cubin [ 8] A14C3EB2 cuda_elf_93824995686256.cubin [ 9] D6ED1226 0x00000000 cuda_elf_93824995476720.cubin [ 10] 2E5EC148 0x00000000 cuda_elf_93825001685984.cubin [ 11] 75A1B5A8 cuda_elf_93824995525440.cubin [ 12] 642E6780 cuda_elf_93824995424144.cubin [ 13] FF15F088 0x00000000 cuda_elf_93825002819712.cubin ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Bug Fixes** - Corrected the stop reason for GPU threads halted by the dynamic loader to display the appropriate status in the debugger. - **New Features** - Improved handling and notification of dynamic loader (dyld) events, including clearer reporting and simulated stop behavior for GPU processes. - **Enhancements** - Enhanced event logging and error reporting for GPU debugging events, providing better visibility during debugging sessions. - Refined GPU stop event handling and event filtering in tests for improved stability and traceability. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
walter-erquinigo
added a commit
that referenced
this pull request
Sep 30, 2025
This cleans up a bit the exception fetching code and prints the exception number in the bt. ``` * thread #1, name = 'GPU Thread (16, 0, 21)', stop reason = CUDA Exception 12 frame #0: 0x7fffd726a1a0 ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Improved handling and reporting of GPU thread exceptions, resulting in clearer and more descriptive exception messages. * Enhanced internal structure for capturing and conveying GPU exception information. * **Bug Fixes** * Updated test validation to expect the new, more specific exception message format for GPU thread stops. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
dmpots
pushed a commit
that referenced
this pull request
Oct 1, 2025
There is a bug that happens when you connect to the server where target list shows: ``` (lldb) target list Current targets: target #0: /data/users/peix/llvm/gpu/build/Debug/a.out ( arch=x86_64-unknown-linux-gnu, platform=host, pid=622763, state=stopped ) target #1: <none> ( arch=amdgcn-amd-amdhsa--gfx942, platform=host, pid=1, state=stopped ) * target #2: <none> ( platform=host, state=unloaded ) ``` The workflow: Process Launch -> initial stop (lldb always stops at launch) -> server gets notified -> server decide to send GPU actions in NativeProcessIsStopping() -> ready is returning true in ReadyToSendConnectionRequest -> Client is receiving the stop packet (our first process, GPU target created) -> m_last_stop_packet = response (contains GPUactions) -> LLDB calls RefreshStateAfterStop() (normal behavior) -> m_last_stop_packet is True so we reprocess the same packet -> SetThreadStopInfo(*m_last_stop_packet) -> Second Processing of Same GPU-Actions -> ParsePairs() extracts SAME: key="gpu-actions" -> HandleGPUActions called for the second time -> HandleConnectionRequest() -> Tries to create SECOND GPU target. The two calls originate from this code: https://github.com/clayborg/llvm-project/blob/llvm-server-plugins/lldb/source/Target/Process.cpp#L3276C1-L3291C6 The call on line 3267 to DoConnectRemote leads to a call to SetThreadStopInfo, which then calls HandleGPUActions. Then the call on line 3289 to HandlePrivateEvent again leads to a call to SetTheadStopInfo (via RefreshStateAfterStop), which then calls HandleGPUActions for the same set of actions. my fix is that the original stop packet (with GPU actions) is still cached in `m_last_stop_packet`, but we create a copy of the cached packet and strip the gpu-actions. --------- Co-authored-by: Bar Soloveychik <barsolo@fb.com>
walter-erquinigo
added a commit
that referenced
this pull request
Oct 9, 2025
- Stop processing the events in a loop. For the same context we shouldn't get too many events together, so for this stage of the project, in which we just care about single kernels, we can keep it simple without a loop. This simplifies the code a bit. - Use a fake stop to notify the client that elf files have been loaded. This is done by ack'ing the event only after the autoresume has been received. Given that the ack'ing is delayed, no further events will appear for the given context for this stage of the project. ``` (lldb) target create "/home/werquinigo/samples/assert.out" Current executable set to '/home/werquinigo/samples/assert.out' (x86_64). (lldb) r Process 2769491 launched: '/home/werquinigo/samples/assert.out' (x86_64) Process 1 stopped * thread #1, name = 'NVIDIA GPU', stop reason = NVIDIA GPU is initializing frame #0: 0x00000000 ./assert.cu:29: void assert_one(unsigned int, unsigned int): block: [8,0,0], thread: [21,0,0] Assertion `fail_lane != threadIdx.x` failed. Target 0: (assert.out) stopped. Process 1 stopped * thread #1, name = 'GPU Thread (16, 0, 21)', stop reason = NVIDIA GPU Thread Stopped by Exception frame #0: 0x7fffd726a1a0 (lldb) image list [ 0] C2BEDE1D 0x00000000 cuda_elf_93825002571216.cubin [ 1] BDBBE6F7 0x00000000 cuda_elf_93825001386384.cubin [ 2] 3E12BE0F 0x00000000 cuda_elf_93825001420080.cubin [ 3] 27A05C6F 0x00000000 cuda_elf_93824999811952.cubin [ 4] C5345583 0x00000000 cuda_elf_93825002112032.cubin [ 5] A1E10B4B cuda_elf_93824998899888.cubin [ 6] 8B4B0CE3 cuda_elf_93824998857200.cubin [ 7] 2BC3D421 cuda_elf_93824998773248.cubin [ 8] A14C3EB2 cuda_elf_93824995686256.cubin [ 9] D6ED1226 0x00000000 cuda_elf_93824995476720.cubin [ 10] 2E5EC148 0x00000000 cuda_elf_93825001685984.cubin [ 11] 75A1B5A8 cuda_elf_93824995525440.cubin [ 12] 642E6780 cuda_elf_93824995424144.cubin [ 13] FF15F088 0x00000000 cuda_elf_93825002819712.cubin ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Bug Fixes** - Corrected the stop reason for GPU threads halted by the dynamic loader to display the appropriate status in the debugger. - **New Features** - Improved handling and notification of dynamic loader (dyld) events, including clearer reporting and simulated stop behavior for GPU processes. - **Enhancements** - Enhanced event logging and error reporting for GPU debugging events, providing better visibility during debugging sessions. - Refined GPU stop event handling and event filtering in tests for improved stability and traceability. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
walter-erquinigo
added a commit
that referenced
this pull request
Oct 9, 2025
This cleans up a bit the exception fetching code and prints the exception number in the bt. ``` * thread #1, name = 'GPU Thread (16, 0, 21)', stop reason = CUDA Exception 12 frame #0: 0x7fffd726a1a0 ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Improved handling and reporting of GPU thread exceptions, resulting in clearer and more descriptive exception messages. * Enhanced internal structure for capturing and conveying GPU exception information. * **Bug Fixes** * Updated test validation to expect the new, more specific exception message format for GPU thread stops. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
pveras
pushed a commit
to pveras/llvm-project
that referenced
this pull request
Oct 10, 2025
A recent change adding a new sanitizer kind (via Sanitizers.def) was reverted in c74fa20 ("Revert "[Clang][CodeGen] Introduce the AllocToken SanitizerKind" (llvm#162413)"). The reason was this ASan report, when running the test cases in clang/test/Preprocessor/print-header-json.c: ``` ==clang==483265==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7d82b97e8b58 at pc 0x562cd432231f bp 0x7fff3fad0850 sp 0x7fff3fad0848 READ of size 16 at 0x7d82b97e8b58 thread T0 #0 0x562cd432231e in __copy_non_overlapping_range<const unsigned long *, const unsigned long *> zorg-test/libcxx_install_asan_ubsan/include/c++/v1/string:2144:38 clayborg#1 0x562cd432231e in void std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::__init_with_size[abi:nn220000]<unsigned long const*, unsigned long const*>(unsigned long const*, unsigned long const*, unsigned long) zorg-test/libcxx_install_asan_ubsan/include/c++/v1/string:2685:18 clayborg#2 0x562cd41e2797 in __init<const unsigned long *, 0> zorg-test/libcxx_install_asan_ubsan/include/c++/v1/string:2673:3 clayborg#3 0x562cd41e2797 in basic_string<const unsigned long *, 0> zorg-test/libcxx_install_asan_ubsan/include/c++/v1/string:1174:5 clayborg#4 0x562cd41e2797 in clang::ASTReader::ReadString(llvm::SmallVectorImpl<unsigned long> const&, unsigned int&) clang/lib/Serialization/ASTReader.cpp:10171:15 clayborg#5 0x562cd41fd89a in clang::ASTReader::ParseLanguageOptions(llvm::SmallVector<unsigned long, 64u> const&, llvm::StringRef, bool, clang::ASTReaderListener&, bool) clang/lib/Serialization/ASTReader.cpp:6475:28 clayborg#6 0x562cd41eea53 in clang::ASTReader::ReadOptionsBlock(llvm::BitstreamCursor&, llvm::StringRef, unsigned int, bool, clang::ASTReaderListener&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&) clang/lib/Serialization/ASTReader.cpp:3069:11 clayborg#7 0x562cd4204ab8 in clang::ASTReader::ReadControlBlock(clang::serialization::ModuleFile&, llvm::SmallVectorImpl<clang::ASTReader::ImportedModule>&, clang::serialization::ModuleFile const*, unsigned int) clang/lib/Serialization/ASTReader.cpp:3249:15 clayborg#8 0x562cd42097d2 in clang::ASTReader::ReadASTCore(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, clang::serialization::ModuleFile*, llvm::SmallVectorImpl<clang::ASTReader::ImportedModule>&, long, long, clang::ASTFileSignature, unsigned int) clang/lib/Serialization/ASTReader.cpp:5182:15 clayborg#9 0x562cd421ec77 in clang::ASTReader::ReadAST(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, unsigned int, clang::serialization::ModuleFile**) clang/lib/Serialization/ASTReader.cpp:4828:11 clayborg#10 0x562cd3d07b74 in clang::CompilerInstance::findOrCompileModuleAndReadAST(llvm::StringRef, clang::SourceLocation, clang::SourceLocation, bool) clang/lib/Frontend/CompilerInstance.cpp:1805:27 clayborg#11 0x562cd3d0b2ef in clang::CompilerInstance::loadModule(clang::SourceLocation, llvm::ArrayRef<clang::IdentifierLoc>, clang::Module::NameVisibilityKind, bool) clang/lib/Frontend/CompilerInstance.cpp:1956:31 clayborg#12 0x562cdb04eb1c in clang::Preprocessor::HandleHeaderIncludeOrImport(clang::SourceLocation, clang::Token&, clang::Token&, clang::SourceLocation, clang::detail::SearchDirIteratorImpl<true>, clang::FileEntry const*) clang/lib/Lex/PPDirectives.cpp:2423:49 clayborg#13 0x562cdb042222 in clang::Preprocessor::HandleIncludeDirective(clang::SourceLocation, clang::Token&, clang::detail::SearchDirIteratorImpl<true>, clang::FileEntry const*) clang/lib/Lex/PPDirectives.cpp:2101:17 clayborg#14 0x562cdb043366 in clang::Preprocessor::HandleDirective(clang::Token&) clang/lib/Lex/PPDirectives.cpp:1338:14 clayborg#15 0x562cdafa84bc in clang::Lexer::LexTokenInternal(clang::Token&, bool) clang/lib/Lex/Lexer.cpp:4512:7 clayborg#16 0x562cdaf9f20b in clang::Lexer::Lex(clang::Token&) clang/lib/Lex/Lexer.cpp:3729:24 clayborg#17 0x562cdb0d4ffa in clang::Preprocessor::Lex(clang::Token&) clang/lib/Lex/Preprocessor.cpp:896:11 clayborg#18 0x562cd77da950 in clang::ParseAST(clang::Sema&, bool, bool) clang/lib/Parse/ParseAST.cpp:163:7 [...] 0x7d82b97e8b58 is located 0 bytes after 3288-byte region [0x7d82b97e7e80,0x7d82b97e8b58) allocated by thread T0 here: #0 0x562cca76f604 in malloc zorg-test/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:67:3 clayborg#1 0x562cd1cce452 in safe_malloc llvm/include/llvm/Support/MemAlloc.h:26:18 clayborg#2 0x562cd1cce452 in llvm::SmallVectorBase<unsigned int>::grow_pod(void*, unsigned long, unsigned long) llvm/lib/Support/SmallVector.cpp:151:15 clayborg#3 0x562cdbe1768b in grow_pod llvm/include/llvm/ADT/SmallVector.h:139:11 clayborg#4 0x562cdbe1768b in grow llvm/include/llvm/ADT/SmallVector.h:525:41 clayborg#5 0x562cdbe1768b in reserve llvm/include/llvm/ADT/SmallVector.h:665:13 clayborg#6 0x562cdbe1768b in llvm::BitstreamCursor::readRecord(unsigned int, llvm::SmallVectorImpl<unsigned long>&, llvm::StringRef*) llvm/lib/Bitstream/Reader/BitstreamReader.cpp:230:10 clayborg#7 0x562cd41ee8ab in clang::ASTReader::ReadOptionsBlock(llvm::BitstreamCursor&, llvm::StringRef, unsigned int, bool, clang::ASTReaderListener&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&) clang/lib/Serialization/ASTReader.cpp:3060:49 clayborg#8 0x562cd4204ab8 in clang::ASTReader::ReadControlBlock(clang::serialization::ModuleFile&, llvm::SmallVectorImpl<clang::ASTReader::ImportedModule>&, clang::serialization::ModuleFile const*, unsigned int) clang/lib/Serialization/ASTReader.cpp:3249:15 clayborg#9 0x562cd42097d2 in clang::ASTReader::ReadASTCore(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, clang::serialization::ModuleFile*, llvm::SmallVectorImpl<clang::ASTReader::ImportedModule>&, long, long, clang::ASTFileSignature, unsigned int) clang/lib/Serialization/ASTReader.cpp:5182:15 clayborg#10 0x562cd421ec77 in clang::ASTReader::ReadAST(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, unsigned int, clang::serialization::ModuleFile**) clang/lib/Serialization/ASTReader.cpp:4828:11 clayborg#11 0x562cd3d07b74 in clang::CompilerInstance::findOrCompileModuleAndReadAST(llvm::StringRef, clang::SourceLocation, clang::SourceLocation, bool) clang/lib/Frontend/CompilerInstance.cpp:1805:27 clayborg#12 0x562cd3d0b2ef in clang::CompilerInstance::loadModule(clang::SourceLocation, llvm::ArrayRef<clang::IdentifierLoc>, clang::Module::NameVisibilityKind, bool) clang/lib/Frontend/CompilerInstance.cpp:1956:31 clayborg#13 0x562cdb04eb1c in clang::Preprocessor::HandleHeaderIncludeOrImport(clang::SourceLocation, clang::Token&, clang::Token&, clang::SourceLocation, clang::detail::SearchDirIteratorImpl<true>, clang::FileEntry const*) clang/lib/Lex/PPDirectives.cpp:2423:49 clayborg#14 0x562cdb042222 in clang::Preprocessor::HandleIncludeDirective(clang::SourceLocation, clang::Token&, clang::detail::SearchDirIteratorImpl<true>, clang::FileEntry const*) clang/lib/Lex/PPDirectives.cpp:2101:17 clayborg#15 0x562cdb043366 in clang::Preprocessor::HandleDirective(clang::Token&) clang/lib/Lex/PPDirectives.cpp:1338:14 clayborg#16 0x562cdafa84bc in clang::Lexer::LexTokenInternal(clang::Token&, bool) clang/lib/Lex/Lexer.cpp:4512:7 clayborg#17 0x562cdaf9f20b in clang::Lexer::Lex(clang::Token&) clang/lib/Lex/Lexer.cpp:3729:24 clayborg#18 0x562cdb0d4ffa in clang::Preprocessor::Lex(clang::Token&) clang/lib/Lex/Preprocessor.cpp:896:11 clayborg#19 0x562cd77da950 in clang::ParseAST(clang::Sema&, bool, bool) clang/lib/Parse/ParseAST.cpp:163:7 [...] SUMMARY: AddressSanitizer: heap-buffer-overflow clang/lib/Serialization/ASTReader.cpp:10171:15 in clang::ASTReader::ReadString(llvm::SmallVectorImpl<unsigned long> const&, unsigned int&) ``` The reason is this particular RUN line: ``` // RUN: env CC_PRINT_HEADERS_FORMAT=json CC_PRINT_HEADERS_FILTERING=direct-per-file CC_PRINT_HEADERS_FILE=%t.txt %clang -fsyntax-only -I %S/Inputs/print-header-json -isystem %S/Inputs/print-header-json/system -fmodules -fimplicit-module-maps -fmodules-cache-path=%t %s -o /dev/null ``` which was added in 8df194f ("[Clang] Support includes translated to module imports in -header-include-filtering=direct-per-file (llvm#156756)"). The problem is caused by an incremental build reusing stale cached module files (.pcm) that are no longer binary-compatible with the updated compiler. Adding a new sanitizer option altered the implicit binary layout of the serialized LangOptions data structure. The build + test system is oblivious to such changes. When the new compiler attempted to read the old module file (from the previous test invocation), it misinterpreted the data due to the layout mismatch, resulting in a heap-buffer-overflow. Unfortunately Clang's PCM format does not encode nor detect version mismatches here; a more graceful failure mode would be preferable. For now, fix the test to be more robust with incremental build + test.
clayborg
pushed a commit
that referenced
this pull request
Oct 13, 2025
Otherwise debug-info is stripped, which influences the language of the
current frame.
Also, set explicit breakpoint because Windows seems to not obey the
debugtrap.
Log from failing test on Windows:
```
(lldb) command source -s 0 'lit-lldb-init-quiet'
Executing commands in 'D:\test\lit-lldb-init-quiet'.
(lldb) command source -C --silent-run true lit-lldb-init
(lldb) target create "main.out"
Current executable set to 'D:\test\main.out' (x86_64).
(lldb) settings set interpreter.stop-command-source-on-error false
(lldb) command source -s 0 'with-target.input'
Executing commands in 'D:\test\with-target.input'.
(lldb) expr blah
^
error: use of undeclared identifier 'blah'
note: Falling back to default language. Ran expression as 'Objective C++'.
(lldb) run
Process 29404 launched: 'D:\test\main.out' (x86_64)
Process 29404 stopped
* thread #1, stop reason = Exception 0x80000003 encountered at address 0x7ff7b3df7189
frame #0: 0x00007ff7b3df718a main.out
-> 0x7ff7b3df718a: xorl %eax, %eax
0x7ff7b3df718c: popq %rcx
0x7ff7b3df718d: retq
0x7ff7b3df718e: int3
(lldb) expr blah
^
error: use of undeclared identifier 'blah'
note: Falling back to default language. Ran expression as 'Objective C++'.
(lldb) expr -l objc -- blah
^
error: use of undeclared identifier 'blah'
note: Expression evaluation in pure Objective-C not supported. Ran expression as 'Objective C++'.
(lldb) expr -l c -- blah
^
error: use of undeclared identifier 'blah'
note: Expression evaluation in pure C not supported. Ran expression as 'ISO C++'.
```
clayborg
pushed a commit
that referenced
this pull request
Oct 13, 2025
The Tkinter module was renamed to tkinter in Python 3.0. https://docs.python.org/2/library/tkinter.html https://docs.python.org/3/library/tkinter.html Rest of it appears to work when imported inside of LLDB: ``` $ ./bin/lldb /tmp/test.o (lldb) target create "/tmp/test.o" Current executable set to '/tmp/test.o' (x86_64). (lldb) b main Breakpoint 1: where = test.o`main + 8 at test.c:1:18, address = 0x0000000000001131 (lldb) run Process 121572 launched: '/tmp/test.o' (x86_64) Process 121572 stopped * thread #1, name = 'test.o', stop reason = breakpoint 1.1 frame #0: 0x0000555555555131 test.o`main at test.c:1:18 -> 1 int main() { int a = 1; char b = '?'; return 0; } (lldb) command script import <...>/llvm-project/lldb/examples/python/lldbtk.py (lldb) tk- Available completions: tk-process -- For more information run 'help tk-process' tk-target -- For more information run 'help tk-target' tk-variables -- For more information run 'help tk-variables' (lldb) tk-process (lldb) tk-target (lldb) tk-variables ```
clayborg
pushed a commit
that referenced
this pull request
Oct 13, 2025
…ypes (llvm#162278) When we take the following C program: ``` int main() { return 0; } ``` and create a statically-linked executable from it: ``` clang -static -g -o main main.c ``` Then we can observe the following `lldb` behavior: ``` $ lldb (lldb) target create main Current executable set to '.../main' (x86_64). (lldb) breakpoint set --name main Breakpoint 1: where = main`main + 11 at main.c:2:3, address = 0x000000000022aa7b (lldb) process launch Process 3773637 launched: '/home/me/tmp/built-in/main' (x86_64) Process 3773637 stopped * thread #1, name = 'main', stop reason = breakpoint 1.1 frame #0: 0x000000000022aa7b main`main at main.c:2:3 1 int main() { -> 2 return 0; 3 } (lldb) script lldb.debugger.GetSelectedTarget().FindFirstType("__int128").size 0 (lldb) script lldb.debugger.GetSelectedTarget().FindFirstType("unsigned __int128").size 0 (lldb) quit ``` The value return by the `SBTarget::FindFirstType` method is wrong for the `__int128` and `unsigned __int128` basic types. The proposed changes make the `TypeSystemClang::GetBasicTypeEnumeration` method consistent with `gcc` and `clang` C [language extension](https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html) related to 128-bit integer types as well as with the `BuiltinType::getName` method in the LLVM codebase itself. When the above change is applied, the behavior of the `lldb` changes in the following (desired) way: ``` $ lldb (lldb) target create main Current executable set to '.../main' (x86_64). (lldb) breakpoint set --name main Breakpoint 1: where = main`main + 11 at main.c:2:3, address = 0x000000000022aa7b (lldb) process launch Process 3773637 launched: '/home/me/tmp/built-in/main' (x86_64) Process 3773637 stopped * thread #1, name = 'main', stop reason = breakpoint 1.1 frame #0: 0x000000000022aa7b main`main at main.c:2:3 1 int main() { -> 2 return 0; 3 } (lldb) script lldb.debugger.GetSelectedTarget().FindFirstType("__int128").size 16 (lldb) script lldb.debugger.GetSelectedTarget().FindFirstType("unsigned __int128").size 16 (lldb) quit ``` --------- Co-authored-by: Matej Košík <matej.kosik@codasip.com>
dmpots
pushed a commit
that referenced
this pull request
Oct 14, 2025
## Summary Right now when the native process exists, we get a lost connection for the GPU target: ``` (lldb) target select 0 Current targets: * target #0: /home/qxy11/llvm/Debug/a.out ( arch=x86_64-unknown-linux-gnu, platform=host, pid=242142, state=stopped ) target #1: <none> ( arch=x86_64-unknown-linux-gnu, platform=host, pid=1234, state=running ) (lldb) c Process 3805000 resuming Process 3805000 exited with status = 0 (0x00000000) Process 1234 exited with status = -1 (0xffffffff) lost connection (lldb) q ``` The desired behavior should be that the GPU connection returns an exit status when the native process exits, returning a `$WXX` packet. This change fixes this so that when the native process is exiting, it notifies the GPU plugin to exit as well. This currently is done in the Mock GPU plugin, and sets the exit status for the GPU process to the same one as the native process, but we can extend and follow up on AMD once this is approved. ## Tests We can follow up with unit tests once the basic unit tests are landed from other PRs. Basic test running until native process reached completion: ``` (lldb) c Process 1234 resuming (lldb) target select 0 Current targets: * target #0: /home/qxy11/llvm/Debug/a.out ( arch=x86_64-unknown-linux-gnu, platform=host, pid=3805000, state=stopped ) target #1: <none> ( arch=x86_64-unknown-linux-gnu, platform=host, pid=1234, state=running ) (lldb) c Process 3805000 resuming gpu_shlib_load gpu_third_stop gpu_shlib_load gpu_kernel Process 3805000 exited with status = 0 (0x00000000) Process 1234 exited with status = 0 (0x00000000) (lldb) ``` Check server logs: ``` 1756162713.459808350 [3383979/3383979] gdb-server < 22> read packet: $vCont;c:p33a2ae.-1#9d 1756162713.459902287 [3383979/3383979] gdb-server < 61> send packet: $O6770755f73686c69625f6c6f61640d0a6770755f6b65726e656c0d0a#43 1756162713.460208416 [3383979/3383979] ProcessMockGPU::HandleNativeProcessExit() native process exited with status=(Exited with status 0) 1756162713.460271358 [3383979/3383979] mock-gpu.server < 7> send packet: $W00#b7 1756162713.460320950 [3383979/3383979] gdb-server < 22> send packet: $W00;process:33a2ae#ea lldb-server exiting... ``` As expected, the both processes send back `$W00` packets now. The `mock-gpu.server` packet doesn't include the process ID since it doesn't have multi-process support enabled. Test killing the process: ``` (lldb) target select 0 Current targets: * target #0: /home/qxy11/llvm/Debug/a.out ( arch=x86_64-unknown-linux-gnu, platform=host, pid=3879593, state=stopped ) target #1: <none> ( arch=x86_64-unknown-linux-gnu, platform=host, pid=1234, state=running ) (lldb) process kill Process 1234 exited with status = 9 (0x00000009) Process 3879593 exited with status = 9 (0x00000009) killed (lldb) ``` Test native process segfaults and exits: ``` (lldb) intern-state pid = 2581667, SyncState::SetStateStopped(stop_id=4) m_stop_id = 4, m_state = stopped intern-state pid = 2581667, SyncState::DidResume() m_stop_id = 4, m_state = running intern-state pid = 2581667, SyncState::SetStateStopped(stop_id=5) m_stop_id = 5, m_state = stopped Process 2581667 stopped * thread #1, name = 'a.out', stop reason = signal SIGSEGV: address not mapped to object (fault address=0x0) frame #0: 0x00005555555551e7 a.out`main(argc=1, argv=0x00007fffffffd6a8) at memory-space-main.c:24:6 21 gpu_initialize(); 22 // CPU BREAKPOINT - BEFORE LAUNCH 23 int *p = NULL; -> 24 *p = 42; 25 gpu_shlib_load(); 26 gpu_third_stop(); 27 gpu_shlib_load(); Likely cause: p accessed 0x0 (lldb) c lldb pid = 2581667, SyncState::DidResume() m_stop_id = 5, m_state = running Process 2581667 resuming Process 2581667 exited with status = 11 (0x0000000b) Process 1234 exited with status = 11 (0x0000000b) (lldb) ```
walter-erquinigo
added a commit
that referenced
this pull request
Oct 24, 2025
- Stop processing the events in a loop. For the same context we shouldn't get too many events together, so for this stage of the project, in which we just care about single kernels, we can keep it simple without a loop. This simplifies the code a bit. - Use a fake stop to notify the client that elf files have been loaded. This is done by ack'ing the event only after the autoresume has been received. Given that the ack'ing is delayed, no further events will appear for the given context for this stage of the project. ``` (lldb) target create "/home/werquinigo/samples/assert.out" Current executable set to '/home/werquinigo/samples/assert.out' (x86_64). (lldb) r Process 2769491 launched: '/home/werquinigo/samples/assert.out' (x86_64) Process 1 stopped * thread #1, name = 'NVIDIA GPU', stop reason = NVIDIA GPU is initializing frame #0: 0x00000000 ./assert.cu:29: void assert_one(unsigned int, unsigned int): block: [8,0,0], thread: [21,0,0] Assertion `fail_lane != threadIdx.x` failed. Target 0: (assert.out) stopped. Process 1 stopped * thread #1, name = 'GPU Thread (16, 0, 21)', stop reason = NVIDIA GPU Thread Stopped by Exception frame #0: 0x7fffd726a1a0 (lldb) image list [ 0] C2BEDE1D 0x00000000 cuda_elf_93825002571216.cubin [ 1] BDBBE6F7 0x00000000 cuda_elf_93825001386384.cubin [ 2] 3E12BE0F 0x00000000 cuda_elf_93825001420080.cubin [ 3] 27A05C6F 0x00000000 cuda_elf_93824999811952.cubin [ 4] C5345583 0x00000000 cuda_elf_93825002112032.cubin [ 5] A1E10B4B cuda_elf_93824998899888.cubin [ 6] 8B4B0CE3 cuda_elf_93824998857200.cubin [ 7] 2BC3D421 cuda_elf_93824998773248.cubin [ 8] A14C3EB2 cuda_elf_93824995686256.cubin [ 9] D6ED1226 0x00000000 cuda_elf_93824995476720.cubin [ 10] 2E5EC148 0x00000000 cuda_elf_93825001685984.cubin [ 11] 75A1B5A8 cuda_elf_93824995525440.cubin [ 12] 642E6780 cuda_elf_93824995424144.cubin [ 13] FF15F088 0x00000000 cuda_elf_93825002819712.cubin ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Bug Fixes** - Corrected the stop reason for GPU threads halted by the dynamic loader to display the appropriate status in the debugger. - **New Features** - Improved handling and notification of dynamic loader (dyld) events, including clearer reporting and simulated stop behavior for GPU processes. - **Enhancements** - Enhanced event logging and error reporting for GPU debugging events, providing better visibility during debugging sessions. - Refined GPU stop event handling and event filtering in tests for improved stability and traceability. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
walter-erquinigo
added a commit
that referenced
this pull request
Oct 24, 2025
This cleans up a bit the exception fetching code and prints the exception number in the bt. ``` * thread #1, name = 'GPU Thread (16, 0, 21)', stop reason = CUDA Exception 12 frame #0: 0x7fffd726a1a0 ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Improved handling and reporting of GPU thread exceptions, resulting in clearer and more descriptive exception messages. * Enhanced internal structure for capturing and conveying GPU exception information. * **Bug Fixes** * Updated test validation to expect the new, more specific exception message format for GPU thread stops. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
clayborg
pushed a commit
that referenced
this pull request
Oct 24, 2025
**Mitigation for:** google/sanitizers#749 **Disclosure:** I'm not an ASan compiler expert yet (I'm trying to learn!), I primarily work in the runtime. Some of this PR was developed with the help of AI tools (primarily as a "fuzzy `grep` engine"), but I've manually refined and tested the output, and can speak for every line. In general, I used it only to orient myself and for "rubberducking". **Context:** The msvc ASan team (👋 ) has received an internal request to improve clang's exception handling under ASan for Windows. Namely, we're interested in **mitigating** this bug: google/sanitizers#749 To summarize, today, clang + ASan produces a false-positive error for this program: ```C++ #include <cstdio> #include <exception> int main() { try { throw std::exception("test"); }catch (const std::exception& ex){ puts(ex.what()); } return 0; } ``` The error reads as such: ``` C:\Users\dajusto\source\repros\upstream>type main.cpp #include <cstdio> #include <exception> int main() { try { throw std::exception("test"); }catch (const std::exception& ex){ puts(ex.what()); } return 0; } C:\Users\dajusto\source\repros\upstream>"C:\Users\dajusto\source\repos\llvm-project\build.runtimes\bin\clang.exe" -fsanitize=address -g -O0 main.cpp C:\Users\dajusto\source\repros\upstream>a.exe ================================================================= ==19112==ERROR: AddressSanitizer: access-violation on unknown address 0x000000000000 (pc 0x7ff72c7c11d9 bp 0x0080000ff960 sp 0x0080000fcf50 T0) ==19112==The signal is caused by a READ memory access. ==19112==Hint: address points to the zero page. #0 0x7ff72c7c11d8 in main C:\Users\dajusto\source\repros\upstream\main.cpp:8 #1 0x7ff72c7d479f in _CallSettingFrame C:\repos\msvc\src\vctools\crt\vcruntime\src\eh\amd64\handlers.asm:49 #2 0x7ff72c7c8944 in __FrameHandler3::CxxCallCatchBlock(struct _EXCEPTION_RECORD *) C:\repos\msvc\src\vctools\crt\vcruntime\src\eh\frame.cpp:1567 #3 0x7ffb4a90e3e5 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x18012e3e5) #4 0x7ff72c7c1128 in main C:\Users\dajusto\source\repros\upstream\main.cpp:6 #5 0x7ff72c7c33db in invoke_main C:\repos\msvc\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78 #6 0x7ff72c7c33db in __scrt_common_main_seh C:\repos\msvc\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288 #7 0x7ffb49b05c06 (C:\WINDOWS\System32\KERNEL32.DLL+0x180035c06) #8 0x7ffb4a8455ef (C:\WINDOWS\SYSTEM32\ntdll.dll+0x1800655ef) ==19112==Register values: rax = 0 rbx = 80000ff8e0 rcx = 27d76d00000 rdx = 80000ff8e0 rdi = 80000fdd50 rsi = 80000ff6a0 rbp = 80000ff960 rsp = 80000fcf50 r8 = 100 r9 = 19930520 r10 = 8000503a90 r11 = 80000fd540 r12 = 80000fd020 r13 = 0 r14 = 80000fdeb8 r15 = 0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: access-violation C:\Users\dajusto\source\repros\upstream\main.cpp:8 in main ==19112==ABORTING ``` The root of the issue _appears to be_ that ASan's instrumentation is incompatible with Window's assumptions for instantiating `catch`-block's parameters (`ex` in the snippet above). The nitty gritty details are lost on me, but I understand that to make this work without loss of ASan coverage, a "serious" refactoring is needed. In the meantime, users risk false positive errors when pairing ASan + catch-block parameters on Windows. **To mitigate this** I think we should avoid instrumenting catch-block parameters on Windows. It appears to me this is as "simple" as marking catch block parameters as "uninteresting" in `AddressSanitizer::isInterestingAlloca`. My manual tests seem to confirm this. I believe this is strictly better than today's status quo, where the runtime generates false positives. Although we're now explicitly choosing to instrument less, the benefit is that now more programs can run with ASan without _funky_ macros that disable ASan on exception blocks. **This PR:** implements the mitigation above, and creates a simple new test for it. _Thanks!_ --------- Co-authored-by: Antonio Frighetto <me@antoniofrighetto.com>
clayborg
pushed a commit
that referenced
this pull request
Oct 24, 2025
…nteger registers (llvm#163646) Fix the `RegisterValue::SetValueFromData` method so that it works also for 128-bit registers that contain integers. Without this change, the `RegisterValue::SetValueFromData` method does not work correctly for 128-bit registers that contain (signed or unsigned) integers. --- Steps to reproduce the problem: (1) Create a program that writes a 128-bit number to a 128-bit registers `xmm0`. E.g.: ``` #include <stdint.h> int main() { __asm__ volatile ( "pinsrq $0, %[lo], %%xmm0\n\t" // insert low 64 bits "pinsrq $1, %[hi], %%xmm0" // insert high 64 bits : : [lo]"r"(0x7766554433221100), [hi]"r"(0xffeeddccbbaa9988) ); return 0; } ``` (2) Compile this program with LLVM compiler: ``` $ $YOUR/clang -g -o main main.c ``` (3) Modify LLDB so that when it will be reading value from the `xmm0` register, instead of assuming that it is vector register, it will treat it as if it contain an integer. This can be achieved e.g. this way: ``` diff --git a/lldb/source/Utility/RegisterValue.cpp b/lldb/source/Utility/RegisterValue.cpp index 0e99451..a4b51db3e56d 100644 --- a/lldb/source/Utility/RegisterValue.cpp +++ b/lldb/source/Utility/RegisterValue.cpp @@ -188,6 +188,7 @@ Status RegisterValue::SetValueFromData(const RegisterInfo ®_info, break; case eEncodingUint: case eEncodingSint: + case eEncodingVector: if (reg_info.byte_size == 1) SetUInt8(src.GetMaxU32(&src_offset, src_len)); else if (reg_info.byte_size <= 2) @@ -217,23 +218,6 @@ Status RegisterValue::SetValueFromData(const RegisterInfo ®_info, else if (reg_info.byte_size == sizeof(long double)) SetLongDouble(src.GetLongDouble(&src_offset)); break; - case eEncodingVector: { - m_type = eTypeBytes; - assert(reg_info.byte_size <= kMaxRegisterByteSize); - buffer.bytes.resize(reg_info.byte_size); - buffer.byte_order = src.GetByteOrder(); - if (src.CopyByteOrderedData( - src_offset, // offset within "src" to start extracting data - src_len, // src length - buffer.bytes.data(), // dst buffer - buffer.bytes.size(), // dst length - buffer.byte_order) == 0) // dst byte order - { - error = Status::FromErrorStringWithFormat( - "failed to copy data for register write of %s", reg_info.name); - return error; - } - } } if (m_type == eTypeInvalid) ``` (4) Rebuild the LLDB. (5) Observe what happens how LLDB will print the content of this register after it was initialized with 128-bit value. ``` $YOUR/lldb --source ./main (lldb) target create main Current executable set to '.../main' (x86_64). (lldb) breakpoint set --file main.c --line 11 Breakpoint 1: where = main`main + 45 at main.c:11:3, address = 0x000000000000164d (lldb) settings set stop-line-count-before 20 (lldb) process launch Process 2568735 launched: '.../main' (x86_64) Process 2568735 stopped * thread #1, name = 'main', stop reason = breakpoint 1.1 frame #0: 0x000055555555564d main`main at main.c:11:3 1 #include <stdint.h> 2 3 int main() { 4 __asm__ volatile ( 5 "pinsrq $0, %[lo], %%xmm0\n\t" // insert low 64 bits 6 "pinsrq $1, %[hi], %%xmm0" // insert high 64 bits 7 : 8 : [lo]"r"(0x7766554433221100), 9 [hi]"r"(0xffeeddccbbaa9988) 10 ); -> 11 return 0; 12 } (lldb) register read --format hex xmm0 xmm0 = 0x7766554433221100ffeeddccbbaa9988 ``` You can see that the upper and lower 64-bit wide halves are swapped. --------- Co-authored-by: Matej Košík <matej.kosik@codasip.com>
clayborg
pushed a commit
that referenced
this pull request
Oct 24, 2025
…lvm#162993) Early if conversion can create instruction sequences such as ``` mov x1, #1 csel x0, x1, x2, eq ``` which could be simplified into the following instead ``` csinc x0, x2, xzr, ne ``` One notable example that generates code like this is `cmpxchg weak`. This is fixed by handling an immediate value of 1 as `add(wzr, 1)` so that the addition can be folded into CSEL by using CSINC instead.
clayborg
pushed a commit
that referenced
this pull request
Oct 31, 2025
In `Driver.cpp` `std::atomic<uint64_t>` is used which may need
libatomic.
Build failure (if that is of interest):
```
[127/135] Linking CXX shared library lib/liblldMachO.so.20.1
ninja: job failed: : && /usr/lib/ccache/bin/clang++-20 -fPIC -Os -fstack-clash-protection -Wformat -Werror=format-security -D_GLIBCXX_ASSERTIONS=1 -D_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS=1 -D_LIBCPP_ENABLE_HARDENED_MODE=1 -g -O2 -DNDEBUG -g1 -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -Wl,--as-needed,-O1,--sort-common -Wl,-z,defs -Wl,-z,nodelete -Wl,-rpath-link,/home/user/aports/main/lld20/src/lld-20.1.5.src/build/./lib -Wl,--gc-sections -shared -Wl,-soname,liblldMachO.so.20.1 -o lib/liblldMachO.so.20.1 MachO/CMakeFiles/lldMachO.dir/Arch/ARM64.cpp.o MachO/CMakeFiles/lldMachO.dir/Arch/ARM64Common.cpp.o MachO/CMakeFiles/lldMachO.dir/Arch/ARM64_32.cpp.o MachO/CMakeFiles/lldMachO.dir/Arch/X86_64.cpp.o MachO/CMakeFiles/lldMachO.dir/ConcatOutputSection.cpp.o MachO/CMakeFiles/lldMachO.dir/Driver.cpp.o MachO/CMakeFiles/lldMachO.dir/DriverUtils.cpp.o MachO/CMakeFiles/lldMachO.dir/Dwarf.cpp.o MachO/CMakeFiles/lldMachO.dir/EhFrame.cpp.o MachO/CMakeFiles/lldMachO.dir/ExportTrie.cpp.o MachO/CMakeFiles/lldMachO.dir/ICF.cpp.o MachO/CMakeFiles/lldMachO.dir/InputFiles.cpp.o MachO/CMakeFiles/lldMachO.dir/InputSection.cpp.o MachO/CMakeFiles/lldMachO.dir/LTO.cpp.o MachO/CMakeFiles/lldMachO.dir/MapFile.cpp.o MachO/CMakeFiles/lldMachO.dir/MarkLive.cpp.o MachO/CMakeFiles/lldMachO.dir/ObjC.cpp.o MachO/CMakeFiles/lldMachO.dir/OutputSection.cpp.o MachO/CMakeFiles/lldMachO.dir/OutputSegment.cpp.o MachO/CMakeFiles/lldMachO.dir/Relocations.cpp.o MachO/CMakeFiles/lldMachO.dir/BPSectionOrderer.cpp.o MachO/CMakeFiles/lldMachO.dir/SectionPriorities.cpp.o MachO/CMakeFiles/lldMachO.dir/Sections.cpp.o MachO/CMakeFiles/lldMachO.dir/SymbolTable.cpp.o MachO/CMakeFiles/lldMachO.dir/Symbols.cpp.o MachO/CMakeFiles/lldMachO.dir/SyntheticSections.cpp.o MachO/CMakeFiles/lldMachO.dir/Target.cpp.o MachO/CMakeFiles/lldMachO.dir/UnwindInfoSection.cpp.o MachO/CMakeFiles/lldMachO.dir/Writer.cpp.o -L/usr/lib/llvm20/lib -Wl,-rpath,"\$ORIGIN/../lib:/usr/lib/llvm20/lib:/home/user/aports/main/lld20/src/lld-20.1.5.src/build/lib:" lib/liblldCommon.so.20.1 /usr/lib/llvm20/lib/libLLVM.so.20.1 && :
/usr/lib/gcc/powerpc-alpine-linux-musl/14.3.0/../../../../powerpc-alpine-linux-musl/bin/ld: MachO/CMakeFiles/lldMachO.dir/Driver.cpp.o: in function `handleExplicitExports()':
/usr/lib/gcc/powerpc-alpine-linux-musl/14.3.0/../../../../include/c++/14.3.0/bits/atomic_base.h:501:(.text._ZL21handleExplicitExportsv+0xb8): undefined reference to `__atomic_load_8'
/usr/lib/gcc/powerpc-alpine-linux-musl/14.3.0/../../../../powerpc-alpine-linux-musl/bin/ld: /usr/lib/gcc/powerpc-alpine-linux-musl/14.3.0/../../../../include/c++/14.3.0/bits/atomic_base.h:501:(.text._ZL21handleExplicitExportsv+0x180): undefined reference to `__atomic_load_8'
/usr/lib/gcc/powerpc-alpine-linux-musl/14.3.0/../../../../powerpc-alpine-linux-musl/bin/ld: MachO/CMakeFiles/lldMachO.dir/Driver.cpp.o: in function `void llvm::function_ref<void (unsigned int)>::callback_fn<llvm::parallelForEach<lld::macho::Symbol* const*, handleExplicitExports()::$_0>(lld::macho::Symbol* const*, lld::macho::Symbol* const*, handleExplicitExports()::$_0)::{lambda(unsigned int)#1}>(int, unsigned int)':
/usr/lib/gcc/powerpc-alpine-linux-musl/14.3.0/../../../../include/c++/14.3.0/bits/atomic_base.h:631:(.text._ZN4llvm12function_refIFvjEE11callback_fnIZNS_15parallelForEachIPKPN3lld5macho6SymbolEZL21handleExplicitExportsvE3$_0EEvT_SC_T0_EUljE_EEvij+0xd4): undefined reference to `__atomic_fetch_add_8'
clang++-20: error: linker command failed with exit code 1 (use -v to see invocation)
```
CC @int3 @gkmhub @smeenai
Similar to
llvm@f0b451c
clayborg
pushed a commit
that referenced
this pull request
Oct 31, 2025
llvm#164955 has a use-after-scope (https://lab.llvm.org/buildbot/#/builders/169/builds/16454): ``` ==mlir-opt==3940651==ERROR: AddressSanitizer: stack-use-after-scope on address 0x6e1f6ba5c878 at pc 0x6336b214912a bp 0x7ffe607f1670 sp 0x7ffe607f1668 READ of size 4 at 0x6e1f6ba5c878 thread T0 #0 0x6336b2149129 in size /home/b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/ADT/SmallVector.h:80:32 #1 0x6336b2149129 in operator[] /home/b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/ADT/SmallVector.h:299:5 #2 0x6336b2149129 in populateBoundsForShapedValueDim /home/b/sanitizer-x86_64-linux-fast/build/llvm-project/mlir/lib/Dialect/MemRef/IR/ValueBoundsOpInterfaceImpl.cpp:113:43 ... ``` This patch attempts to fix-forward by stack-allocating reassocIndices, instead of taking a reference to a return value.
clayborg
pushed a commit
that referenced
this pull request
Nov 14, 2025
## Summary
Fix `FindProcesses` to respect Android's `hidepid=2` security model and
enable name matching for Android apps.
## Problem
1. Called `adb shell pidof` or `adb shell ps` directly, bypassing
Android's process visibility restrictions
2. Name matching failed for Android apps - searched for
`com.example.myapp` but GDB Remote Protocol reports `app_process64`
Android apps fork from Zygote, so `/proc/PID/exe` points to
`app_process64` for all apps. The actual package name is only in
`/proc/PID/cmdline`. The previous implementation applied name filters
without supplementing with cmdline, so searches failed.
## Fix
- Delegate to lldb-server via GDB Remote Protocol (respects `hidepid=2`)
- Get all visible processes, supplement zygote/app_process entries with
cmdline, then apply name matching
- Only fetch cmdline for zygote apps (performance), parallelize with
`xargs -P 8`
- Remove redundant code (GDB Remote Protocol already provides GID/arch)
## Test Results
### Before this fix:
```
(lldb) platform process list
error: no processes were found on the "remote-android" platform
(lldb) platform process list -n com.example.hellojni
1 matching process was found on "remote-android"
PID PARENT USER TRIPLE NAME
====== ====== ========== ============================== ============================
5276 359 u0_a192 com.example.hellojni
^^^^^^^^ Missing triple!
```
### After this fix:
```
(lldb) platform process list
PID PARENT USER TRIPLE NAME
====== ====== ========== ============================== ============================
1 0 root aarch64-unknown-linux-android init
2 0 root [kthreadd]
359 1 system aarch64-unknown-linux-android app_process64
5276 359 u0_a192 aarch64-unknown-linux-android com.example.hellojni
5357 5355 u0_a192 aarch64-unknown-linux-android sh
5377 5370 u0_a192 aarch64-unknown-linux-android lldb-server
^^^^^^^^ User-space processes now have triples!
(lldb) platform process list -n com.example.hellojni
1 matching process was found on "remote-android"
PID PARENT USER TRIPLE NAME
====== ====== ========== ============================== ============================
5276 359 u0_a192 aarch64-unknown-linux-android com.example.hellojni
(lldb) process attach -n com.example.hellojni
Process 5276 stopped
* thread #1, name = 'example.hellojni', stop reason = signal SIGSTOP
```
## Test Plan
With an Android device/emulator connected:
1. Start lldb-server on device:
```bash
adb push lldb-server /data/local/tmp/
adb shell chmod +x /data/local/tmp/lldb-server
adb shell /data/local/tmp/lldb-server platform --listen 127.0.0.1:9500 --server
```
2. Connect from LLDB:
```
(lldb) platform select remote-android
(lldb) platform connect connect://127.0.0.1:9500
(lldb) platform process list
```
3. Verify:
- `platform process list` returns all processes with triple information
- `platform process list -n com.example.app` finds Android apps by
package name
- `process attach -n com.example.app` successfully attaches to Android
apps
## Impact
Restores `platform process list` on Android with architecture
information and package name lookup. All name matching modes now work
correctly.
Fixes llvm#164192
clayborg
pushed a commit
that referenced
this pull request
Nov 14, 2025
…am (llvm#167724) This got exposed by `09262656f32ab3f2e1d82e5342ba37eecac52522`. The underlying stream of `m_os` is referenced by the `TextDiagnostic` member of `TextDiagnosticPrinter`. It got turned into a `llvm::formatted_raw_ostream` in the commit above. When `~TextDiagnosticPrinter` (and thus `~TextDiagnostic`) is invoked, we now call `~formatted_raw_ostream`, which tries to access the underlying stream. But `m_os` was already deleted because it is earlier in the order of destruction in `TextDiagnosticPrinter`. Move the `m_os` member before the `TextDiagnosticPrinter` to avoid a use-after-free. Drive-by: * Also move the `m_output` member which the `m_os` holds a reference to. The fact it's a reference indicates the expectation is most likely that the string outlives the stream. The ASAN macOS bot is currently failing with this: ``` 08:15:39 ================================================================= 08:15:39 ==61103==ERROR: AddressSanitizer: heap-use-after-free on address 0x60600012cf40 at pc 0x00012140d304 bp 0x00016eecc850 sp 0x00016eecc848 08:15:39 READ of size 8 at 0x60600012cf40 thread T0 08:15:39 #0 0x00012140d300 in llvm::formatted_raw_ostream::releaseStream() FormattedStream.h:205 08:15:39 #1 0x00012140d3a4 in llvm::formatted_raw_ostream::~formatted_raw_ostream() FormattedStream.h:145 08:15:39 #2 0x00012604abf8 in clang::TextDiagnostic::~TextDiagnostic() TextDiagnostic.cpp:721 08:15:39 #3 0x00012605dc80 in clang::TextDiagnosticPrinter::~TextDiagnosticPrinter() TextDiagnosticPrinter.cpp:30 08:15:39 #4 0x00012605dd5c in clang::TextDiagnosticPrinter::~TextDiagnosticPrinter() TextDiagnosticPrinter.cpp:27 08:15:39 #5 0x0001231fb210 in (anonymous namespace)::StoringDiagnosticConsumer::~StoringDiagnosticConsumer() ClangModulesDeclVendor.cpp:47 08:15:39 #6 0x0001231fb3bc in (anonymous namespace)::StoringDiagnosticConsumer::~StoringDiagnosticConsumer() ClangModulesDeclVendor.cpp:47 08:15:39 #7 0x000129aa9d70 in clang::DiagnosticsEngine::~DiagnosticsEngine() Diagnostic.cpp:91 08:15:39 #8 0x0001230436b8 in llvm::RefCountedBase<clang::DiagnosticsEngine>::Release() const IntrusiveRefCntPtr.h:103 08:15:39 #9 0x0001231fe6c8 in (anonymous namespace)::ClangModulesDeclVendorImpl::~ClangModulesDeclVendorImpl() ClangModulesDeclVendor.cpp:93 08:15:39 #10 0x0001231fe858 in (anonymous namespace)::ClangModulesDeclVendorImpl::~ClangModulesDeclVendorImpl() ClangModulesDeclVendor.cpp:93 ... 08:15:39 08:15:39 0x60600012cf40 is located 32 bytes inside of 56-byte region [0x60600012cf20,0x60600012cf58) 08:15:39 freed by thread T0 here: 08:15:39 #0 0x0001018abb88 in _ZdlPv+0x74 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x4bb88) 08:15:39 #1 0x0001231fb1c0 in (anonymous namespace)::StoringDiagnosticConsumer::~StoringDiagnosticConsumer() ClangModulesDeclVendor.cpp:47 08:15:39 #2 0x0001231fb3bc in (anonymous namespace)::StoringDiagnosticConsumer::~StoringDiagnosticConsumer() ClangModulesDeclVendor.cpp:47 08:15:39 #3 0x000129aa9d70 in clang::DiagnosticsEngine::~DiagnosticsEngine() Diagnostic.cpp:91 08:15:39 #4 0x0001230436b8 in llvm::RefCountedBase<clang::DiagnosticsEngine>::Release() const IntrusiveRefCntPtr.h:103 08:15:39 #5 0x0001231fe6c8 in (anonymous namespace)::ClangModulesDeclVendorImpl::~ClangModulesDeclVendorImpl() ClangModulesDeclVendor.cpp:93 08:15:39 #6 0x0001231fe858 in (anonymous namespace)::ClangModulesDeclVendorImpl::~ClangModulesDeclVendorImpl() ClangModulesDeclVendor.cpp:93 ... 08:15:39 08:15:39 previously allocated by thread T0 here: 08:15:39 #0 0x0001018ab760 in _Znwm+0x74 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x4b760) 08:15:39 #1 0x0001231f8dec in lldb_private::ClangModulesDeclVendor::Create(lldb_private::Target&) ClangModulesDeclVendor.cpp:732 08:15:39 #2 0x00012320af58 in lldb_private::ClangPersistentVariables::GetClangModulesDeclVendor() ClangPersistentVariables.cpp:124 08:15:39 #3 0x0001232111f0 in lldb_private::ClangUserExpression::PrepareForParsing(lldb_private::DiagnosticManager&, lldb_private::ExecutionContext&, bool) ClangUserExpression.cpp:536 08:15:39 #4 0x000123213790 in lldb_private::ClangUserExpression::Parse(lldb_private::DiagnosticManager&, lldb_private::ExecutionContext&, lldb_private::ExecutionPolicy, bool, bool) ClangUserExpression.cpp:647 08:15:39 #5 0x00012032b258 in lldb_private::UserExpression::Evaluate(lldb_private::ExecutionContext&, lldb_private::EvaluateExpressionOptions const&, llvm::StringRef, llvm::StringRef, std::__1::shared_ptr<lldb_private::ValueObject>&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*, lldb_private::ValueObject*) UserExpression.cpp:280 08:15:39 #6 0x000120724010 in lldb_private::Target::EvaluateExpression(llvm::StringRef, lldb_private::ExecutionContextScope*, std::__1::shared_ptr<lldb_private::ValueObject>&, lldb_private::EvaluateExpressionOptions const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*, lldb_private::ValueObject*) Target.cpp:2905 08:15:39 #7 0x00011fc7bde0 in lldb::SBTarget::EvaluateExpression(char const*, lldb::SBExpressionOptions const&) SBTarget.cpp:2305 08:15:39 ==61103==ABORTING ... ```
clayborg
pushed a commit
that referenced
this pull request
Nov 14, 2025
llvm#168105) …63019)" This reverts commit 92e5608.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Server errors were being disposed right after parsing in the client. Instead, now they are displayed to the user. This helps a lot with development.
I'm using Debugger::Report error for this because they are non-blocking issues, as the CPU target can keep being debugged, but the user needs to know that the GPU plugin couldn't be initialized and they can report the issue if they want it.