Bug 10273 - Linker removes used constructor
Summary: Linker removes used constructor
Status: RESOLVED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: Tools ()
Version: 6.3.x
Hardware: PC Mac OS
: --- major
Target Milestone: Untriaged
Assignee: Sebastien Pouliot
URL:
Depends on:
Blocks:
 
Reported: 2013-02-13 08:21 UTC by Marek Safar
Modified: 2013-02-13 19:50 UTC (History)
2 users (show)

Tags:
Is this bug a regression?: ---
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:
RESOLVED FIXED

Description Marek Safar 2013-02-13 08:21:27 UTC
Linker removes ObjectHandle constructor even if it's used by the Activator::CreateInstanceFrom
Comment 1 Marek Safar 2013-02-13 08:22:27 UTC
Test code

	[ComVisible (true)]
	public class COMTest : MarshalByRefObject {
		
		private int id;
		public bool constructorFlag = false;
		
		public COMTest ()
		{
			id = 0;
		}
		
		public COMTest (int id)
		{
			this.id = id;
		}
		
		// This property is visible
		[ComVisible (true)]
		public int Id {
			get { return id; }
			set { id = value; }
		}
	}


var objHandle = Activator.CreateInstanceFrom (GetType ().Assembly.Location, typeof (COMTest).FullName);
Console.WriteLine (objHandle);
Comment 2 Sebastien Pouliot 2013-02-13 08:36:36 UTC
The constructor is not used directly used, it's reflected.

We can add special (xml) instructions for ObjectHandle if the BCL itself needs it (it will *never* be linked out in that case, leading to a larger mscorlib.dll) or add some extra code (sometime we can conditionally preserve things in relation to others). 

OTOH if the call to `Activator.CreateInstanceFrom` comes from user code (like the test code) then it's up to the test application to add [Preserve] attributes or add it's own .xml definitions to preserve extra code.

Where does it happens for ObjectHandle ?
Comment 3 Marek Safar 2013-02-13 08:40:23 UTC
Where is ObjectHandle reflected? It's used directly by mscorlib code.

Please check Activator.CreateInstanceFrom implementation

https://github.com/mono/mono/blob/master/mcs/class/corlib/System/Activator.cs#L404
Comment 4 Sebastien Pouliot 2013-02-13 08:53:19 UTC
> Where is ObjectHandle reflected?

I don't know, that's why I asked you where it came from :-)

But I misunderstood your "test code" as being a similar, but different, case (COMTest vs ObjectHandle), i.e. not the one showing the ObjectHandle issue.

The issue is likely because System.Runtime.Remoting is not supported by MonoTouch. However the .ctor should be there (OTOH it would not work). I'll look to duplicate it on mobile-master (since head of master-3.0 asserts when building on device right now).
Comment 5 Sebastien Pouliot 2013-02-13 10:16:41 UTC
Using 6.2.x / mobile-master the ObjectHandle is not removed, but it's code is replaced with an exception, so you get:

    System.NotSupportedException : Linked away

which is the default behavior when trying ot use remoting code. Is that the exception you got ?

It's possible to overide this with --nolinkaway [1] but (beside getting larger application sizes) it does not mean it the code will work (that depends it remoting is really used or not internally).

I'll try to special case ObjectHandle and see what's the impact (working or not, size change).


[1] http://spouliot.wordpress.com/2011/11/01/linker-vs-linked-away-exceptions/
Comment 6 Marek Safar 2013-02-13 10:22:54 UTC
yes, I get Linked away.

I just find this quite confusing. Perhaps in this case you should throw NotSupportedException ("Remoting") or something like that instead of Linked away which is not really true.
Comment 7 Sebastien Pouliot 2013-02-13 10:37:15 UTC
Googling "Linked away" will give better results than "Remoting". In this case it's the IL (not the metadata) that is removed (not that "linked away" is the best term, just the old, well-known one).

OTOH we could change the string to add an URL, which will make it even easier than googling, e.g.

"Linked away - see http://... for reasons why this can happen"

Bryan, could you create a landing page in the documentation for this error ? and give me the final URL so we can update the code to point to it in newer releases.
Comment 8 bryan costanich 2013-02-13 12:02:34 UTC
Is this an error that's exposed during run time?

let's chat, because we're adding some error pages, but they're compiler errors. this sounds like it may need to be a new troubleshooting entry.
Comment 9 Sebastien Pouliot 2013-02-13 19:50:29 UTC
ObjectHandle is pretty small and will be (really) removed by the linker if not used. Since it does not depend on the remoting stack it's not excluded from being "linked away".

I'll ping Bryan tomorrow to enhance the exception message...

fixed in master: a00b41533a9297ff71130e53c934eb5665c9d1bd
QA: unit test added in the same revision