This is an archive of the discontinued LLVM Phabricator instance.

Add a .lldbinit file to autoload LLVM/Clang data formatters
Needs ReviewPublic

Authored by arichardson on Jan 8 2023, 2:38 AM.

Details

Reviewers
None
Group Reviewers
Restricted Project
Summary

This makes it much easier to debug LLVM/Clang when using an IDE such as
CLion that defaults to using the project root directory as the CWD for
run targets and therefore allows for this file to be loaded. The only
thing that needs to be configured manually is setting
settings set target.load-cwd-lldbinit true in ~/.lldbinit

Diff Detail

Event Timeline

arichardson created this revision.Jan 8 2023, 2:38 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 8 2023, 2:38 AM
arichardson requested review of this revision.Jan 8 2023, 2:38 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 8 2023, 2:38 AM
mib added a subscriber: mib.Jan 9 2023, 9:36 PM

I guess we could even throw MLIR formatters in there for completeness

.lldbinit
2–3
mib added a subscriber: mehdi_amini.Jan 9 2023, 9:41 PM

I guess we could even throw MLIR formatters in there for completeness

I don't know exactly how well those are maintained ... @mehdi_amini do you think it would be safe to add these here ?

jingham added a subscriber: jingham.EditedJan 10 2023, 3:13 PM

I've been holding off on actually promoting the lldbDataFormatters until there was some tests written for these formatters. llvm data structures are constantly changing and so formatters in these files often break. It shouldn't be hard to build a little test executable that links to llvm or clang and makes structures of these types and makes sure the formatted results are correct.

But even so, the idea of leaving .lldbinit files lying around in really common places like the root of the llvm-project source directory gives me the willies... It's not so bad since by default we won't use this, but then the suggestion for using this is to turn on the target.load-cwd-lldbinit setting in ~/.lldbinit, and given how we see people cargo-cult .lldbinit files, I think this is likely to cause confusion.

Also for anyone not using CLion, having the local .lldbinit file in the root directory is not all that helpful, you'd really want it to be copied into the bin directory of your build, since most people when debugging their new binaries cd to the bin directory and run it from there. I'd suggest having it in some suitable subdirectory, and then have the build system copy it to the useful location, which for CLion would be the project root and for anything else would be the bin directory.

IMO the correct solution to this problem is for the IDE to give affordances for specifying either absolute or project relative paths to "the debugger init file". Then we don't have to clutter our sources with .lldbinit files in weird places hoping to catch the attention of one IDE or another.