Purge materialize hook. #9
Draft
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
gysit
force-pushed
the
remove-materialize-conversion
branch
from
c9c2d25 to
86a56b2
Compare
definelicht
reviewed
Mar 10, 2023
gysit
force-pushed
the
remove-materialize-conversion
branch
from
f4ad6b4 to
ef6c1d9
Compare
definelicht
approved these changes
Mar 12, 2023
gysit
force-pushed
the
remove-materialize-conversion
branch
3 times, most recently
from
521b3e4 to
0987786
Compare
gysit
force-pushed
the
inliner-interface
branch
from
7a7a055 to
4e87453
Compare
D142084 moved an enumeration inside a header from the llvm namespace into an anon namespace. Some of the bots started failing as a result. Differential Revision: https://reviews.llvm.org/D146419
This reverts commit 21cd04c.
This reverts commit 35c05f0.
…ion fragments Fixes llvm#61480 Reviewed By: dang Differential Revision: https://reviews.llvm.org/D146354
We're working on a transform in LSR which is essentiall an inverse of LFTR (in certain sub-cases). Move utilties so that they can be reused.
…r-prone redundancy See: http://eel.is/c++draft/diff.cpp17.class#2 Reviewed By: springerm Differential Revision: https://reviews.llvm.org/D146308
Internalize was trying to update CallGraph if the analysis was available, but the new PM doesn't really use it so there's little reason to update it.
…fadd with vcmla. NFC See D146407.
Summary: Some older compilers, which we still support, have problems handling the copy elision that allows us to directly move an `Error` to an `Expected`. This patch adds explicit moves to remove the error.
Summary: Some older compilers, which we still support, have problems handling the copy elision that allows us to directly move an `Error` to an `Expected`. This patch adds explicit moves to remove the error. Same as last patch but I forgot this one.
These are currently in a `Predicates = [HasStdExtZfhOrZfhmin]` block, but Zfhmin has no fcmp instructions so the definition makes no sense for Zfhmin. Differential Revision: https://reviews.llvm.org/D146435
This fixes a compile time issue due to guarding loop unswitching based on whether the enclosing function is cold. That approach is very inefficient in the case of large cold functions that contain numerous loops, since the loop pass calls isFunctionColdInCallGraph once per loop, and that function walks all BBs in the function (twice for Sample PGO) looking for any non-cold blocks. Originally, this code only checked if the current Loop's header was cold (D129599). However, that apparently caused a slowdown on a SPEC benchmark, and the example given was that of a cold inner loop nested in a non-cold outer loop (see comments in D129599). The fix was to check if the whole function is cold, done in D133275. This is overkill, and we can simply check if the header of any loop in the current loop's loop nest is non-cold (looking at both outer and inner loops). This patch drops the compile time for a large module by 40% with this approach. I also updated PGO-nontrivial-unswitch2.ll since it only had one cold loop in a non-cold function, so that it instead had IR based off the example given in the comments relating to the SPEC degradation in D129599. I confirmed that the new version of the test fails with the original check done in D129599 of only the current loop's header coldness. Similarly updated test PGO-nontrivial-unswitch.ll to contain a cold loop in a cold loop nest, and created PGO-nontrivial-unswitch3.ll to contain a non-cold loop in a non-cold loop nest. Differential Revision: https://reviews.llvm.org/D146383
Some test code was doing loose conversions caught by compiler warnings in the Fuchsia build. This included duplicated code in a few tests that was reconsolidated with the existing header file copy of the same functions. The MemoryMatcher abstraction presumes gtest-style matcher support, which is not available in Fuchsia's zxtest library. It's avoided in favor of simpler memory-comparing assertions. Reviewed By: abrachet Differential Revision: https://reviews.llvm.org/D146343
Fixes warning: format specifies type 'unsigned long' but the argument has type 'DataType' (aka 'unsigned long long') [-Wformat]
Fix several problems related to serialization causing command line defines to be reported as being built-in defines: * When serializing the <built-in> and <command line> files don't convert them into absolute paths. * When deserializing SM_SLOC_BUFFER_ENTRY we need to call setHasLineDirectives in the same way as we do for SM_SLOC_FILE_ENTRY. * When created suggested predefines based on the current command line options we need to add line markers in the same way that InitializePreprocessor does. * Adjust a place in clangd where it was implicitly relying on command line defines being treated as builtin. Differential Revision: https://reviews.llvm.org/D144651
Main benefit here is making the logic easier to follow, slightly more efficient, and more in line with LFTR. This is not NFC. There are three semantic changes here. First, we drop handling for constants on the LHS of the comparison. These are non-canonical, and we're very late in the optimization pipeline here, so there's no point in supporting this. I removed a test which covered this case. Second, we don't need the almost dead IV to be an addrec. We just need SCEV to be able to compute a trip count for it. Third, we require a simple IV for the almost dead IV. In theory, this removes cases we could have previously handled, but given a) zero testing and b) multiple known correctness issues, I'm adopting an attidute of narrowing this down to something which works correctly, and *then* expanding.
The goal of this patch is to add the ability for the CMake configure to fail when some optional test dependencies are not met. LLDB tries to be flexible when test dependencies are not present but there are cases where it would be useful to know that these dependencies are missing before we run the test suite. The intent here is to apply this setting on CI machines and make sure that they have useful optional dependencies installed. We recently hit a case where some CI machines were timing out while running the test suite because a few tests were hanging. With this option, we'll be able to know if the machine does not have psutil installed so we can install it and avoid the timeout scenario altogether. rdar://103194447 Differential Revision: https://reviews.llvm.org/D146335
…s [nfc] This invariant was introduced in 8f3d169.
Note that the comments being removed appear to be very out of sync with the actual code in question. Differential Revision: https://reviews.llvm.org/D146468
We do not want to add file path lib args when -r is specified. Differential Revision: https://reviews.llvm.org/D146578
We custom isel for ConstantFP that has higher priority than isel patterns. We were previously detecting valid FP constants for fli to early exit from the custom code. This detection called getLoadFPImm. Then we would run the isel patterns which would call getLoadFPImm a second time. With a little bit more code we can directly select the fli instruction in the custom handler and avoid a second call. Remove the incorrect mayRaiseFPException flag from the FLI instructions. Reviewed By: joshua-arch1 Differential Revision: https://reviews.llvm.org/D146093
We got it right for fclass.s and fclass.h.
update dependency for TransformOpsPyTdFiles Differential Revision: https://reviews.llvm.org/D146605
When doing store constant vector/scalar, some duplicated values can be reused. Add test case and will show combiner can improve these. Reviewed By: shchenz Differential Revision: https://reviews.llvm.org/D146500
Fix llvm#56532 Effectively, this reverts behavior introduced in https://reviews.llvm.org/D117087, which did two things: 1. Change delayed to early conversion of return object. 2. Introduced RVO possibilities because of early conversion. This patches fixes (1) and removes (2). I already worked on a follow up for (2) in a separated patch. I believe it's important to split these two because if the RVO causes any problems we can explore reverting (2) while maintaining (1). Notes on some testcase changes: - `pr59221.cpp` changed to `-O1` so we can check that the front-end honors the value checked for. Sounds like `-O3` without RVO is more likely to work with LLVM optimizations... - Comment out delete members `coroutine-no-move-ctor.cpp` since behavior now requires copies again. Differential Revision: https://reviews.llvm.org/D145639
…tain conditions - The cwg2563 issue is fixed by delaying GRO initialization only when the types mismatch between GRO and function return. - When the types match directly initialize, which indirectly enables RVO to kick in, partially restores behavior introduced in https://reviews.llvm.org/D117087. - Add entry to release notes. Background: llvm#56532 https://cplusplus.github.io/CWG/issues/2563.html cplusplus/papers#1414 Differential Revision: https://reviews.llvm.org/D145641
Reviewed By: MaskRay Closes llvm#55940 Differential Revision: https://reviews.llvm.org/D145646
…sOps Creating maximally folded and composd affine.apply operation during FoldMemRefAliasOps composes better with other transformations without having to interleave canonicalization passes. Differential Revision: https://reviews.llvm.org/D146515
All of these methods will invoke `getOrCreateSymbol(const Twine &Name)`, using `Twine` here makes these methods more flexible. Differential Revision: https://reviews.llvm.org/D145923
Plugin that counts the number of times each tree node occurs in a given program. Used for test coverage. Updated to fix build issues. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D143704
The patch was reverted because of hang, adding the test so that this doesn't happen again.
In the following example, we will end up hitting the `llvm_unreachable()`: https://godbolt.org/z/5sccc95Ec ```lang=C++ enum class E {}; const E glob[] = {{}}; void initlistWithinInitlist() { clang_analyzer_dump(glob[0]); // crashes at loading from `glob[0]` } ``` We should just return `std::nullopt` instead for these cases. It's better than crashing. Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D146538
Blocks are enumerated depth-first, but post-order. I.e., a block is enumerated when its successors have been enumerated. This iteration style is suitable when deleting blocks in a regions: in the absence of cycles, uses are deleted before their definitions. Differential Revision: https://reviews.llvm.org/D146125
The revision adds the handleArgument and handleResult handlers that allow users of the inlining interface to implement argument and result conversions that take argument and result attributes into account. The motivating use cases for this revision are taken from the LLVM dialect inliner, which has to copy arguments that are marked as byval and that also has to consider zeroext / signext when converting integers. All type conversions are currently handled by the materializeCallConversion hook. It runs before isLegalToInline and supports only the introduction of a single cast operation since it may have to rollback. The new handlers run shortly before and after inlining and cannot fail. As a result, they can introduce more complex ir such as copying a struct argument. At the moment, the new hooks cannot be used to perform type conversions since all type conversions have to be done using the materializeCallConversion. A follow up revision will either relax this constraint or drop materializeCallConversion in favor of the new and more flexible handlers. The revision also extends the CallableOpInterface to provide access to the argument and result attributes if available. Reviewed By: rriddle, Dinistro Differential Revision: https://reviews.llvm.org/D145582
…ock, try 2 The initial version was reverted because it looped infinitely if the likely successor isn't properly dominated by the predecessor. In practice it means that we went up the CFG through backedge and looped infinitely. I also added some paranoid assertion checks to make sure that every other invariant holds. I also found a hypothetical situation when we may go past the dominated block while following the likely successors (it means that in fact the dominated block is dynamically not reachable from dominating block) and explicitly prohibited this, though I don't have a motivating test showing that it's a real problem. https://reviews.llvm.org/D146276
The constructor of `OperationFolder` takes a listener. Therefore, the remaining API should not take any builder/rewriters. This could lead to double notifications in case a listener is attached to the builder/rewriter. As an internal cleanup, `OperationFolder` now has an `IRRewriter` instead of a `RewriterBase::Listener`. In most cases, `OperationFolder` no longer has to notify/deal with listeners. This is done by the rewriter. Differential Revision: https://reviews.llvm.org/D146134
The revision adds the llvm.experimental.noalias.scope.decl intrinsic to the LLVM dialect and updates the import and export accordingly. Reviewed By: Dinistro Differential Revision: https://reviews.llvm.org/D146504
This revision removes the materializeCallConversion hook and replaces it by a isTypeConvertible hook that checks if an argument or a result conversion is possible. The actual conversion is then performed using the recently introduced handleArgument and handleResult hooks. The revision enables argument and result conversions that create multiple operations rather than a single cast operation. Additionally, the handlers also have access to argument and result attributes that may provide extra information such as if an integer has to be sign or zero extended. Depends on D145582 Differential Revision: https://reviews.llvm.org/D145876
gysit
pushed a commit
that referenced
this pull request
Mar 23, 2023
This change prevents rare deadlocks observed for specific macOS/iOS GUI
applications which issue many `dlopen()` calls from multiple different
threads at startup and where TSan finds and reports a race during
startup. Providing a reliable test for this has been deemed infeasible.
Although I've only observed this deadlock on Apple platforms,
conceptually the cause is not confined to Apple code so the fix lives in
platform-independent code.
Deadlock scenario:
```
Thread 2 | Thread 4
ReportRace() |
Lock internal TSan mutexes |
&ctx->slot_mtx |
| dlopen() interceptor
| OnLibraryLoaded()
| MemoryMappingLayout::DumpListOfModules()
| calls dyld API, which takes internal lock
| lock() interceptor
| TSan tries to take internal mutexes again
| &ctx->slot_mtx
call into symbolizer |
MemoryMappingLayout::DumpListOfModules()
calls dyld API, which hangs on trying to take lock
```
Resulting in:
* Thread 2 has internal TSan mutex, blocked on dyld lock
* Thread 4 has dyld lock, blocked on internal TSan mutex
The fix prevents this situation by not intercepting any of the calls
originating from `MemoryMappingLayout::DumpListOfModules()`.
Stack traces for deadlock between ReportRace() and dlopen() interceptor:
```
thread #2, queue = 'com.apple.root.default-qos'
frame #0: libsystem_kernel.dylib
frame #1: libclang_rt.tsan_osx_dynamic.dylib`::wrap_os_unfair_lock_lock_with_options(lock=<unavailable>, options=<unavailable>) at tsan_interceptors_mac.cpp:306:3
frame #2: dyld`dyld4::RuntimeLocks::withLoadersReadLock(this=0x000000016f21b1e0, work=0x00000001814523c0) block_pointer) at DyldRuntimeState.cpp:227:28
frame #3: dyld`dyld4::APIs::_dyld_get_image_header(this=0x0000000101012a20, imageIndex=614) at DyldAPIs.cpp:240:11
frame #4: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::MemoryMappingLayout::CurrentImageHeader(this=<unavailable>) at sanitizer_procmaps_mac.cpp:391:35
frame #5: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::MemoryMappingLayout::Next(this=0x000000016f2a2800, segment=0x000000016f2a2738) at sanitizer_procmaps_mac.cpp:397:51
frame #6: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::MemoryMappingLayout::DumpListOfModules(this=0x000000016f2a2800, modules=0x00000001011000a0) at sanitizer_procmaps_mac.cpp:460:10
frame #7: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::ListOfModules::init(this=0x00000001011000a0) at sanitizer_mac.cpp:610:18
frame #8: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::Symbolizer::FindModuleForAddress(unsigned long) [inlined] __sanitizer::Symbolizer::RefreshModules(this=0x0000000101100078) at sanitizer_symbolizer_libcdep.cpp:185:12
frame #9: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::Symbolizer::FindModuleForAddress(this=0x0000000101100078, address=6465454512) at sanitizer_symbolizer_libcdep.cpp:204:5
frame #10: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::Symbolizer::SymbolizePC(this=0x0000000101100078, addr=6465454512) at sanitizer_symbolizer_libcdep.cpp:88:15
frame #11: libclang_rt.tsan_osx_dynamic.dylib`__tsan::SymbolizeCode(addr=6465454512) at tsan_symbolize.cpp:106:35
frame #12: libclang_rt.tsan_osx_dynamic.dylib`__tsan::SymbolizeStack(trace=StackTrace @ 0x0000600002d66d00) at tsan_rtl_report.cpp:112:28
frame #13: libclang_rt.tsan_osx_dynamic.dylib`__tsan::ScopedReportBase::AddMemoryAccess(this=0x000000016f2a2a90, addr=4381057136, external_tag=<unavailable>, s=<unavailable>, tid=<unavailable>, stack=<unavailable>, mset=0x00000001012fc310) at tsan_rtl_report.cpp:190:16
frame #14: libclang_rt.tsan_osx_dynamic.dylib`__tsan::ReportRace(thr=0x00000001012fc000, shadow_mem=0x000008020a4340e0, cur=<unavailable>, old=<unavailable>, typ0=1) at tsan_rtl_report.cpp:795:9
frame #15: libclang_rt.tsan_osx_dynamic.dylib`__tsan::DoReportRace(thr=0x00000001012fc000, shadow_mem=0x000008020a4340e0, cur=Shadow @ x22, old=Shadow @ 0x0000600002d6b4f0, typ=1) at tsan_rtl_access.cpp:166:3
frame #16: libclang_rt.tsan_osx_dynamic.dylib`::__tsan_read8(void *) at tsan_rtl_access.cpp:220:5
frame #17: libclang_rt.tsan_osx_dynamic.dylib`::__tsan_read8(void *) [inlined] __tsan::MemoryAccess(thr=0x00000001012fc000, pc=<unavailable>, addr=<unavailable>, size=8, typ=1) at tsan_rtl_access.cpp:442:3
frame llvm#18: libclang_rt.tsan_osx_dynamic.dylib`::__tsan_read8(addr=<unavailable>) at tsan_interface.inc:34:3
<call into TSan from from instrumented code>
thread #4, queue = 'com.apple.dock.fullscreen'
frame #0: libsystem_kernel.dylib
frame #1: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::FutexWait(p=<unavailable>, cmp=<unavailable>) at sanitizer_mac.cpp:540:3
frame #2: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::Semaphore::Wait(this=<unavailable>) at sanitizer_mutex.cpp:35:7
frame #3: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::Mutex::Lock(this=0x0000000102992a80) at sanitizer_mutex.h:196:18
frame #4: libclang_rt.tsan_osx_dynamic.dylib`__tsan::ScopedInterceptor::~ScopedInterceptor() [inlined] __sanitizer::GenericScopedLock<__sanitizer::Mutex>::GenericScopedLock(this=<unavailable>, mu=0x0000000102992a80) at sanitizer_mutex.h:383:10
frame #5: libclang_rt.tsan_osx_dynamic.dylib`__tsan::ScopedInterceptor::~ScopedInterceptor() [inlined] __sanitizer::GenericScopedLock<__sanitizer::Mutex>::GenericScopedLock(this=<unavailable>, mu=0x0000000102992a80) at sanitizer_mutex.h:382:77
frame #6: libclang_rt.tsan_osx_dynamic.dylib`__tsan::ScopedInterceptor::~ScopedInterceptor() at tsan_rtl.h:708:10
frame #7: libclang_rt.tsan_osx_dynamic.dylib`__tsan::ScopedInterceptor::~ScopedInterceptor() [inlined] __tsan::TryTraceFunc(thr=0x000000010f084000, pc=0) at tsan_rtl.h:751:7
frame #8: libclang_rt.tsan_osx_dynamic.dylib`__tsan::ScopedInterceptor::~ScopedInterceptor() [inlined] __tsan::FuncExit(thr=0x000000010f084000) at tsan_rtl.h:798:7
frame #9: libclang_rt.tsan_osx_dynamic.dylib`__tsan::ScopedInterceptor::~ScopedInterceptor(this=0x000000016f3ba280) at tsan_interceptors_posix.cpp:300:5
frame #10: libclang_rt.tsan_osx_dynamic.dylib`__tsan::ScopedInterceptor::~ScopedInterceptor(this=<unavailable>) at tsan_interceptors_posix.cpp:293:41
frame #11: libclang_rt.tsan_osx_dynamic.dylib`::wrap_os_unfair_lock_lock_with_options(lock=0x000000016f21b1e8, options=OS_UNFAIR_LOCK_NONE) at tsan_interceptors_mac.cpp:310:1
frame #12: dyld`dyld4::RuntimeLocks::withLoadersReadLock(this=0x000000016f21b1e0, work=0x00000001814525d4) block_pointer) at DyldRuntimeState.cpp:227:28
frame #13: dyld`dyld4::APIs::_dyld_get_image_vmaddr_slide(this=0x0000000101012a20, imageIndex=412) at DyldAPIs.cpp:273:11
frame #14: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::MemoryMappingLayout::Next(__sanitizer::MemoryMappedSegment*) at sanitizer_procmaps_mac.cpp:286:17
frame #15: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::MemoryMappingLayout::Next(this=0x000000016f3ba560, segment=0x000000016f3ba498) at sanitizer_procmaps_mac.cpp:432:15
frame #16: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::MemoryMappingLayout::DumpListOfModules(this=0x000000016f3ba560, modules=0x000000016f3ba618) at sanitizer_procmaps_mac.cpp:460:10
frame #17: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::ListOfModules::init(this=0x000000016f3ba618) at sanitizer_mac.cpp:610:18
frame llvm#18: libclang_rt.tsan_osx_dynamic.dylib`__sanitizer::LibIgnore::OnLibraryLoaded(this=0x0000000101f3aa40, name="<some library>") at sanitizer_libignore.cpp:54:11
frame llvm#19: libclang_rt.tsan_osx_dynamic.dylib`::wrap_dlopen(filename="<some library>", flag=<unavailable>) at sanitizer_common_interceptors.inc:6466:3
<library code>
```
rdar://106766395
Differential Revision: https://reviews.llvm.org/D146593
gysit
force-pushed
the
remove-materialize-conversion
branch
from
0987786 to
ed8c062
Compare
definelicht
pushed a commit
that referenced
this pull request
Apr 17, 2023
Fix crash in ASTImporter related to import of unnamed structures and typedefs to these maybe with pointer. There was a series of problems exposed by https://reviews.llvm.org/D133468 (commit 69a6417) in the ASTImporter breaking cross-translation unit analysis. This change fixes one of the problems exposed by that change for importing unnamed structures. The problem was discovered when running clang static analysis on open source projects using cross-translation unit analysis. Simple test command. Produces crash without change, passes all tests with change. ``` ninja ASTTests && ./tools/clang/unittests/AST/ASTTests --gtest_filter="*/*ImportAnonymousStruct/0" ``` Formatted crash stack: ``` ASTTests: <root>/clang/lib/AST/ASTContext.cpp:4787: clang::QualType clang::ASTContext::getTypedefType(const clang::TypedefNameDecl*, clang::QualType) const: Assertion `hasSameType(Decl->getUnderlyingType(), Underlying)' failed. ... #9 <addr> clang::ASTContext::getTypedefType(clang::TypedefNameDecl const*, clang::QualType) const <root>/clang/lib/AST/ASTContext.cpp:4789:26 <root>/clang/lib/AST/ASTImporter.cpp:1374:71 <root>/tools/clang/include/clang/AST/TypeNodes.inc:75:1 <root>/clang/lib/AST/ASTImporter.cpp:8663:8 ``` Reviewed By: donat.nagy Differential Revision: https://reviews.llvm.org/D145868
definelicht
pushed a commit
that referenced
this pull request
Jan 5, 2024
This has been flaky for a while, for example https://lab.llvm.org/buildbot/#/builders/96/builds/50350 ``` Command Output (stdout): -- lldb version 18.0.0git (https://github.com/llvm/llvm-project.git revision 3974d89) clang revision 3974d89 llvm revision 3974d89 "can't evaluate expressions when the process is running." ``` ``` PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. #0 0x0000ffffa46191a0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x529a1a0) #1 0x0000ffffa4617144 llvm::sys::RunSignalHandlers() (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x5298144) #2 0x0000ffffa46198d0 SignalHandler(int) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x529a8d0) #3 0x0000ffffab25b7dc (linux-vdso.so.1+0x7dc) #4 0x0000ffffab13d050 /build/glibc-Q8DG8B/glibc-2.31/string/../sysdeps/aarch64/multiarch/memcpy_advsimd.S:92:0 #5 0x0000ffffa446f420 lldb_private::process_gdb_remote::GDBRemoteRegisterContext::PrivateSetRegisterValue(unsigned int, llvm::ArrayRef<unsigned char>) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x50f0420) #6 0x0000ffffa446f7b8 lldb_private::process_gdb_remote::GDBRemoteRegisterContext::GetPrimordialRegister(lldb_private::RegisterInfo const*, lldb_private::process_gdb_remote::GDBRemoteCommunicationClient&) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x50f07b8) #7 0x0000ffffa446f308 lldb_private::process_gdb_remote::GDBRemoteRegisterContext::ReadRegisterBytes(lldb_private::RegisterInfo const*) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x50f0308) #8 0x0000ffffa446ec1c lldb_private::process_gdb_remote::GDBRemoteRegisterContext::ReadRegister(lldb_private::RegisterInfo const*, lldb_private::RegisterValue&) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x50efc1c) #9 0x0000ffffa412eaa4 lldb_private::RegisterContext::ReadRegisterAsUnsigned(lldb_private::RegisterInfo const*, unsigned long) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x4dafaa4) #10 0x0000ffffa420861c ReadLinuxProcessAddressMask(std::shared_ptr<lldb_private::Process>, llvm::StringRef) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x4e8961c) #11 0x0000ffffa4208430 ABISysV_arm64::FixCodeAddress(unsigned long) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x4e89430) ``` Judging by the backtrace something is trying to read the pointer authentication address/code mask registers. This explains why I've not seen this issue locally, as the buildbot runs on Graviton 3 with has the pointer authentication extension. I will try to reproduce, fix and re-enable the test.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.