Fix indentation.

Oddly, we don't use tabs here...
[runtime] Fix AOT log message

In 72ca429d6ced5d0a5cf9e517e19aa2c49405f4ed the message format was
refactored and an additional '%s' format specifier was left over.
[sdb] Fix tests.
[jit] Fix the processing of LLVM compiled method frames on x86. Fixes running corlib tests with LLVM.
[sdb] Fix an assertion if a single step breakpoint is hit in a thread other than the thread the single stepping is done on. Fixes #14950.
Fix the amd64 build. Fix a warning.
Merge pull request #797 from ranma42/fix-log-message

[runtime] Fix AOT log message
Fix the linker script for OSX. libtool screwed up the first attempt.
[jit] Implement support for OP_TLS_GET_REG on amd64 linux.
[sgen] Use mono_class_has_parent () instead of mono_class_has_parent_fast () in one place.
Fix warnings.
Revert "[sgen] Use mono_class_has_parent () instead of mono_class_has_parent_fast () in one place."

This reverts commit 2594b363632d507e20dbc728f48bcb4bfef7295f.

Revert this as its wrong.
[jit] Fix a gsharedvt crash on x86.
[jit]Extract emit_init_local and use it with the ldloca optimization to handle any kind of types.
Fixed an issue in corlib Makefile that would make a resource test case fail which relies on satellite assemblies.
The satellite assembly generated by the Makefile was suffixed with '.Resources.dll', but the assembly loader looks for '.resources.dll', thus the satellite assembly wasn't found.
[jit] Avoid linking the try block with the EH block as this produces spurious BBs during inlining.

The inliner could not handle optimally when we inline code inside the try block as it would be linked
with the catch block.

Since the source block would have more than one exit, the inliner would conservatively not link them together,
which hinders further local optimizations.
Comment style
[System] Avoid an NRE when Close() and Write() are concurrent.

Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=15857

Scenario (for which I couldn't easily create a testcase, but can
sketch out): Imagine using HttpClient...in a multithreaded manner:

	// shared:
	static CancellationTokenSource _cancellationTokenSource = new CancellationTokenSource ();

	// Thread 1
	var request = new HttpRequestMessage(HttpMethod.Post, "https://www.google.com/") {
		Content = new StringContent (new string('x', 1024)),
	};
	using (request)
	using (HttpClient httpClient = new HttpClient())
	using (HttpResponseMessage response = await httpClient.SendAsync(request,
			_cancellationTokenSource.Token)) {
		string responseContent = await response.Content.ReadAsStringAsync();
		Console.WriteLine ("Read {0} chars", responseContent.Length);
	}

	// Thread 2
	_cancellationTokenSource.Cancel ();

This isn't entirely farfetched; in the case of #15857, Thread 2 was
the Main thread (due to the user clicking a button), while Thread 1
was the ThreadPool (because of async/await).

