Figure out how Xcode can be made to use the in-tree .lldbinit



5 years ago
6 months ago


(Reporter: jwatt, Unassigned)



Firefox Tracking Flags

(Not tracked)




5 years ago
+++ This bug was initially created as a clone of Bug #941539 +++

Bug 941539 added a .lldbinit file to topsrcdir that the build system also installs to the bin directory. Unfortunately Xcode does not read either of these .lldbinit files for some reason. Here are some points of note:

The man page says "Third, an .lldbinit file in the current working directory (where lldb is started) will be read."

If you start lldb from the command line from the topsrcdir or from the bin directory then the in-tree .lldbinit is correctly read by lldb, so this seems to be true.

So it seems that getting Xcode to read the in-tree .lldbinit should be as simple as getting Xcode to use topsrcdir or the bin directory as the current working directory when it gets lldb to start the app for debugging. So I tried setting the absolute path to the topsrcdir in "Use Custom Working Directory" in the "Options" in the "Run" panel under "Project" > "Scheme" > "Edit Scheme...". That doesn't seem to work though because if I start a debugging session with Xcode, pause, and type:

  (lldb) script import os; print os.getcwd()

it simply prints "/" which seems to indicate that the path set for "Use Custom Working Directory" is being ignored (at least in Xcode 5.0.1).

I also tried putting the .lldbinit in the root directory, given the output from the command above, but the lldb started by Xcode is still not picking it up. :/

Comment 1

5 years ago
Can you check to see if XCode is passing either -x or --no-lldbinit to lldb? <>  You should be able to replace lldb with a simple bash script which dumps out its cmdline arguments somewhere...

Comment 2

5 years ago
(I don't have XCode 5 myself, otherwise I would be happy to do this!)

Comment 3

5 years ago
Xcode doesn't invoke lldb via a shell. It dynamically links in the lldb binary, so I'm not sure how to determine this. I'll see if I can figure something out next week.

Comment 4

5 years ago
(In reply to Jonathan Watt [:jwatt] from comment #3)
> Xcode doesn't invoke lldb via a shell. It dynamically links in the lldb
> binary, so I'm not sure how to determine this. I'll see if I can figure
> something out next week.

Yeah ok then that's the reason.  As far as I can see, the .lldbinit file is read through lldb's driver (see the code in tools/driver/Driver.cpp) before it tries to parse other command line arguments.  In other words, anything that doesn't go through the driver (which liblldb won't) will not honor .lldbinit.

Comment 5

5 years ago
Googling around a bit, it looks like some versions of XCode use a ~/.lldbinit-Xcode file.  Can you try that please?

Comment 6

5 years ago
Hmm, there is also some code in source/Interpreter/CommandInterpreter.cpp which should be in liblldb which tries to read ~/.lldbinit-ProgramName or otherwise ~/.lldbinit...

Comment 7

4 years ago
~/.lldbinit works for me in Xcode 5.1.  You probably have a typo in your .lldbinit file, which seem to cause lldb to silently ignore the file when running in Xcode.  Try launching lldb directly from the command line, and see if that gives you some useful error message.

Otherwise it's time to bsearch your file to see what's causing the error... blah.

Comment 8

4 years ago
I'm not sure why we started talking about HOME dir .lldbinit. The fact that Xcode initiated lldb reads that file doesn't help resolve my primary concern, which is that the fix for bug 941539 doesn't actually help avoid dev frustration if they first have to trip over the issue described there and take action. I wanted to find a way to make sure the in-tree .lldbinit is picked up by Xcode debug sessions without them having to take action so that they never encounter that issue.

Comment 9

3 years ago
To import the Mozilla .lldbinit that comes from the source tree that was built to create the Mozilla executable we would need something like the following in $HOME/.lldbinit

Comment 10

3 years ago
# Start import of Mozilla utilities and settings:
# We enter the Python interactive interpreter here. That makes it possible to
# use multi-statement if-else and multi-line functions scope polution by using def and makes it possible to
# if-else, but unfortunately it will write a bunch of ">>>" sequences to
# stdout.
import os, sys
  (exedir, exename) = os.path.split(
  if exename in ["firefox"]:
    objdir = exedir
    while objdir != "/" and not os.path.exists(os.path.join(objdir, "config.status")): objdir = os.path.dirname(objdir)
    if objdir != "/":
      def gettopsrcdir(objdir): # using a function to avoid scope polution
        config = os.path.join(objdir, "config.status")
        exec("__file__ = '" + config + "'\n" + (open(config).read()))
        globals()["topsrcdir"] = topsrcdir

# This exit MUST be proceeded by a blank line to exit the interactive
# interpreter

Comment 11

3 years ago
However, given how messy that is and the unfortunate side effect that it prints some distracting ">>>" and other crap, it's probably best to stick with the fallbacktopsrcdir approach detailed on:

That's probably good enough for everyone.

Given that, probably we should just WONTFIX this.
Last Resolved: 3 years ago
Resolution: --- → WONTFIX

Comment 12

3 years ago
BTW I recently updated the commands for $HOME/.lldbinit detailed on that MDN page to avoid double importing of the Mozilla .lldbinit under some circumstances.


6 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.