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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
