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

[golddranks]

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.

[retep998]

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.

[golddranks]

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-deprecated/error-chain#129 (comment) (I had hard time to make dtrace to find the debug symbols too: Edit: This was with the same computer. http://stackoverflow.com/questions/43469047/using-dtrace-to-get-stack-traces-profiling-data-on-rust )

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.

[waywardmonkeys]

@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?

[alexcrichton]

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)

[golddranks]

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