No deterministic/easily findable name for debug symbol directory on macOS #4056
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
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
The easy fix, of course, is to create a
The text was updated successfully, but these errors were encountered:
Curiously, my friend doesn't seem to have this problem, and actually my another Mac works too.
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.
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
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.
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
Hi, I also came up with this issue: when cargo build hello_world example. then