We have a need (and it is my understanding that we’re not the only one) to tweak the default configuration of lldb in order to ensure it interacts well with our internal tools. We would like to do so in a way that is supported upstream. I am not aware of any mechanism that would allow us to do that (if there is one, please let me know). For that reason, I would like to propose a new feature: a system-wide lldbinit file.
Unlike $HOME/.lldbinit, which is specific to one user, this file would live in a central location, and would be shared by all users. It would be automatically sourced by lldb (unless –no-lldbinit is given) upon startup. This would happen before $HOME/.lldbinit (and $PWD/.lldbinit) processing, to give the user a chance to override any unwanted settings. I propose to have the location of the file be configurable at build time, via a cmake option, say LLDB_SYSTEMWIDE_INIT_LOCATION.
If the variable is set to an absolute path (e.g. /etc/lldb/lldbinit), then the file would be searched in that location. This setup could be suitable for e.g. linux distributions (our distribution model is similar) to package an extra lldbinit file to configure lldb (for example, to set split debug file search paths) to match their setup. Relative paths would be interpreted relative to the location of (lib)lldb. This model may be suitable for “independent” distribution channels, where one gives the user a zip file containing a build of lldb (perhaps together with some SDK), and an lldbinit file which configures it to make use of the files inside that SDK. Setting the variable to an empty string would disable the feature altogether.
In case anyone is wondering, gdb also has a similar capability, but it is more featureful – in addition to a file, one can also specify directory, and all files in that directory will be automatically executed, depending on the extension (python files, gdb command scripts, …). I’m not proposing anything like that here, as it’s not needed for my use case, and the functionality can be emulated with a bit of python scripting.
Due to the system-wide scope of the feature, writing automated tests for it is going to be very tricky. If the file location is relative, then we could theoretically write a test that copies the entire lldb installation to a temp folder, adds an init file, and then checks that it got executed, but such a test would be pretty ugly. Therefore I propose to skip an end-to-end test for the feature. If there are some bits that could be tested at a lower level, then we could handle that with a unit test, but I am hoping that it will be possible to reuse the existing file sourcing machinery to make this work, and that the entire feature will almost be a “one liner”.
Let me know what you think,