diff options
| author | Ben Langmuir <blangmuir@apple.com> | 2024-08-23 10:32:14 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-08-23 10:32:14 -0700 |
| commit | fa089efa6c70f4da8618f2f41ee9c7db86e2b0e0 (patch) | |
| tree | da493d757fe82457ea14f800f3399428136becb8 /lldb/source/Commands/CommandObjectMemory.cpp | |
| parent | 960a210b1f22f74ba32a04acbb5d3134d4443839 (diff) | |
| download | llvm-fa089efa6c70f4da8618f2f41ee9c7db86e2b0e0.zip llvm-fa089efa6c70f4da8618f2f41ee9c7db86e2b0e0.tar.gz llvm-fa089efa6c70f4da8618f2f41ee9c7db86e2b0e0.tar.bz2 | |
[orc][mach-o] Unlock the JITDylib state mutex during +load (#105333)
Similar to what was already done for static initializers, we need to
unlock the state mutext when calling out to libobjc to run +load methods
in case they cause us to reenter the runtime, which was previously
deadlocking. No test for now, because we don't have any code paths in
llvm-jitlink itself that could lead to this deadlock. If we interpose
calls to dlopen to go back to the JIT in the future then calling dlopen
from a +load is the easiest way to reproduce this.
rdar://133430490
Diffstat (limited to 'lldb/source/Commands/CommandObjectMemory.cpp')
0 files changed, 0 insertions, 0 deletions