[lldb-dev] Global lldbinit file?

Zachary Turner zturner at google.com
Wed Jan 28 11:29:48 PST 2015


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 <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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150128/9685ccd2/attachment.html>


More information about the lldb-dev mailing list