Then you should be able to have a ".lldbinit-hexagon-lldb" file that will get sourced. The main questions is if there is a good place to put this file when there are no bundles on linux or windows. On LLDB, the LLDB.framework contains everything we need (headers, resources, support binaries (debugserver, lldb-gdbserver lldb-platform, darwin-debug, and more) and the lldb python modules.
Maybe we can start paving the way for bundles on windows and linux with LLDB? Greg > On Jan 28, 2015, at 11:54 AM, Ted Woodward <[email protected]> > wrote: > > All the llvm tools in our installation have "hexagon-" prepended too them, so > lldb is really hexagon-lldb. > > Right now we use a wrapper script that looks something like this: > > DIR=$(dirname $0) > export PYTHONHOME=$DIR/.. > exec $DIR/hexagon-lldb-3.5.0 -o "command script import $DIR/hexagon_utils.py" > "$@" > > I'd like to replace the '-o "command script import $DIR/hexagon_utils.py"' > with something that gets loaded automatically, so I can set PYTHONHOME and > just run hexagon-lldb-3.5.0 and get my utility scripts. I can do this with > custom drivers (1 for lldb, 1 for lldb-mi), but I'd hoped to stay as close to > the upstream code as possible. > > -- > Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Wednesday, January 28, 2015 1:40 PM > To: Zachary Turner > Cc: Ted Woodward; [email protected] > Subject: Re: [lldb-dev] Global lldbinit file? > > First off, the fact that git does something at the user-interface level seems > rather an argument against doing it that for... > > But also, in git's case it makes some sense to have global configurations, > for instance to implement policies for everybody on a team, or something like > that. But I don't see that strong a use case for that for lldb. Plus, the > particular instance seems another counter-argument, since as I understand it > the Hexagon init is going to change the behavior of lldb significantly. I > would rather if that happen I know this is not vanilla lldb, because it is > called "lldb-hex" or something... > > Jim > >> On Jan 28, 2015, at 11:27 AM, Zachary Turner <[email protected]> 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 <[email protected]> >> 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: [email protected] [mailto:[email protected]] >> Sent: Wednesday, January 28, 2015 1:12 PM >> To: Ted Woodward >> Cc: [email protected] >> 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 <[email protected]> >>> 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 >>> [email protected] >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> >> >> >> _______________________________________________ >> lldb-dev mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> _______________________________________________ >> lldb-dev mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
