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

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[Jonathan Watt [:jwatt]]

+++ 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. :/

Comment 1

[(no longer active)]

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...

Comment 2

[(no longer active)]

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

Comment 3

[Jonathan Watt [:jwatt]]

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

[(no longer active)]

(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

[(no longer active)]

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

Comment 6

[(no longer active)]

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

[jonah]

~/.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

[Jonathan Watt [:jwatt]]

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

[Jonathan Watt [:jwatt]]

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

[Jonathan Watt [:jwatt]]

# 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

Comment 11

[Jonathan Watt [:jwatt]]

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.

Comment 12

[Jonathan Watt [:jwatt]]

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.