New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No deterministic/easily findable name for debug symbol directory on macOS #4056

golddranks opened this Issue May 16, 2017 · 7 comments


None yet
6 participants

golddranks commented May 16, 2017

I recently attempted to debug a Rust program with LLDB. I was surprised to find out that LLDB wouldn't find the debug symbols, even I had been sure to compile them in.

The problem was that on macOS, the debug symbols are stored in a directory that is separate from the binary. This directory has an extension .dSYM. (To be sure, there is also symbol table compiled in the binary, and LLDB was able to show stack traces because of this.), This .dSYM directory was produced in the build, but it's stored in target/debug/deps/ instead of target/debug/. Therefore, debuggingtarget/debug/$BINARY_NAME with LLDB caused LLDB not to find the debug symbols.

This is a problem, since it's surprising; I, and I bet that many others too, expect to be able to debug the main build artefact of a debug build. Many don't necessarily find the "debuggable" binary in the subdirectory.

There's a second problem too: using VS Code, I can modify the settings of the Launch debugger command. I can set the binary name that is going to be debugged. But the binary in the directory target/debug/deps/ doesn't have a deterministic name, because of the hash appended to the name (which is of course the point there...). One could argue that being not able to set a glob filename for the debugging command is just a shortcoming of VS Code, but I think that there should also be a deterministically named debuggable binary.

The easy fix, of course, is to create a .dSYM directory in target/debug/ too, corresponding to the binary there.


This comment has been minimized.


retep998 commented May 16, 2017

Note that this is also an issue on Windows where the .pdb file takes after the name of the .exe which has a hash in its name, so the .pdb does as well.


This comment has been minimized.


golddranks commented May 16, 2017

Curiously, my friend doesn't seem to have this problem, and actually my another Mac works too.

I've had some problem with debug info before with this computer: Edit: Oops, it was another computer! rust-lang-nursery/error-chain#129 (comment) (I had hard time to make dtrace to find the debug symbols too: Edit: This was with the same computer. )

However, the computer is almost new (unboxed just a few weeks ago) and I haven't installed anything significant to it, which suggests that it's not about just messing with the settings.

My friend suggested that it might be that an antivirus program or something is messing with things. (It's a work computer, and I'm not allowed to uninstall the thing.)

Anyway, it seems that on some Macs, the debug tools have no problems finding the debug info, and in my case, there's some problems. But the problems go away if you have the debug info in the same folder.


This comment has been minimized.


waywardmonkeys commented May 24, 2017

@golddranks For the machines where it works, is that because SpotLight is indexing the folders involved and on the machines where it doesn't work, SpotLight is not indexing?


This comment has been minimized.


alexcrichton commented May 30, 2017

I actually just commented on what I think is a very related issue. @golddranks mind peeking at that and giving your thoughts about that? Specifically, is it acceptable to not lift up the *.dSYM folder from deps/ up one level? (but assume that we can drop the "weird" hash at the end)


This comment has been minimized.


golddranks commented Jun 2, 2017

Okay, the mystery why LLDB was unable to find the debug symbols is now solved. Indeed, like @waywardmonkeys said, my "repos" folder was in the "folders excluded from Spotlight search" on the "Privacy" tab of Spotlight settings. I haven't got a slightest idea why it was there.

Like @alexcrichton asked in the comment above, I also tested if it was able to find the symbols, if they were in the deps folder but with the same name as the main executable. It could'n find the symbols when the directory was excluded from the Spotlight search.

Long story short: if Spotlight works flawlessly, the debug symbols will be found. If it doesn't, it won't find the symbols, unless they are in the same directory, and with the same name as the binary.

However, one more thing: I also experienced some lag for them to be found. (For example, when printing a debug trace of a freshly produced binary, it wouldn't show all the info when running for the first time, but only after some seconds (or even tens of seconds) after the first run. This is described in detail here: rust-lang-nursery/error-chain#129 (comment) )

I don't think the situation is desirable even if the specific problem I had was solved. The debug symbol finding mechanism depends on Spotlight, which I find unreliable and magical.

@kennytm kennytm referenced this issue Oct 13, 2017


Uplift *.dSYM #4616

bors added a commit that referenced this issue Oct 14, 2017

Auto merge of #4616 - kennytm:fix-4490, r=alexcrichton
Uplift *.dSYM

Fixed #4490.

The solution is based on #4570. Simply adding `.dSYM` into `add_target_specific_suffixes` will cause cargo trying to actually run that `.dSYM` folder, so I've upgraded the `linkable` boolean into a 3-value enum `TargetFileType`, to tell `cargo run` and `cargo test` to avoid these debug symbol files.

(I haven't checked if it can solve #4056, don't wanna mess with Spotlight 😝)

This comment has been minimized.

huoyuanliao commented Nov 6, 2017

Hi, I also came up with this issue: when cargo build hello_world example. then
gdb ../target/debug/hello_world ,and enter the gdb command line, typing b hello_world::main with complain: Function "hello_world::main" not defined. does anyone who meet the same situation as me?
I've copy the dSYM directory to target/debug/ but nothing help.


This comment has been minimized.


alexcrichton commented Feb 24, 2018

I believe these issues have since been fixed, so closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment