Change:
Supported values for this option are: <del> - `none` - debuginfo and symbols (if they exist) are copied to the produced binary or separate files depending on the target (e.g. `.pdb` files in case of MSVC). </del> <ins> - `none` - debuginfo and symbols are not modified. </ins> - `debuginfo` - debuginfo sections and debuginfo symbols from the symbol table <del> section are stripped at link time and are not copied to the produced binary or separate files. This should leave backtraces mostly-intact but may make using a debugger like gdb or lldb ineffectual. - `symbols` - same as `debuginfo`, but the rest of the symbol table section is stripped as well, depending on platform support. On platforms which depend on this symbol table for backtraces, profiling, and similar, this can affect them so negatively as to make the trace incomprehensible. Programs which may be combined with others, such as CLI pipelines and developer tooling, or even anything which wants crash-reporting, should usually avoid `-Cstrip=symbols`. Note that, at any level, removing debuginfo only necessarily impacts "friendly" introspection. `-Cstrip` cannot be relied on as a meaningful security or obfuscation measure, as disassemblers and decompilers can extract considerable information even in the absence of symbols. </del> <ins> section are stripped at link time and are not copied to the produced binary. This should leave backtraces mostly-intact but may make using a debugger like gdb or lldb ineffectual. Prior to 1.79, this unintentionally disabled the generation of `*.pdb` files on MSVC, resulting in the absence of symbols. - `symbols` - same as `debuginfo`, but the rest of the symbol table section is stripped as well, depending on platform support. On platforms which depend on this symbol table for backtraces, profiling, and similar, this can affect them so negatively as to make the trace incomprehensible. Programs which may be combined with others, such as CLI pipelines and developer tooling, or even anything which wants crash-reporting, should usually avoid `-Cstrip=symbols`. Note that, at any level, removing debuginfo only necessarily impacts "friendly" introspection. `-Cstrip` cannot be relied on as a meaningful security or obfuscation measure, as disassemblers and decompilers can extract considerable information even in the absence of symbols. </ins> ## symbol-mangling-version

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Setting up a release profile with stripped binaries and split debuginfo is made very complicated due to subtle differences in how , and interact with eachother across platforms. In particular, in the following setup: Then when targetting linux/macos, a / debug information file will be generated, while when targeting windows, no debug information file can be found. In particular, no file is created. This seems to stem from how the flags propagate to linker invocation: On windows, of rustccodegenssa only takes into account when choosing how to generate the debug information. If it's set to any value other than None, it will not generate any debuginfo whatsoever, regardless of the value of . On macos/linux, it's  that's responsible both for splitting debuginfo and stripping. A / file will be created only if is set to a value other than 0, and is set to packed. Stripping is, crucially, not a part of the equation. I believe the behavior with the windows should be adjusted to match what is done on macos/linux. In particular, if is set to and strip is set to , then a file should be generated. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
I believe is also effected by such inconsistencies. Would be nice to have consistent behavior. And possibly a flag that produces both an unstripped and stripped binary, though that's a separate feature.