[Lldb-commits] [PATCH] D119831: [lldb] Add support for a "system-wide" lldbinit file

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D119831#3324830 <https://reviews.llvm.org/D119831#3324830>, @clayborg wrote:

> This looks good to me. Just a few things to possibly think about:
>
> - Maybe we would want addition system init files for different workflows and then we would start lldb with a new option like "lldb --workflow qemu" and it would load the system ".lldbinit-qemu" init file. That way we could have many supported workflows from one distribution. Here at Facebook we would have at least 3 that I know of: "fb-ios", "fb-android" and "fb-server". We would still have a system ".lldbinit" for global settings of course.

You are correctly guessing that this is motivated (at least partially, anyway) by the qemu patchset, but the idea there is to have a plain "lldb" just work. So, I don't think this would be interesting for us right now.

Nonetheless, I do find that idea intriguing. We would need to reconciliate this somehow with the existing concept of application-specific lldbinit files -- I think having both would be too much. Perhaps if we rename the app-specific files to "workflow-specific init files", and have the default workflow be derived from the application name... I don't think this would work right now, as we probably `realpath` everything, but if we avoided that then we could even allow using symlinks to automatically choose different workflows (`ln -s lldb lldb.qemu; ./lldb.qemu` could launch a "qemu" workflow).

(Of course, at that point, one could just make `lldb.qemu` a shell script which effectively does a `exec lldb -S qemu.lldbinit "$@"`, and avoid all this extra infrastructure.)

> - We were currently doing stuff like this in python where it would auto import some of our facebook specific python modules when the debugger starts up, would that be useful as well? It wouldn't really be needed here because we could just "command script import" in the init files

Right now, it looks like all of our setup will be done in python as well, and our lldbinit file will probably consist of a single `command script import --relative-to-command-file` line. Going straight to python would probably make things easier for us, but this seemed to fit in better into the existing lldb feature set.



================
Comment at: lldb/include/lldb/Interpreter/CommandInterpreter.h:256
   void SourceInitFileHome(CommandReturnObject &result, bool is_repl);
+  void SourceSystemInitFile(CommandReturnObject &result);
 
----------------
wallace wrote:
> JDevlieghere wrote:
> > `SourceInitFileSystem` for consistency with the other two? Or maybe you were planning to change the other two in another patch?
> calling it SourceInitFileSystem is a bit confusing. What about using Global instead of System to avoid naming issues?
Yeah, that was the reason why I changed the word order. We can just call it "global" instead.


================
Comment at: lldb/source/Interpreter/CommandInterpreter.cpp:2385-2393
+#ifdef LLDB_SYSTEM_INIT_PATH
+    FileSpec init_file(LLDB_SYSTEM_INIT_PATH);
+    if (init_file) {
+      init_file.MakeAbsolute(HostInfo::GetShlibDir());
+    }
+
+    SourceInitFile(init_file, result);
----------------
JDevlieghere wrote:
> Why not put the ifdef around the `m_skip_lldbinit_files` check?
It just happened to fall out that way. I agree switching the order looks better.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119831/new/

https://reviews.llvm.org/D119831