This patch fixes an issue, where if the thread has a signal blocked when
we try to inject it into the process (via vCont), then instead of
executing straight away, the injected signal will trigger another stop
when the thread unblocks the signal.
As (linux) threads start their life with SIGUSR1 (among others)
disabled, and only enable it during initialization, injecting the signal
during this window did not behave as expected. The fix is to change the
test to ensure the signal gets injected with the signal unblocked.
The simplest way to do this was to write a dedicated inferior for this
test. I also created a new header to factor out the function retrieving
the (os-specific) thread id.
As discussed on lldb-dev
<https://lists.llvm.org/pipermail/lldb-dev/2021-March/016777.html> the
mips code is unmaintained and untested. It also carries a lot of
technical debt which is not limited to mips-specific code.
Generic mips support remains (and is going to be used by the upcoming
freebsd code). Resurrecting mips support should be a matter of re-adding
the relevant register context files (while avoiding reintroducing the
debt).
Add a minimal support for the multiprocess extension in lldb-server.
The server indicates support for it via qSupported, and accepts
thread-ids containing a PID. However, it still does not support
debugging more than one inferior, so any other PID value results
in an error.
Differential Revision: https://reviews.llvm.org/D98482
TestVSCode_disconnect.test_launch fails with clean up error because
disconnect gets called twice once from the test case and once from
the tear down hook.
This patch disables disconnect after its been called from test_launch
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D99491
This is apparently allowed in Objective-C so we should test this in LLDB.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D99513
This is an LLDB test for the ASTImporter crash that got fixed in D99077.
The test is using Clang modules for the properties as it seems the conflicting
names are not actually correctly handled when generating debug information
(only the first property is emitted and the second one is ignored in the current
clang ToT).
Commit 6bc1e69de2 changed the search string
to also check for the generated strings that surround the plain assert:
Assertion `false && "lldb-test assert"' failed
^^^^^^^^^
This causes the test to fail on setups where the generated assert message
looks different. E.g., on macOS the generated message looks like this:
Assertion failed: (false && "lldb_assert failed"), function lldb_assert
This reverts the old behaviour of just checking for the actual string we
have inside LLDB.
LLDB on Linux built with symbols is showing this error.
Without symbols it still PASSes:
lldb-test: .../lldb/source/Utility/LLDBAssert.cpp:29: void lldb_private::lldb_assert(bool, const char *, const char *, const char *, unsigned int): Assertion `false && "lldb_assert failed"' failed.
With symbols it FAILs:
lldb-test: .../lldb/tools/lldb-test/lldb-test.cpp:1086: int opts::assert::lldb_assert(lldb_private::Debugger &): Assertion `false && "lldb-test assert"' failed.
Differential Revision: https://reviews.llvm.org/D99462
LLDB can often appear deadlocked to users that use IDEs when it is indexing DWARF, or parsing symbol tables. These long running operations can make a debug session appear to be doing nothing even though a lot of work is going on inside LLDB. This patch adds a public API to allow clients to listen to debugger events that report progress and will allow UI to create an activity window or display that can show users what is going on and keep them informed of expensive operations that are going on inside LLDB.
Differential Revision: https://reviews.llvm.org/D97739
The commit passes the tests on Darwin. The failure on linux shows
that this change was not sufficient to get this setting to work on linux,
but the behavior is the same as before the patch & test, and it caused
no new failures.
So marking the tests as Darwin only till someone can debug the Linux
issue.
The StopInfoBreakpoint::PerformAction was overriding the synchronous
breakpoint's ShouldStop report. Fix that and add a test.
This fixes two bugs in the original submission:
1) Actually generate both dylibs by including the second one in the Makefile
2) Don't ask synchronous callbacks for their opinion on whether to stop
in the async context, that info is taken care of by recording the m_should_stop
on entry to PerformAction.
Differential Revision: https://reviews.llvm.org/D98914
This patch introduces Scripted Processes to lldb.
The goal, here, is to be able to attach in the debugger to fake processes
that are backed by script files (in Python, Lua, Swift, etc ...) and
inspect them statically.
Scripted Processes can be used in cooperative multithreading environments
like the XNU Kernel or other real-time operating systems, but it can
also help us improve the debugger testing infrastructure by writting
synthetic tests that simulates hard-to-reproduce process/thread states.
Although ScriptedProcess is not feature-complete at the moment, it has
basic execution capabilities and will improve in the following patches.
rdar://65508855
Differential Revision: https://reviews.llvm.org/D95713
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This got removed in 68bb51acd5 and this enabled
the test on macOS (where it just causes lldb-server to crash). Re-adding the
decorator to get the tests passing again.
This patch introduces Scripted Processes to lldb.
The goal, here, is to be able to attach in the debugger to fake processes
that are backed by script files (in Python, Lua, Swift, etc ...) and
inspect them statically.
Scripted Processes can be used in cooperative multithreading environments
like the XNU Kernel or other real-time operating systems, but it can
also help us improve the debugger testing infrastructure by writting
synthetic tests that simulates hard-to-reproduce process/thread states.
Although ScriptedProcess is not feature-complete at the moment, it has
basic execution capabilities and will improve in the following patches.
rdar://65508855
Differential Revision: https://reviews.llvm.org/D95713
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
In order to facilitate the writting of Scripted Processes, this patch
introduces a `ScriptedProcess` python base class in the lldb module.
The base class holds the python interface with all the - abstract -
methods that need to be implemented by the inherited class but also some
methods that can be overwritten.
This patch also provides an example of a Scripted Process with the
`MyScriptedProcess` class.
rdar://65508855
Differential Revision: https://reviews.llvm.org/D95712
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
The file contained bogus input - the DIE list was not properly
terminated. This should not cause a crash, but it seems it was crashing
at least on linux arm and x86 windows.
lit has grown a feature where it stores the runtimes of all tests.
Normally, these times should be stored in the build directory, but
because our API tests have set test_exec_root to point to the source
tree, it has ended up polluting our checkout and led to the
.lit_test_times.txt being committed to the repository.
Delete this file, and adjust the exec root of API tests. I've also
needed to adjust the root of Shell tests, in order to avoid the two
overlapping.
SymbolFileDWARF::ResolveSymbolContext is currently unaware that in DWARF5 the primary file is specified at file index 0. As a result it misses to correctly resolve the symbol context for the primary file when DWARF5 debug data is used and the primary file is only specified at index 0.
This change makes use of CompileUnit::ResolveSymbolContext to resolve the symbol context. The ResolveSymbolContext in CompileUnit has been previously already updated to reflect changes in DWARF5
and contains a more readable version. It can resolve more, but will also do a bit more work than
SymbolFileDWARF::ResolveSymbolContext (getting the Module, and going through SymbolFileDWARF::ResolveSymbolContextForAddress), however, it's mostly directed by $resolve_scope
what will be resolved, and ensures that code is easier to maintain if there's only one path.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D98619
In general, it seems like the debugger should allow programs to load & run with
libraries as far as possible, instead of defaulting to being super-picky about
unavailable symbols.
This is critical on macOS/Darwin, as libswiftCore.dylib may 1) export a version
symbol using @available markup and then 2) expect that other exported APIs are
only dynamically used once the version symbol is checked. We can't open a
version of the library built with a bleeding-edge SDK on an older OS without
RTLD_LAXY (or pervasive/expensive @available markup added to dyld APIs).
This was previously committed as cb8c1ee269 and reverted due to
unknown failures on the Linux bots. This version adds additional asserts
to check that the shared objects are where we expect them & that calling
f1() from libt1 produces the expected value. The Linux failure is
tracked by https://bugs.llvm.org/show_bug.cgi?id=49656.
See: https://lists.llvm.org/pipermail/lldb-dev/2021-March/016796.html
Differential Revision: https://reviews.llvm.org/D98879
In general, it seems like the debugger should allow programs to load & run with
libraries as far as possible, instead of defaulting to being super-picky about
unavailable symbols.
This is critical on macOS/Darwin, as libswiftCore.dylib may 1) export a version
symbol using @available markup and then 2) expect that other exported APIs are
only dynamically used once the version symbol is checked. We can't open a
version of the library built with a bleeding-edge SDK on an older OS without
RTLD_LAXY (or pervasive/expensive @available markup added to dyld APIs).
See: https://lists.llvm.org/pipermail/lldb-dev/2021-March/016796.html
Differential Revision: https://reviews.llvm.org/D98879
Call `os_log_fault` when an lldb assert fails. We piggyback off
`LLVM_SUPPORT_XCODE_SIGNPOSTS`, which also depends on `os_log`, to avoid
having to introduce another CMake check and corresponding define.
This patch also adds a small test using lldb-test that verifies we abort
with a "regular" assertion when asserts are enabled.
Differential revision: https://reviews.llvm.org/D98987
This reverts commit 9406d43138.
I messed up a test, and when I got it right it was failing. The changed logic
doesn't work quite right (now the async callback called at sync time is
forcing us to stop. I need to be a little more careful about that.
We weren't taking into account the "m_should_stop" setting that the
synchronous breakpoint callback had already set when we did PerformAction
in the StopInfoBreakpoint. So we didn't obey its instructions when it
told us to stop. Fixed that and added some tests both for when we
just have the setting, and when we have the setting AND other breakpoints
at the shared library load notification breakpoint address.
Differential Revision: https://reviews.llvm.org/D98914
Make the API, Shell and Unit tests independent lit test suites. This
allows us to specify different dependencies and skip rebuilding all the
unit test (which is particularly expensive) when running check-lldb-api
or check-lldb-shell.
This does not change the autogenerated targets such as
check-lldb-shell-driver or the top level check-lldb target, which all
continue to work as before.
Differential revision: https://reviews.llvm.org/D98842
TestExitDuringExpression test_exit_before_one_thread_unwind fails
sporadically on both Arm and AArch64 linux buildbots.
This seems like a thread timing issue. I am marking it skip for now.
For instance, some recent clang emits this code on x86_64:
0x100002b99 <+57>: callq 0x100002b40 ; step_out_of_here at main.cpp:11
-> 0x100002b9e <+62>: xorl %eax, %eax
0x100002ba0 <+64>: popq %rbp
0x100002ba1 <+65>: retq
and the "xorl %eax, %eax" is attributed to the same line as the callq. Since
step out is supposed to stop just on returning from the function, you can't guarantee
it will end up on the next line. I changed the test to check that we were either
on the call line or on the next line, since either would be right depending on the
debug information.
The cause is the non-async-signal-safety printf function (et al.). If
the test managed to interrupt the process and inject a signal before the
printf("@started") call returned (but after it has actually written the
output), that string could end up being printed twice (presumably,
because the function did not manage the clear the userspace buffer, and
so the print call in the signal handler would print it once again).
This patch fixes the issue by replacing the printf call in the signal
handler with a sprintf+write combo, which should not suffer from that
problem (though I wouldn't go as far as to call it async signal safe).
Fix the test to account for recent test infrastructure changes, and make
it run locally to increase the chances of it continuing to work in the
future.
The TestGdbRemote_vContThreads.py were introduced to test NetBSD process
plugin's capability of sending per-thread and per-process signals.
However, at some point the tests started failing. From retrospective,
it is possible that they were relying on some bug in the plugin's
original signal handling.
Fix the tests not to expect the process to terminate after receiving
the signals. Instead, scan for output indicating that the signals were
received and match thread IDs in it. Enable 'signal to all threads'
test everywhere as it works fine on Linux. Add a new test for vCont
packet without specific thread IDs. Introduce a helper function
to cover the common part of tests.
While this does not fix all the problems on NetBSD, it enables a subset
of the tests on other systems. I am planning to add more tests
to the group while implementing multiprocess extension for vCont.
Differential Revision: https://reviews.llvm.org/D98749
Summary:
The request "evaluate" supports a "context" attribute, which is sent by VSCode. The attribute is defined here https://microsoft.github.io/debug-adapter-protocol/specification#Requests_Evaluate
The "clipboard" context is not yet supported by lldb-vscode, so we can forget about it for now. The 'repl' (i.e. Debug Console) and 'watch' (i.e. Watch Expression) contexts must use the expression parser in case the frame's variable path is not enough, as the user expects these expressions to never fail. On the other hand, the 'hover' expression is invoked whenever the user hovers on any keyword on the UI and the user is fine with the expression not being fully resolved, as they know that the 'repl' case is the fallback they can rely on.
Given that the 'hover' expression is invoked many many times without the user noticing it due to it being triggered by the mouse, I'm making it use only the frame's variable path functionality and not the expression parser. This should speed up tremendously the responsiveness of a debug session when the user only sets source breakpoints and inspect local variables, as the entire debug info is not needed to be parsed.
Regarding tests, I've tried to be as comprehensive as possible considering a multi-file project. Fortunately, the results from the "hover" case are enough most of the times.
Differential Revision: https://reviews.llvm.org/D98656
TestExitDuringExpression test_exit_before_one_thread_unwind fails
sporadically on arm/linux. This seems like a thread timing issue.
I am marking it skip for now.
The functionality is not posix specific. Also force the usage of the
gdb-remote process plugin in the gdb platform class.
This is not sufficient to make TestPlatformConnect pass on windows (it
seems it suffers from module loading issues, unrelated to this test),
but it at least makes it shut down correctly, so I change the skip to an
xfail.
D96202 removes the test dependency on debugserver which is causing a bunch of
tests to fail on a clean build.
This patch re-adds the dependency. I decided to not add the dependency in the
`test/API` folder as we actually need it in all kinds of tests (we have shell,
API and a few unit tests such as the LLDBServerTests that depend on the
debugserver binary). lldb-server is also handled in the same way.
Reviewed By: JDevlieghere, labath
Differential Revision: https://reviews.llvm.org/D98196
This variable is used to reducing the likelihood of hitting module cache
issues in CI where different branches can potentially run on the same
machine.
Use lit's with_system_environment function to propagate environment
variables to the tests. Include the usual suspects, as well as the
variables already explicitly forwarded.
LLVM OrcJIT is shifting from RuntimeDyld to JITLink. Starting with D96627 I am planning to add debug support. It would be great to have test coverage for it in LLDB early on.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D96634
This patch exposes the getter and setter methods for the command
interpreter `print_errors` run option.
rdar://74816984
Differential Revision: https://reviews.llvm.org/D98001
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch introduces a new interpreter setting to prevent LLDB from
re-executing the previous command when passing an empty command.
This can be very useful when performing actions that requires a long
time to complete.
To preserve the original behaviour, the setting defaults to `true`.
rdar://74983516
Differential Revision: https://reviews.llvm.org/D97999
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
We have a plugin.process.gdb-remote.packet-timeout setting, which can be
used to control how long the lldb client is willing to wait before
declaring the server side dead. Our test suite makes use of this
feature, and sets the setting value fairly high, as the low default
value can cause flaky tests, particularly on slower bots.
After fixing TestPlatformConnect (one of the few tests exercising the
remote platform capabilities of lldb) in 4b284b9ca, it immediately
started being flaky on the arm bots. It turns out this is because the
packet-timeout setting is not being applied to platform connections.
This patch makes the platform connections also respect the value of this
setting. It also adds a test which checks that the timeout value is
being honored.
Differential Revision: https://reviews.llvm.org/D97769
Apply changes from https://reviews.llvm.org/D91014 to other places where DWARF entries are being processed.
Test case is provided by @jankratochvil.
The test is marked to run only on x64 and exclude Windows and Darwin, because the assembly is not OS-independent.
(First attempt https://reviews.llvm.org/D96778 broke the build bots)
Reviewed By: jankratochvil
Differential Revision: https://reviews.llvm.org/D97765
GDB remote protocol does not specify length of g packet for register read. It depends on remote to include all or exclude certain registers from g packet. In case a register or set of registers is not included as part of g packet then we should fall back to p packet for reading all registers excluded from g packet by remote. This patch adds support for above feature and adds a test-case for the same.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D97498
This patch introduces Scripted Processes to lldb.
The goal, here, is to be able to attach in the debugger to fake processes
that are backed by script files (in Python, Lua, Swift, etc ...) and
inspect them statically.
Scripted Processes can be used in cooperative multithreading environments
like the XNU Kernel or other real-time operating systems, but it can
also help us improve the debugger testing infrastructure by writting
synthetic tests that simulates hard-to-reproduce process/thread states.
Although ScriptedProcess is not feature-complete at the moment, it has
basic execution capabilities and will improve in the following patches.
rdar://65508855
Differential Revision: https://reviews.llvm.org/D95713
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
In order to facilitate the writting of Scripted Processes, this patch
introduces a `ScriptedProcess` python base class in the lldb module.
The base class holds the python interface with all the - abstract -
methods that need to be implemented by the inherited class but also some
methods that can be overwritten.
This patch also provides an example of a Scripted Process with the
`MyScriptedProcess` class.
rdar://65508855
Differential Revision: https://reviews.llvm.org/D95712
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Skip the AVX-related lldb-server test on non-x86 architectures, as they
do not support AVX. While technically the test worked on Linux because
the AVX check would simply return false, other platforms do not provide
such a straightforward way of checking for AVX (especially remotely),
and the results of such check may need to be interpreted specially
for the platform in question.
Differential Revision: https://reviews.llvm.org/D97450
Use realpath() when spawning the executable create_after_attach
to workaround a FreeBSD plugin (and possibly others) problem.
If the executable is started via a path containing a symlink, it is
added to the module list twice -- via the real and apparent path.
This in turn cases the requested breakpoint to resolve twice.
Use realpath() for main program path in lldb-vscode breakpoint tests
to workaround a similar problem. If the passed path does not match
the realpath, lldb-vscode does not report the breakpoints as verified
and causes tests to fail.
Since the underlying problems are non-trivial to fix and the purpose
of these tests is not to reproduce symlink problems, let's apply
trivial workarounds to make them pass.
Differential Revision: https://reviews.llvm.org/D97230
Some implementations of the DeepCopy function called the copy constructor that copied m_parent member instead of setting a new parent. Others just leaved the base class's members (m_parent, m_callback, m_was_set) empty.
One more problem is that not all classes override this function, e.g. OptionValueArgs::DeepCopy produces OptionValueArray instance, and Target[Process/Thread]ValueProperty::DeepCopy produces OptionValueProperty. This makes downcasting via static_cast invalid.
The patch implements idiom "virtual constructor" to fix these issues.
Add a test that checks DeepCopy for correct copying/setting all data members of the base class.
Differential Revision: https://reviews.llvm.org/D96952
Add frame variable dereference suppport to libc++ `std::unique_ptr`.
This change allows for commands like `v *thing_up` and `v thing_up->m_id`. These commands now work the same way they would with raw pointers, and as they would with expression. This is done by adding an unaccounted for child member named `$$dereference$$`.
Without this change, the command would have to be written as `v *thing_up.__value_` or v thing_up.__value_->m_id` which exposes internal structure and is more clumsy to type.
Additionally, the existing tests were updated. See also https://reviews.llvm.org/D97165 which added deref support for `std::shared_ptr`.
Differential Revision: https://reviews.llvm.org/D97524
This patch replaces the static large function threshold variable with a
global debugger setting (`stop-disassembly-max-size`).
The default threshold is now set to 32KB (instead of 8KB) and can be modified.
rdar://74726362
Differential Revision: https://reviews.llvm.org/D97486
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
The current API for printing errors/warnings/messages from LLDB commands
sometimes adds newlines behind the messages for the caller. However, this
happens unconditionally so when the caller already specified a trailing newline
in the error message (or is trying to print a generated error message that ends
in a newline), LLDB ends up printing both the automatically added newline and
the one that was in the error message string. This leads to all the randomly
appearing new lines in error such as:
```
(lldb) command a
error: 'command alias' requires at least two arguments
(lldb) apropos a b
error: 'apropos' must be called with exactly one argument.
(lldb) why is there an empty line behind the second error?
```
This code adds a check that only appends the new line if the passed message
doesn't already contain a trailing new line.
Also removes the AppendRawWarning which had only one caller and doesn't serve
any purpose now.
Reviewed By: #lldb, mib
Differential Revision: https://reviews.llvm.org/D96947
In DWARF v4 compile units go in .debug_info and type units go in
.debug_types. However, in v5 both kinds of units are in .debug_info.
Therefore we can't decide whether to use the CU or TU index just by
looking at which section we're reading from. We have to wait until we
have read the unit type from the header.
Differential Revision: https://reviews.llvm.org/D96194
Add `frame variable` dereference suppport to libc++ `std::shared_ptr`.
This change allows for commands like `v *thing_sp` and `v thing_sp->m_id`. These
commands now work the same way they do with raw pointers. This is done by adding an
unaccounted for child member named `$$dereference$$`.
Also, add API tests for `std::shared_ptr`, previously there were none.
Differential Revision: https://reviews.llvm.org/D97165
When enabling LLDB tests with `LLVM_ENABLE_RUNTIMES=libcxx` CMake will
fail with:
```
LLDB test suite requires libc++, but it is currently disabled.
```
The issue is that the targets in LLVM_ENABLE_RUNTIMES are configured
after the targets in LLVM_ENABLE_PROJECTS, so at this point the check
for the `cxx` target will fail. CMake will add a dependency for a target
that does not exist yet however, so by first checking for `libcxx` in
LLVM_ENABLE_RUNTIMES we ensure that the `cxx` target will be present at
build time.
Tested with:
```
% cmake -G Ninja \
-C ~/local/llvm-project/lldb/cmake/caches/Apple-lldb-macOS.cmake \
-DLLVM_ENABLE_PROJECTS="clang;lldb" -DLLVM_ENABLE_RUNTIMES="libcxx" \
-DLIBCXX_INCLUDE_TESTS=NO ~/local/llvm-project/llvm
% ninja check-lldb
```
Reviewed By: smeenai, JDevlieghere
Differential Revision: https://reviews.llvm.org/D97227
Currently TypePrinter lumps anonymous classes and unnamed classes in one group "anonymous" this is not correct and can be confusing in some contexts.
Differential Revision: https://reviews.llvm.org/D96807
This reapplies 7df4eaaa93/D96202, which was reverted due to issues on
windows. These were caused by problems in the computation of the liblldb
directory, which was fixed by D96779.
The original commit message was:
Our test configuration logic assumes that the tests can be run either
with debugserver or with lldb-server. This is not entirely correct,
since lldb server has two "personalities" (platform server and debug
server) and debugserver is only a replacement for the latter.
A consequence of this is that it's not possible to test the platform
behavior of lldb-server on macos, as it is not possible to get a hold of
the lldb-server binary.
One solution to that would be to duplicate the server configuration
logic to be able to specify both executables. However, that seems
excessively redundant.
A well-behaved lldb should be able to find the debug server on its own,
and testing lldb with a different (lldb-|debug)server does not seem very
useful (even in the out-of-tree debugserver setup, we copy the server
into the build tree to make it appear "real").
Therefore, this patch deletes the configuration altogether and changes
the low-level server retrieval functions to be able to both lldb-server
and debugserver paths. They do this by consulting the "support
executable" directory of the lldb under test.
Differential Revision: https://reviews.llvm.org/D96202
VSCode was not being informed whenever a location had been resolved (after being initated as non-resolved), so even though it was actually resolved, the IDE would show a hollow dot (instead of a red dot) because it didn't know about the change.
Differential Revision: https://reviews.llvm.org/D96680
This issue was introduced in https://reviews.llvm.org/D92187.
The guard I'm changing were is supposed to act when linux is loading the linker for the second time (due to differences in paths like symlinks).
This is done by checking `module_sp != m_interpreter_module.lock()` however this will be true when `m_interpreter_module` wasn't initialized, making linux unload the linker module (the most visible result here is that lldb will stop getting notified about new modules loaded by the process, because it can't set the rendezvous breakpoint again after the stepping over it once).
The `m_interpreter_module` is not getting initialize when it goes through this path: dbfdb139f7/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp (L332), which happens when lldb was able to read the address from the dynamic section of the executable.
What I'm not sure about though, is if when we go through this path if we still load the linker twice on linux. If that's the case then it means we need to somehow set the m_interpreter_module instead of the fix I provide here. I've only tested this on Android.
Differential Revision: https://reviews.llvm.org/D96637
Michał Górny