Managed Bytecode Stripping and Debug Symbols

Unity Engine
1

Hello!

I am trying to turn on the managed bytecode stripping, but am hitting a weird situation; some of the stripped assemblies have their debug symbols (pdb, we are on 2018.3.8) removed, while other assemblies have their symbols kept.

Is there some logic behind the debug symbols being removed, or is it most likely a bug in the Unity Linker?

Also, to give more info - this happens with Medium level stripping; with Low, all debug symbols are kept.

2

Some scenarios in which symbol files are expected to no longer exist after managed code stripping are:

  • If an entire assembly was stripped away, it’s symbols will also be removed
  • The assembly had no symbol file to begin with.
  • If you are doing a player build on a non-windows platform and you had an assembly that was compiled on windows with pdb symbols (note this applies to the non-portable pdb .pdb files)

A few questions that will help me get a better idea of whether what you are seeing is expected or a bug.

  • Are you on windows or osx?
  • Do you have any precompiled assemblies in your project?
  • Can you share a list of the assemblies that have and don’t have symbol files? Or provide any additional details on which assemblies retain symbols and which do not? Especially the ones that had symbols with Low stripping but do not with Medium.
3

The assembly stays (and actually has still a lot of code), but the symbols do not. All of the assemblies are coming from asmdef files, we do not use default Assembly-CSharp etc. at all anymore.

I am on Windows, and building a 64bit Windows Standalone player.

I can’t see any pattern in the assemblies missing the symbols. Also, it’s not only “root” assemblies that are missing the symbols. For some assemblies cases, when B depends on A, the symbols for B are kept and the symbols for A are missing.

I could try taking one or two assemblies from the project and reproduce the bug tomorrow, because to me, it clearly seems like a bug. If it won’t be reproducible, I can share a list of assemblies, their types, fields and methods (before and after stripping) and marking which do have and which do not have the symbols.

4

Please submit a bug and we will take a look. Don’t feel like you have to simplify a repro. You can submit your full project if you would like.

5

Reported as Case 1142732.

6

Thanks for the bug report. I was able to pin point the issue. There is indeed a bug on our end. A fix will land in an future patch release.

I noticed in the bug that you are using the mono backend with Managed Stripping Level of Medium. There is actually a bug in the current 2018.3 that causes the stripped version of some assemblies to be overwritten with the unstripped version. Depending on the project, this may or may not cause noticeable issues. However, because of it, I would generally not recommend using a Managed Stripping Level other than Disabled with the mono backend until 2018.3.13 is released. That is the first version the fix will appear in.

As for the case you reported. The only viable workaround is to use Managed Stripping Level = Low. The bug does not occur in that mode.

7

Thanks for checking & fixing it quickly, and letting me know about the other existing issue as well! I will definitely wait until both of these fixes land.

Just out of curiosity, do you have any idea why the symbol files from unstripped assemblies do not work with stripped ones? Intuitively, since the symbol matches an IL offset to the source code line, and we are removing methods/types (and therefore not changing IL offsets of existing methods), the symbols should still be OK. Or not?

8

I’m not sure. I’ve never tried to use unstripped symbols with a stripped assembly. It does seem plausible that it could work. This is a guess, but it could have something to do with the fact that we regenerate the assembly guid when we strip an assembly. linker/src/linker/Linker.Steps/RegenerateGuidStep.cs at main · Unity-Technologies/linker · GitHub

1 Like
9

Hey, can I ask when is the Linker fix coming to Unity 2018.3? Is it going to be a 2018.3.13 as well, or some later release?

10

It’s hard to say for certain, but it looks like 2018.4.2. The last release of 2018.3 will be 2018.3.14 and it doesn’t look like the fix will make that release.