[LLDB] Fix lldb plug-ins isolation to reduce lldb-server size

[slydiman]

I'm trying to reduce the size of lldb-server binary.
The size of lldb-server binary for Aarch64 (release) is about 42MB.
I have analyzed the code and found a lot of x86, PDB, MIPS and Darwin related code.
Many "lldb plug-ins" are not plug-ins, but libraries used by other plug-ins.
See ac1ea0d

1. It is necessary to review and isolate plug-ins more accurately.
   llvm-project/lldb/tools/lldb-server/SystemInitializerLLGS.cpp includes only necessary plug-ins, but it is not enough.
   For example, llvm-project/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp uses PDB code in
   PDBASTParser *TypeSystemClang::GetPDBParser() and npdb::PdbAstBuilder *TypeSystemClang::GetNativePDBParser().
   That's why Aarch64 lldb-server binary contains unwanted x86 and PDB code.
   I'm trying to figure out how to disable some plug-ins (with loss of some functionality) to reduce the size of lldb-server binary. But they have a lot of cross-dependencies.
   PlatformPOSIX::DoLoadImage() uses TypeSystemClang directly, etc.

2. A lot of unwanted code is used directly in the base LLVM code and cannot be disabled in lldb.
   For example ms_demangler is used in llvm-project/llvm/lib/Demangle/Demangle.cpp
   Currently I have no solution how to remove such unwanted code except by using local patches.

Any thoughts are welcome.

[llvmbot]

@llvm/issue-subscribers-lldb

Author: Dmitry Vasilyev (slydiman)

I'm trying to reduce the size of lldb-server binary. The size of lldb-server binary for Aarch64 (release) is about 42MB. I have analyzed the code and found a lot of x86, PDB, MIPS and Denwer related code. Many "lldb plug-ins" are not plug-ins, but libraries used by other plug-ins. See https://github.com/llvm/llvm-project/commit/ac1ea0d3da1ef620a392d2e22a38c03bd844383b

1. It is necessary to review and isolate plug-ins more accurately.
   llvm-project/lldb/tools/lldb-server/SystemInitializerLLGS.cpp includes only necessary plug-ins, but it is not enough.
   For example, llvm-project/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp uses PDB code in
   PDBASTParser *TypeSystemClang::GetPDBParser() and npdb::PdbAstBuilder *TypeSystemClang::GetNativePDBParser().
   That's why Aarch64 lldb-server binary contains unwanted x86 and PDB code.
   I'm trying to figure out how to disable some plug-ins (with loss of some functionality) to reduce the size of lldb-server binary. But they have a lot of cross-dependencies.
   PlatformPOSIX::DoLoadImage() uses TypeSystemClang directly, etc.

2. A lot of unwanted code is used directly in the base LLVM code and cannot be disabled in lldb.
   For example ms_demangler is used in llvm-project/llvm/lib/Demangle/Demangle.cpp
   Currently I have no solution how to remove such unwanted code except by using local patches.

Any thoughts are welcome.

[slydiman]

The base size of lldb-server (Linux, Aarch64) is about 6MB.

+0.1KB ClangREPL plug-in

+1.7KB lldb/source/Expression/IRExecutionUnit.cpp

+10KB
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp uses PDB directly (can be removed):
std::unique_ptr m_pdb_ast_parser_up;
std::unique_ptrnpdb::PdbAstBuilder m_native_pdb_ast_parser_up;

+98KB llvm::DWARFExpression() used in lldb/source/Expression/DWARFExpression.cpp

+223KB GDBRemoteCommunicationServerLLGS class used in lldb/tools/lldb-server/lldb-gdbserver.cpp

+312KB GDBRemoteCommunicationServerPlatform class used in lldb/tools/lldb-server/lldb-platform.cpp

+194KB EmulateInstructionARM plug-in used in lldb/tools/lldb-server/SystemInitializerLLGS.cpp

+306KB ObjectFileELF plug-in used in lldb/tools/lldb-server/SystemInitializerLLGS.cpp

+609KB NativeProcessLinux plug-in used in lldb/tools/lldb-server/lldb-gdbserver.cpp

+5MB lldbPluginExpressionParserClang lib (not plug-in!) used in lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp in the following functions:
UserExpression *ScratchTypeSystemClang::GetUserExpression()
FunctionCaller *ScratchTypeSystemClang::GetFunctionCaller()
std::unique_ptr ScratchTypeSystemClang::CreateUtilityFunction()

+32MB lldbPluginSymbolFileDWARF lib (not plug-in!), including

+1979KB llvm/DebugInfo/DWARF
+549KB DWO
+23KB AppleDWARFIndex
+30MB DWARFASTParserClang

The size of lldb-server w/o lldbPluginExpressionParserClang and lldbPluginSymbolFileDWARF is about 8MB.
The full size of lldb-server is about 42MB.

DWARFASTParserClang is biggest. It is linked in TypeSystemClang.cpp together with PDB parsers and in SymbolFileDWARF::CompleteType().

It seems we need to refactor

1. SymbolFileDWARF to be able to disable DWARFASTParserClang usage.

2. TypeSystemClang to be able to disable importers m_dwarf_ast_parser_up, m_pdb_ast_parser_up and m_native_pdb_ast_parser_up.

3. TypeSystemClang to be able to disable lldbPluginExpressionParserClang usage.

[da-viper]

+98KB llvm::DWARFExpression() used in lldb/source/Expression/DWARFExpression.cpp

+223KB GDBRemoteCommunicationServerLLGS class used in lldb/tools/lldb-server/lldb-gdbserver.cpp

