+++ 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." http://www.manpagez.com/man/1/lldb/ 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. :/
Can you check to see if XCode is passing either -x or --no-lldbinit to lldb? <https://github.com/llvm-mirror/lldb/blob/master/tools/driver/Driver.cpp#L110> You should be able to replace lldb with a simple bash script which dumps out its cmdline arguments somewhere...
(I don't have XCode 5 myself, otherwise I would be happy to do this!)
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.
(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.
Googling around a bit, it looks like some versions of XCode use a ~/.lldbinit-Xcode file. Can you try that please?
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...
~/.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.
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.
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
# 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. script import os, sys if lldb.target: (exedir, exename) = os.path.split(lldb.target.executable.fullpath) 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 gettopsrcdir(objdir) # This exit MUST be proceeded by a blank line to exit the interactive # interpreter exit
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: https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_on_Mac_OS_X That's probably good enough for everyone. Given that, probably we should just WONTFIX this.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
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.
You need to log in before you can comment on or make changes to this bug.