Actually after a quick glance at the code, maybe it already does something like this? I hadn't really dug into the way .lldbinit works before.
On Wed Jan 28 2015 at 11:27:26 AM Zachary Turner <ztur...@google.com> wrote: > Personally I'm a big fan of this model. Sort of like what git does, where > you have different install files in different scopes, and it starts by > parsing the global config first, then the user-level config, then the local > config, overwriting values in the process. > > So in Ted's scenario, for example, maybe lldb could load ~/.lldbinit > first, then look in the same folder as the executable for a .lldbinit and > load it second. > > On Wed Jan 28 2015 at 11:21:13 AM Ted Woodward < > ted.woodw...@codeaurora.org> wrote: > >> I'm sorry; I wasn't clear. When I say "global", I mean "global to this >> installation", not "global to the system". >> >> My idea was something like /inst/hexagon/Tools/bin/lldb would load >> /inst/hexagon/Tools/bin/lldbinit. Another lldb installation, say >> /inst/Xcode/bin/lldb, wouldn't see it, or be affected by it. >> >> -- >> Qualcomm Innovation Center, Inc. >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a >> Linux Foundation Collaborative Project >> >> -----Original Message----- >> From: jing...@apple.com [mailto:jing...@apple.com] >> Sent: Wednesday, January 28, 2015 1:12 PM >> To: Ted Woodward >> Cc: lldb-dev@cs.uiuc.edu >> Subject: Re: [lldb-dev] Global lldbinit file? >> >> This worries me a little bit. I install your Hexagon lldb, and that >> installs a global lldbinit, which then starts affecting my use of the other >> lldb's I happen to have on my system in ways that are not at all clear to >> me... That doesn't seem like a good idea to me. >> >> gdb had a global configuration file in /etc/conf, and Apple's gdb >> installation used it for a few things (this was actually done at NeXT and >> NOT by me...) - mainly setting some common print variables. But this just >> ended up causing more confusion than it was worth. It would have been >> better to just bake these into the gdb driver we shipped... >> >> I would suggest distributing your lldb as lldb-hex or something like >> that, and including a template .lldbinit-hex that folks could install, or >> making your own driver that sets the options you want first. >> >> Jim >> >> >> >> >> >> > On Jan 28, 2015, at 9:40 AM, Ted Woodward <ted.woodw...@codeaurora.org> >> wrote: >> > >> > >> > When LLDB launches, it will read ~/.lldbinit (and possibly other >> variants of that, like ~/.lldbinit-Xcode). >> > >> > In my Hexagon LLDB installation, I want LLDB to always load a global >> lldbinit file. Currently I do this by having lldb be a wrapper script that >> calls lldb with –o, but I’d like to eliminate the wrapper script, since >> wrapper batch files cause problems with ctrl-c handling on Windows. I use >> this to load a python file with utilities in it, like one to get the TLB >> info from the target. It sends a qXfer command to the remote GDB server to >> download an XML file, parses it, and prints the info from it. These >> utilities need to load for all users. >> > >> > Do we have a global lldbinit file, or should I add code to load >> Host::GetProgramFileSpec()/lldbinit? >> > >> > -- >> > Qualcomm Innovation Center, Inc. >> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, >> a Linux Foundation Collaborative Project >> > >> > _______________________________________________ >> > lldb-dev mailing list >> > lldb-dev@cs.uiuc.edu >> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> >> >> >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
