That's not so bad, though I don't think putting config files in the bin directory is going to be a very popular thing to do. But I still feel that this ends up being a very opaque way to change the behavior of lldb. If the changes are trivial, then the benefit of doing this doesn't seem worth the potential confusion, and if they are significant, then it seems to me better to make a special-purpose driver, so that I know the thing I'm invoking is NOT going to behave the way lldb normally behaves.
Jim > On Jan 28, 2015, at 11:17 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
