LLDB has come a long way since the project was first announced. As a robust
debugger for C-family languages and Swift, LLDB is constantly in use by
millions of developers. It has also become a foundation for bringing up
debugger support for other languages like Go and RenderScript. In addition to
the original macOS implementation the Linux LLDB port is in active use and
Windows support has made significant strides. IDE and editor integration via
both SB APIs and MI have made LLDB available to even more users. It’s
definitely a project every contributor can be proud of and I’d like to take a
moment to thank everyone who has been involved in one way or another.
It’s also a project that shows some signs of strain due to its rapid growth.
We’ve accumulated some technical debt that must be paid off, and in general it
seems like a good time to reflect on where we'll be headed next. We’ve
outlined a few goals for discussion below as well as one more short-term
action. Discussion is very much encouraged.
Forward-Looking Goals
1. Testing Strategy Evaluation
Keeping our code base healthy is next to impossible without a robust testing
strategy. Our existing suite of tests is straightforward to run locally, and
serves as a foundation for continuous integration. That said, it is definitely
not exhaustive. Obvious priorities for improvement include gathering coverage
information, investing in more conventional unit tests in addition to the suite
of end-to-end tests, and introducing tests in code bases where we depend on
debugger-specific behavior (e.g.: for expression evaluation.)
2. C++ Module Support
LLDB takes advantage of Clang modules for type information and expression
evaluation. This has been used extensively for C and Objective-C scenarios,
but Clang C++ module support is now mature enough that we can extend our
support accordingly. Fully embracing C++ modules will enable LLDB expressions
to take advantage of template declarations and other constructs that are better
represented by declarations than the artifacts produced during compilation.
3. Establishing Language Integration Standards
As more languages build on LLDB’s foundation the project runs the risk of
growing deep dependencies on a wide variety of compilers and runtimes. The
community needs to engage in a constructive conversation about how best to keep
the core of LLDB clean and allow language support to be plugged in. Whether
this should occur at compile-time or runtime and how best to organize
repositories and branches to meet the needs of our diverse community will be an
ongoing topic of discussion.
4. Good Citizenship in the LLVM Community
Last, but definitely not least, LLDB should endeavor to be a good citizen of
the LLVM community. We should encourage developers to think of the technology
stack as a coherent effort, where common code should be introduced at an
appropriate level in the stack. Opportunities to factor reusable aspects of
the LLDB code base up the stack into LLVM will be pursued.
One arbitrary source of inconsistency at present is LLDB’s coding standard.
That brings us to…
Near-Term Goal: Standardizing on LLVM-style clang-format Rules
We’ve heard from several in the community that would prefer to have a single
code formatting style to further unify the two code bases. Using clang-format
with the default LLVM conventions would simplify code migration, editor
configuration, and coding habits for developers who work in multiple LLVM
projects. There are non-trivial implications to reformatting a code base with
this much history. It can obfuscate history and impact downstream projects by
complicating merges. Ideally, it should be done once with as much advance
notice as is practical. Here’s the timeline we’re proposing:
Today - mechanical reformatting proposed, comment period begins
To get a preview of what straightforward reformatting of the code looks like,
just follow these steps to get a clean copy of the repository and reformat it:
Check out a clean copy of the existing repository
Edit .clang-format in the root of the tree, remove all but the line
“BasedOnStyle: LLVM”
Change your current working directory to the root of the tree to reformat
Double-check to make sure you did step 3 ;-)
Run the following shell command: "find . -name "*.[c,cpp,h] -exec clang-format
-i {} +"
Aug 20th - comment period closes, final schedule proposed
TBD (early September?) - patches land in svn
The purpose of the comment period is to review the straightforward diffs to
identify areas where comment pragmas should be used to avoid undesirable
formatting (tables laid out in code are a classic example.) It’s also a time
when feedback on the final timetable can be discussed, and any unforeseen
implications can be discovered. We understand that LLDB tends toward
relatively long names that may not always work well with the LLVM convention of
wrapping at 80 columns. Worst case scenarios will be evaluated to determine
the desired course of action.
Kate Stone k8st...@apple.com <mailto:k8st...@apple.com>
Xcode Low Level Tools
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
