Closed Bug 1282184 Opened 5 years ago Closed 5 years ago

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

Categories

(Firefox Build System :: Mach Core, enhancement)

enhancement
Not set
normal

Tracking

(firefox50 fixed)

RESOLVED FIXED
mozilla50
Tracking Status
firefox50 --- fixed

People

(Reporter: erahm, Assigned: erahm)

Details

Attachments

(1 file)

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
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.
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
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.
Attachment #8765659 - Flags: review?(ted)
Assignee: nobody → erahm
Status: NEW → ASSIGNED
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).
Attachment #8765659 - Flags: review?(ted) → review+
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)
https://hg.mozilla.org/integration/mozilla-inbound/rev/14663c45b49b8998e61c22c489357424948cfe6d
Bug 1282184 - Use lldb from Xcode install rather than system install if possible. r=ted
(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?
(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.
Depends on: 1282980
No longer depends on: 1282980
https://hg.mozilla.org/mozilla-central/rev/14663c45b49b
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.