[lldb-dev] Global lldbinit file?

Wed Jan 28 12:00:32 PST 2015

If this is for the PYTHONHOME stuff, then could we solve this in a way
similar to what I suggested on IRC?  Basically, for Windows specifically,
we either assume that python is installed into a specific location relative
to the lldb executable, or look for an environment variable like
LLDB_PYTHON_LOCATION  (different from PYTHONHOME since that would be used
by other installed versions of python as well).

On Wed Jan 28 2015 at 11:55:02 AM Ted Woodward <ted.woodward at codeaurora.org>
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: jingham at apple.com [mailto:jingham at apple.com]
> Sent: Wednesday, January 28, 2015 1:40 PM
> To: Zachary Turner
> Cc: Ted Woodward; lldb-dev at cs.uiuc.edu
> 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 <zturner at 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.woodward at 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: jingham at apple.com [mailto:jingham at apple.com]
> > Sent: Wednesday, January 28, 2015 1:12 PM
> > To: Ted Woodward
> > Cc: lldb-dev at 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.woodward at 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 at cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
> >
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150128/c4afc644/attachment.html>