+312KB GDBRemoteCommunicationServerPlatform class used in lldb/tools/lldb-server/lldb-platform.cpp

@slydiman This information what application/ package did you use to get this ?

[labath]

It seems we need to refactor

1. SymbolFileDWARF to be able to disable DWARFASTParserClang usage.

2. TypeSystemClang to be able to disable importers `m_dwarf_ast_parser_up`, `m_pdb_ast_parser_up` and `m_native_pdb_ast_parser_up`.

3. TypeSystemClang to be able to disable lldbPluginExpressionParserClang usage.

The problem is much higher up. None of these classes (SymbolFileDWARF, TypeSystemClang) should actually be a part of lldb-server.

[da-viper]

Sorry, for not clarifying. I wanted to inspect another binary to see the size based on the compilation unit. So I wanted to know what tool used to get that output

[JDevlieghere]

CC @bulbazord who worked on reducing the size of lldb-server in the past.

[slydiman]

Sorry, for not clarifying. I wanted to inspect another binary to see the size based on the compilation unit. So I wanted to know what tool used to get that output

I used own mocks to temporary disable some code, recompiled and compared the size of the binary manually.

For example, you can update TypeSystemClang.cpp with the following code

DWARFASTParser *TypeSystemClang::GetDWARFParser() {
  return nullptr;
}

PDBASTParser *TypeSystemClang::GetPDBParser() {
  return nullptr;
}

npdb::PdbAstBuilder *TypeSystemClang::GetNativePDBParser() {
  return nullptr;
}

bool TypeSystemClang::LayoutRecordType(
    const clang::RecordDecl *record_decl, uint64_t &bit_size, uint64_t &alignment,
    llvm::DenseMap<const clang::FieldDecl *, uint64_t> &field_offsets,
    llvm::DenseMap<const clang::CXXRecordDecl *, clang::CharUnits> &base_offsets,
    llvm::DenseMap<const clang::CXXRecordDecl *, clang::CharUnits> &vbase_offsets) {
  return false;
}

UserExpression *ScratchTypeSystemClang::GetUserExpression(
    llvm::StringRef expr, llvm::StringRef prefix, SourceLanguage language,
    Expression::ResultType desired_type,
    const EvaluateExpressionOptions &options, ValueObject *ctx_obj) {
  return nullptr;
}

FunctionCaller *ScratchTypeSystemClang::GetFunctionCaller(
    const CompilerType &return_type, const Address &function_address,
    const ValueList &arg_value_list, const char *name) {
  return nullptr;
}

std::unique_ptr<UtilityFunction>
ScratchTypeSystemClang::CreateUtilityFunction(std::string text, std::string name) {
  return {};
}

and SymbolFileDWARF.cpp with the following code

bool SymbolFileDWARF::CompleteType(CompilerType &compiler_type) {
  std::lock_guard<std::recursive_mutex> guard(GetModuleMutex());
/*
  auto clang_type_system = compiler_type.GetTypeSystem().dyn_cast_or_null<TypeSystemClang>();
  if (clang_type_system) {
    DWARFASTParserClang *ast_parser = static_cast<DWARFASTParserClang *>(clang_type_system->GetDWARFParser());
    if (ast_parser &&
        ast_parser->GetClangASTImporter().CanImport(compiler_type))
      return ast_parser->GetClangASTImporter().CompleteType(compiler_type);
  }
*/
...

to reduce the size of lldb-server binary from 42MB to 10MB.

[slydiman]

The problem is much higher up. None of these classes (SymbolFileDWARF, TypeSystemClang) should actually be a part of lldb-server.

Agreed. But these classes are not plugins. They are libs which are used directly in many places.

[slydiman]

A was able to get the same 10MB lldb-server replacing TypeSystemClang.cpp with the following mock

#include "TypeSystemClang.h"
using namespace lldb;
using namespace lldb_private;
char TypeSystemClang::ID;

and replacing autogenerated Plugins.def with the following code

#ifndef LLDB_SCRIPT_PLUGIN
#define LLDB_SCRIPT_PLUGIN(p) LLDB_PLUGIN(p)
#endif

LLDB_PLUGIN(ProcessGDBRemote)

#undef LLDB_PLUGIN
#undef LLDB_SCRIPT_PLUGIN

Note TypeSystemClang::ID is used in ClangUtil::IsClangType() which is called in many places.

But SymbolFileDWARF is still there because a lot of DWARFUnit methods are used in lldb/source/Expression/DWARFExpression.cpp

Probably we can use an interface instead of the class DWARFUnit in DWARFExpression.cpp to fix this issue.

And it seems DW_OP_value_to_name() can be moved from lldb/source/Plugins/SymbolFile/DWARF/DWARFDefines.cpp to lldb/source/Expression/DWARFExpression.cpp because it is only used there.

[slydiman]

lldb-server contains its own SystemInitializerLLGS inherited from SystemInitializerCommon.
Good question - why does lldb-server depend on SystemInitializerFull and Plugins.def?

SystemInitializerFull is used in lldb/source/API/SBDebugger.cpp in SBDebugger::InitializeWithErrorHandling().
Any suggestions how to remove this dependency?

[labath]

lldb-server contains its own SystemInitializerLLGS inherited from SystemInitializerCommon. Good question - why does lldb-server depend on SystemInitializerFull and Plugins.def?

That's definitely unexpected. The main reason why SystemInitializerFull exists is so that lldb-server does not need to depend on it (and transitively, the whole world).

SystemInitializerFull is used in lldb/source/API/SBDebugger.cpp in SBDebugger::InitializeWithErrorHandling(). Any suggestions how to remove this dependency?

I don't know. What causes that dependency? (I don't see anything at a first glance)