llvm-project/lldb
Pavel Labath e67cee0949 [lldb] Avoid duplicate vdso modules when opening core files
When opening core files (and also in some other situations) we could end
up with two vdso modules. This could happen because the vdso module is
very special, and over the years, we have accumulated various ways to
load it.

In D10800, we added one mechanism for loading it, which took the form of
a generic load-from-memory capability. Unfortunately loading an elf file
from memory is not possible (because the loader never loads the entire
file), and our attempts to do so were causing crashes. So, in D34352, we
partially reverted D10800 and implemented a custom mechanism specific to
the vdso.

Unfortunately, enough of D10800 remained such that, under the right
circumstances, it could end up loading a second (non-functional) copy of
the vdso module. This happened when the process plugin did not support
the extended MemoryRegionInfo query (added in D22219, to workaround a
different bug), which meant that the loader plugin was not able to
recognise that the linux-vdso.so.1 module (this is how the loader calls
it) is in fact the same as the [vdso] module (the name used in
/proc/$PID/maps) we loaded before. This typically happened in a core
file, as they don't store this kind of information.

This patch fixes the issue by completing the revert of D10800 -- the
memory loading code is removed completely. It also reduces the scope of
the hackaround introduced in D22219 -- it isn't completely sound and is
only relevant for fairly old (but still supported) versions of android.

I added the memory loading logic to the wasm dynamic loader, which has
since appeared and is relying on this feature (it even has a test). As
far as I can tell loading wasm modules from memory is possible and
reliable. MachO memory loading is not affected by this patch, as it uses
a completely different code path.

Since the scenarios/patches I described came without test cases, I have
created two new gdb-client tests cases for them. They're not
particularly readable, but right now, this is the best way we can
simulate the behavior (bugs) of a particular dynamic linker.

Differential Revision: https://reviews.llvm.org/D122660
2022-04-05 11:22:37 +02:00
..
bindings [lldb] Expose diagnostic events through the SB API 2022-03-16 15:03:31 -07:00
cmake [lldb] Add support for a "global" lldbinit file 2022-02-18 12:30:22 +01:00
docs [trace][intelpt] Server side changes for TSC to wall time conversion 2022-03-24 05:36:21 -07:00
examples [lldb/crashlog] Parse thread fields and pass it to crashlog scripted process 2022-03-25 14:59:50 -07:00
include/lldb [lldb] Avoid duplicate vdso modules when opening core files 2022-04-05 11:22:37 +02:00
packages/Python/lldbsuite [lldb] Avoid duplicate vdso modules when opening core files 2022-04-05 11:22:37 +02:00
resources [lldb] Remove stale LLDB-Info.plist 2021-01-08 10:12:16 -08:00
scripts Prefer /usr/bin/env xxx over /usr/bin/xxx where xxx = perl, python, awk 2021-02-25 11:32:27 +01:00
source [lldb] Avoid duplicate vdso modules when opening core files 2022-04-05 11:22:37 +02:00
test [lldb] Avoid duplicate vdso modules when opening core files 2022-04-05 11:22:37 +02:00
third_party/Python/module [lldb][NFC] Inclusive language: replace master/slave names for ptys 2021-11-12 10:54:18 -06:00
tools Add DumpBinaryEscaped method to JSONGenerator, avoid extra copy 2022-04-04 14:14:02 -07:00
unittests Prevent GetAugmentedArchSpec() from attaching "unknown" environments 2022-04-04 08:56:58 -07:00
utils [lldb] Match test dependencies name to other LLVM projects. 2021-05-21 00:10:27 -07:00
.clang-format
.clang-tidy [lldb] Replace default bodies of special member functions with = default; 2021-07-02 11:31:16 -07:00
.gitignore
CMakeLists.txt [cmake] Make include(GNUInstallDirs) always below project(..) 2022-01-20 18:59:17 +00:00
CODE_OWNERS.txt [CODE OWNERS] Add wallace as code owner 2022-01-12 12:36:30 -08:00
LICENSE.TXT
use_lldb_suite_root.py