The _occasional_ result: a TargetInvocationException exception:

	System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object
	  at (wrapper delegate-invoke) <Module>:invoke_bool__this___HttpsClientStream (Mono.Security.Protocol.Tls.HttpsClientStream)
	  at System.Reflection.MonoProperty.GetterAdapterFrame[HttpsClientStream,Boolean] (System.Reflection.Getter`2 getter, System.Object obj)
	  at System.Reflection.MonoProperty.GetValue (System.Object obj, System.Object[] index)
	  --- End of inner exception stack trace ---
	  at System.Reflection.MonoProperty.GetValue (System.Object obj, System.Object[] index)
	  at System.Net.WebConnection.Write (System.Net.HttpWebRequest request, System.Byte[] buffer, Int32 offset, Int32 size, System.String& err_msg)
	  at System.Net.WebConnectionStream.WriteHeaders ()
	  at System.Net.WebConnectionStream.SetHeaders (System.Byte[] buffer)
	  at System.Net.HttpWebRequest.SendRequestHeaders (Boolean propagate_error)
	--- End of stack trace from previous location where exception was thrown ---
	  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw ()
	  at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1+ConfiguredTaskAwaiter[System.Net.Http.HttpResponseMessage].GetResult ()
	  at System.Net.Http.HttpClient+<SendAsyncWorker>c__async0.MoveNext ()
	--- End of stack trace from previous location where exception was thrown ---
	  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw ()
	  at System.Runtime.CompilerServices.TaskAwaiter`1[System.Net.Http.HttpResponseMessage].GetResult ()
	  at HttpClientAsyncCancellationRepro.Activity1+<AccessGoogleButton_Click>c__async0.MoveNext ()

Huh?

The reason why is because HttpClientHandler.SendAsync() registers a
Cancel handler with the CancellationTokenSource, and the registered
handler calls HttpWebRequest.Abort() (which eventually calls
WebConnection.Close()). This causes WebConnection.nstream to _change_
while WebConnection.Write() is executing, causing
WebConnection.nstream to go from non-null to null, which
WebConnection.Write() does not expect:

	# WebConnection.CreateStream; from 5 Threadpool worker
	# WebConnection.Write; from 5 Threadpool worker
	# WebConnection.Close; from 1  at    at System.Environment.get_StackTrace()
	   at System.Net.WebConnection.Close(Boolean sendNext)
	   at System.Net.WebConnection.Abort(System.Object sender, System.EventArgs args)
	   at System.Net.WebConnection+AbortHelper.Abort(System.Object sender, System.EventArgs args)
	   at System.Net.HttpWebRequest.Abort()
	   at System.Net.Http.HttpClientHandler+<SendAsync>c__async0.<>m__0(System.Object l)
	   at System.Threading.CancellationToken+<Register>c__AnonStorey0.<>m__0()
	   at System.Threading.CancellationTokenSource.Cancel(Boolean throwOnFirstException)
	   at System.Threading.CancellationTokenSource.Cancel()
	   at System.Threading.CancellationTokenSource.SafeLinkedCancel()
	   at System.Threading.CancellationTokenSource.Cancel(Boolean throwOnFirstException)
	   at System.Threading.CancellationTokenSource.Cancel()
	   at HttpClientAsyncCancellationRepro.Activity1.CancelButton_Click(System.Object sender, System.EventArgs e)
	   at Android.Views.View+IOnClickListenerImplementor.OnClick(Android.Views.View v)
	   at Android.Views.View+IOnClickListenerInvoker.n_OnClick_Landroid_view_View_(IntPtr jnienv, IntPtr native__this, IntPtr native_v)
	   at System.Object.e7b5b870-ea0f-434f-bc31-984f665a44ad(IntPtr , IntPtr , IntPtr )
	# WebConnection.Write: checking piTrustFailure; from 5 Threadpool worker

(Yay extra logging. Notice that WebConnection creates a stream from
the ThreadPool, starts WebConnection.Write(), then before it can se
piTrustFailure the instance is Close()d, which nulls out nstream.)

Since WebConnection.Write() attempts to access the (now null)
WebConnection.nstream field, it results in a NullReferenceException,
which is wrapped into a TargetInvocationException by
System.Reflection.

The fix? As usual, "don't do that."

In this case, WebConnection.Write() has already captured
WebConnection.nstream into the local variable `s` (which thus can't be
changed by another thread). Instead of using WebConnection.nstream,
reuse the `s` local variable, which cannot be null, thus avoiding the
NullReferenceException.

(This solution could fail if HttpsClientStream ever throws e.g.
ObjectDisposedException from HttpsClientStream.TrustFailure, but at
present HttpsClientStream.TrustFailure never throws, so this is fine.)
[fullaot] Don't use the complicated generics-heavy cache under full-aot.
[jit] Fix fbd9fd71679f626fabe0b1bd7f923836f98252b4, a wrong version was commited.