[all-commits] [llvm/llvm-project] 553558: [lldb/dyld-posix] Avoid reading the module list in...

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 553558292eaef8867940856bd5272478cc51f4e0
      https://github.com/llvm/llvm-project/commit/553558292eaef8867940856bd5272478cc51f4e0
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2022-07-01 (Fri, 01 Jul 2022)

  Changed paths:
    M lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp
    M lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp

  Log Message:
  -----------
  [lldb/dyld-posix] Avoid reading the module list in inconsistent states

New glibc versions (since 2.34 or including this
<https://github.com/bminor/glibc/commit/ed3ce71f5c64c5f07cbde0ef03554ea8950d8f2c>
patch) trigger the rendezvous breakpoint after they have already added
some modules to the list. This did not play well with our dynamic
loader plugin which was doing a diff of the the reported modules in the
before (RT_ADD) and after (RT_CONSISTENT) states. Specifically, it
caused us to miss some of the modules.

While I think the old behavior makes more sense, I don't think that lldb
is doing the right thing either, as the documentation states that we
should not be expecting a consistent view in the RT_ADD (and RT_DELETE)
states.

Therefore, this patch changes the lldb algorithm to compare the module
list against the previous consistent snapshot. This fixes the previous
issue, and I believe it is more correct in general. It also reduces the
number of times we are fetching the module info, which should speed up
the debugging of processes with many shared libraries.

The change in RefreshModules ensures we don't broadcast the loaded
notification for the dynamic loader (ld.so) module more than once.

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


  Commit: b6b65403b3826af5404f874f32d7abd8ef8a8a96
      https://github.com/llvm/llvm-project/commit/b6b65403b3826af5404f874f32d7abd8ef8a8a96
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2022-07-01 (Fri, 01 Jul 2022)

  Changed paths:
    A lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string/simulator/Makefile
    A lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string/simulator/TestDataFormatterLibcxxStringSimulator.py
    A lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string/simulator/main.cpp

  Log Message:
  -----------
  [lldb] Add tests which simulate the various std::string layouts

Checking whether a formatter change does not break some of the supported
string layouts is difficult because it requires tracking down and/or
building different versions and build configurations of the library.

The purpose of this patch is to avoid that by providing an in-tree
simulation of the string class. It is a reduced version of the real
string class, obtained by elimitating all non-trivial code, leaving
just the internal data structures used by the data formatter. Different
versions of the class can be simulated through preprocessor defines.

The test (ab)uses the fact that our formatters kick in for any
double-underscore sub-namespace of `std`, so it avoids colliding with
the real string class by declaring the test class in the std::__lldb
namespace.

I do not consider this to be a replacement for the existing data
formatter tests, as producing this kind of a test is not trivial, and it
is easy to make a mistake in the process. However, it's also not
realistic to expect that every person changing the data formatter will
test it against all versions of the real class, so I think it can be
useful as a first line of defence.

Adding support for new layouts can become particularly unwieldy, but
this complexity will also be reflected in the actual code, so if we find
ourselves needing to support too many variants, we may need to start
dropping support for old ones, or come up with a completely different
strategy.

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


Compare: https://github.com/llvm/llvm-project/compare/c0702ac07b8e...b6b65403b382