Bug 54578 - [cecil] Assemblies are duplicated in fat apps when built with .pdb
Summary: [cecil] Assemblies are duplicated in fat apps when built with .pdb
Status: VERIFIED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: XI 10.10 (d15-2)
Hardware: PC Mac OS
: High major
Target Milestone: 15.2
Assignee: Jb Evain
URL:
Depends on:
Blocks:
 
Reported: 2017-04-06 10:55 UTC by Rolf Bjarne Kvinge [MSFT]
Modified: 2017-04-20 09:54 UTC (History)
7 users (show)

Tags:
Is this bug a regression?: Yes
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
VERIFIED FIXED

Description Rolf Bjarne Kvinge [MSFT] 2017-04-06 10:55:36 UTC
Cecil writes the full path to the .pdb is embedded into assemblies.

At build time, we build 32-bit and 64-bit assemblies in different directories, which means that the resulting linked assemblies end up with different .pdb paths:

> diff -u a b
--- a    2017-04-06 09:33:53.000000000 +0200
+++ b    2017-04-06 09:34:05.000000000 +0200
@@ -48445,7 +48445,7 @@
 000cdcb0  63 68 54 6f 6f 6c 2e 43  72 65 61 74 65 54 65 6d  |chTool.CreateTem|
 000cdcc0  70 6f 72 61 72 79 44 69  72 65 63 74 6f 72 79 30  |poraryDirectory0|
 000cdcd0  2f 6d 74 6f 75 63 68 2d  74 65 73 74 2d 63 61 63  |/mtouch-test-cac|
-000cdce0  68 65 2f 33 32 2f 50 72  65 42 75 69 6c 64 2f 6d  |he/32/PreBuild/m|
+000cdce0  68 65 2f 36 34 2f 50 72  65 42 75 69 6c 64 2f 6d  |he/64/PreBuild/m|
 000cdcf0  73 63 6f 72 6c 69 62 2e  70 64 62 00 24 fb 0c 00  |scorlib.pdb.$...|
 000cdd00  00 00 00 00 00 00 00 00  3e fb 0c 00 00 20 00 00  |........>.... ..|
 000cdd10  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

which prevents us from putting a single assembly into the .app instead of a 32-bit and a 64-bit version.

I think the best fix is for Cecil to support writing relative paths here: https://github.com/jbevain/cecil/blob/7297b51/Mono.Cecil.Cil/PortablePdb.cs#L304

Another option is to change our assembly-comparing code to ignore these differences. I don't like this though, since it's making complicated code even more complicated.

For reference, Roslyn has a similar problem: https://github.com/dotnet/roslyn/issues/9813 (this would affect non-linked builds, and assemblies not processed by Cecil).

This affects release builds as well, because we always copy and load any pdb files so that the AOT compiler can generate better native debug symbols.
Comment 1 Rolf Bjarne Kvinge [MSFT] 2017-04-06 10:58:59 UTC
Cecil bug: https://github.com/jbevain/cecil/issues/372
Comment 3 Sebastien Pouliot 2017-04-06 12:45:20 UTC
This can have a significant impact on the final application size.

c.c. @JB
Comment 4 Jb Evain 2017-04-06 14:50:22 UTC
@Rolf, are assemblies in this case built with -deterministic? If so, Cecil could use this to decide whether to write a full path or a relative path.
Comment 5 Rolf Bjarne Kvinge [MSFT] 2017-04-06 14:52:19 UTC
@JBEvain, unlikely, since it's a fairly new flag. And in any case we don't build our own assemblies with -deterministic yet.
Comment 6 Jb Evain 2017-04-06 14:58:12 UTC
Ok so you need a way to set this behavior unconditionally. I'll look into it.
Comment 7 Sebastien Pouliot 2017-04-06 20:26:10 UTC
@Manuel this, in particular the roslyn option, might be of interest wrt debugging the BCL
Comment 8 Sebastien Pouliot 2017-04-07 12:00:48 UTC
update status
Comment 9 Manuel de la Peña [MSFT] 2017-04-12 17:19:22 UTC
Looking into this on our iOS side.
Comment 10 Sebastien Pouliot 2017-04-18 23:07:51 UTC
@Marek can you pick up https://github.com/jbevain/cecil/commit/f980e1ff78049036312f6709861a19501e14c576 inside mono fork so we can bump and close this ? thanks!
Comment 11 Marek Safar 2017-04-19 10:03:06 UTC
Cecil bumped
Comment 12 Rolf Bjarne Kvinge [MSFT] 2017-04-19 10:30:46 UTC
master PR: https://github.com/xamarin/xamarin-macios/pull/2026
d15-2 PR: https://github.com/xamarin/xamarin-macios/pull/2027
Comment 14 Prasad Raghorte 2017-04-20 09:31:30 UTC
@ Rolf
Hi Rolf, this is unit testing bug, Can you please verify this at your end??
Comment 15 Rolf Bjarne Kvinge [MSFT] 2017-04-20 09:54:25 UTC
The unit test is green, so this is verified.