[all-commits] [llvm/llvm-project] 331150: [lldb] Move host platform implementations into the...

Tue Apr 5 02:23:19 PDT 2022

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 331150a47dd5b26758293d73c5df3aa1b61ecad9
      https://github.com/llvm/llvm-project/commit/331150a47dd5b26758293d73c5df3aa1b61ecad9
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2022-04-05 (Tue, 05 Apr 2022)

  Changed paths:
    M lldb/include/lldb/Target/Platform.h
    M lldb/source/Plugins/Platform/QemuUser/PlatformQemuUser.h
    M lldb/source/Target/Platform.cpp
    M lldb/source/Target/RemoteAwarePlatform.cpp
    A lldb/test/API/qemu/TestQemuAPI.py

  Log Message:
  -----------
  [lldb] Move host platform implementations into the base class

About half of our host platform code was implemented in the Platform
class, while the rest was it RemoteAwarePlatform. Most of the time, this
did not matter, as nearly all our platforms are also
RemoteAwarePlatforms. It makes a difference for PlatformQemu, which
descends directly from the base class (as it is local-only).

This patch moves all host code paths into the base class, and marks
PlatformQemu as a "host" platform so it can make use of them (it sounds
slightly strange, but that is consistent with what the apple simulator
platforms are doing). Not all of the host implementations make sense for
this platform, but it can always override those that don't.

I add some basic tests using the platform file apis to exercise this
functionality.

Differential Revision: https://reviews.llvm.org/D122898

  Commit: 4384c96fe7eb5ceb5f2c1ece4a73c22a18bac19f
      https://github.com/llvm/llvm-project/commit/4384c96fe7eb5ceb5f2c1ece4a73c22a18bac19f
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2022-04-05 (Tue, 05 Apr 2022)

  Changed paths:
    M lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
    A lldb/test/API/functionalities/thread/main_thread_exit/Makefile
    A lldb/test/API/functionalities/thread/main_thread_exit/TestMainThreadExit.py
    A lldb/test/API/functionalities/thread/main_thread_exit/main.cpp

  Log Message:
  -----------
  [lldb/linux] Handle main thread exits

This patch handles the situation where the main thread exits (through
the SYS_exit syscall). In this case, the process as a whole continues
running until all of the other threads exit, or one of them issues an
exit_group syscall.

The patch consists of two changes:
- a moderate redesign of the handling of thread exit (WIFEXITED) events.
  Previously, we were removing (forgetting) a thread once we received
  the WIFEXITED (or WIFSIGNALED) event. This was problematic for the
  main thread, since the main thread WIFEXITED event (which is better thought
  of as a process-wide event) gets reported only after the entire process
  exits. This resulted in deadlocks, where we were waiting for the
  process to stop (because we still considered the main thread "live").

  This patch changes the logic such that the main thread is removed as
  soon as its PTRACE_EVENT_EXIT (the pre-exit) event is received. At
  this point we can consider the thread gone (for most purposes). As a
  corrolary, I needed to add special logic to catch process-wide exit
  events in the cases where we don't have the main thread around.

- The second part of the patch is the removal of the assumptions that
  the main thread is always available. This generally meant replacing
  the uses of GetThreadByID(process_id) with GetCurrentThread() in
  various process-wide operations (such as memory reads).

Differential Revision: https://reviews.llvm.org/D122716

  Commit: e67cee09499cbf386334115a627cd4fbe19cb01c
      https://github.com/llvm/llvm-project/commit/e67cee09499cbf386334115a627cd4fbe19cb01c
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2022-04-05 (Tue, 05 Apr 2022)

  Changed paths:
    M lldb/include/lldb/Target/DynamicLoader.h
    M lldb/packages/Python/lldbsuite/test/gdbclientutils.py
    M lldb/source/Core/DynamicLoader.cpp
    M lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp
    M lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.h
    M lldb/source/Plugins/DynamicLoader/wasm-DYLD/DynamicLoaderWasmDYLD.cpp
    M lldb/source/Plugins/DynamicLoader/wasm-DYLD/DynamicLoaderWasmDYLD.h
    A lldb/test/API/functionalities/gdb_remote_client/TestGdbClientModuleLoad.py
    M lldb/test/API/functionalities/gdb_remote_client/TestWasm.py
    A lldb/test/API/functionalities/gdb_remote_client/module_load.yaml

  Log Message:
  -----------
  [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

  Commit: dbb158ebf4e3232065030b12762a98a1a5bb55c6
      https://github.com/llvm/llvm-project/commit/dbb158ebf4e3232065030b12762a98a1a5bb55c6
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2022-04-05 (Tue, 05 Apr 2022)

  Changed paths:
    M llvm/include/llvm/Transforms/IPO/ProfiledCallGraph.h
    M llvm/include/llvm/Transforms/IPO/SampleContextTracker.h

  Log Message:
  -----------
  Remove top-level using directives from Transforms/IPO headers

These directives pollute the namespace of all files which include the
header.

Compare: https://github.com/llvm/llvm-project/compare/a9bd565ff2d2...dbb158ebf4e3