Incorporating LLDB Libraries into Core LLVM Project?

Project Infrastructure LLVM Dev List Archives
1

Greetings!

LLDB contains many useful abstractions (notably inside the Utility and Host
modules) which are not specific to the debugger or its CLI/API. We would
like to move some of these out of the LLDB subproject to use them elsewhere
in LLVM.

There is some overlap with functionality provided by LLVM. For example,
both LLVM
<https://github.com/llvm/llvm-project/blob/646299d183ca72cbafd3a2d64629ce8cb3fcdd9d/llvm/lib/Support/Timer.cpp&gt;
and LLDB
<https://github.com/llvm/llvm-project/blob/d480f968ad8b56d3ee4a6b6df5532d485b0ad01e/lldb/include/lldb/Utility/Timer.h&gt;
implement a Timer class. We would like for LLVM projects to make use of the
support libraries of LLDB, without requiring a large undertaking to
deduplicate and generalize all the overlapping functionality. Therefore we
would only move a few desirable components that are unique to LLDB.

As motivating examples:

2

Hello Noah, everyone,

first off, let me say that I think that having some kind of a socket library in llvm is a great idea.

/However/, I have doubts whether this library should take the form of lldb's Socket classes, or even if it can be obtained by transforming/refactoring them. LLDB has a very different standards when it comes to testing, code quality, and general coding style than the llvm core. If this code was judged by the standards for new llvm contributions, it wouldn't stand a chance of being accepted (it might not even be accepted by current lldb standards, as those have evolved over the years).

So, I am wondering, if instead of going the clang/flang route, it might not be better to use the json library as an example. Back when the idea of a json library was first proposed, there were also suggestions to reuse/move the preexisting library in lldb. This idea was eventually rejected due to code quality concerns. A new (much better) json library was added to llvm instead, and in due time the lldb library was deleted in favor of the llvm one.

My impression is that a similar approach would result in a higher quality product, and make sure it fits in well with the rest of the llvm libraries. I'd be happy to help with the migration of lldb to this new implementation.

regards,
Pavel