1282184 - DMD does not work with |mach run| and debug on OSX

Status: RESOLVED FIXED

(Firefox Build System :: Mach Core, enhancement)

Description

[Eric Rahm [:erahm]]

Running: |mach run --debug --dmd| launches lldb on OSX but does not enable DMD. The best I can tell the env vars are not being forwarded to lldb (or perhaps lldb is not forwarding them to firefox).

I used the following in lldb as a work-around:
> settings set target.env-vars DYLD_INSERT_LIBRARIES=/Users/ericrahm/dev/mozilla-central/obj-x86_64-apple-darwin15.3.0-debug/dist/NightlyDebug.app/Contents/MacOS/libdmd.dylib LD_LIBRARY_PATH=/Users/ericrahm/dev/mozilla-central/obj-x86_64-apple-darwin15.3.0-debug/dist/NightlyDebug.app/Contents/MacOS DMD="--mode=cumulative"
> process launch

Comment 1

[Eric Rahm [:erahm]]

Looking at the defaults for lldb, the default is to inherit env:
> (lldb) settings show target.inherit-env
> target.inherit-env (boolean) = true

I confirmed this forwards env vars properly, eg: |FOO=BAR lldb a.out| forwards FOO to a.out

So somehow it seems we're not actually setting the dmd vars when using lldb.

Comment 2

[Eric Rahm [:erahm]]

Alright it looks like an issue with System Integrity Protection that was added to OSX 10.11 (maybe 10.10?) prevents us from using |DYLD_LIBRARY_PATH| when trying to run a program under /usr/bin [1]. |lldb| is under /usr/bin. There are a few alternatives:

1) Use lldb from under xcode
2) Provide an lldb setup script that sets the env vars for us

[1] http://stackoverflow.com/a/33589760

Comment 3

[Eric Rahm [:erahm]]

Attachment: Use lldb from Xcode install rather than system install if possible

This works around issues with System Integrity Protection kicking in on OSX when
trying to run /usr/bin/lldb by attempting to using the version installed with
XCode's command line utilities.

In particular SIP prevents us from setting DYLD_LIBRARY_PATH which is needed
to run DMD.

Ted, you were the last reviewer for this code but feel free to redirect.

Comment 4

[(not currently active) Ted Mielczarek]

Comment on attachment 8765659 [details] [diff] [review]
Use lldb from Xcode install rather than system install if possible

Review of attachment 8765659 [details] [diff] [review]:
-----------------------------------------------------------------

Sort of unfortunate that they added these protections but left a copy of lldb in /usr/bin (unless that's just an old version you had lying around).

Comment 5

[Mike Hommey [:glandium]]

We should probably avoid depending on the debugger passing environment variables down, and instead set the environment variable from the debugger itself.
`set env VAR value` in gdb and `settings set target.env-vars VAR=value` in lldb (presumably, `env VAR=value` works too)

Comment 6

[Eric Rahm [:erahm]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/14663c45b49b8998e61c22c489357424948cfe6d
Bug 1282184 - Use lldb from Xcode install rather than system install if possible. r=ted

Comment 7

[Eric Rahm [:erahm]]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #4)
> Comment on attachment 8765659 [details] [diff] [review]
> Use lldb from Xcode install rather than system install if possible
> 
> Review of attachment 8765659 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Sort of unfortunate that they added these protections but left a copy of
> lldb in /usr/bin (unless that's just an old version you had lying around).

The versions are the same (but *not* a symlink), maybe it's for backwards compat?

Comment 8

[Eric Rahm [:erahm]]

(In reply to Mike Hommey [:glandium] from comment #5)
> We should probably avoid depending on the debugger passing environment
> variables down, and instead set the environment variable from the debugger
> itself.
> `set env VAR value` in gdb and `settings set target.env-vars VAR=value` in
> lldb (presumably, `env VAR=value` works too)

That's not a bad idea, but it's not straightforward either. It's roughly what I meant by "Provide an lldb setup script that sets the env vars for us." Seems like a good option for a follow-up if you want to file it, we'd want to support windbg and devenv as well. It would probably require a more elaborate wrapper for a debugger instance (rather than just calling subprocess) that cleans up any temp files needed.

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/14663c45b49b