前言
在CLR里面几乎所有的函数都运行在内存映射的范围内，至少托管的Main函数及其它大部分是如此。以上如有疏漏，可不吝指教。.
概括
但这就带来一个问题，内存范围内断点会导致了内存映射的失败，而出现异常。为啥.Net程序在运行的时候，不会出现这个状况呢？关于这一点可以参考上一篇文章：绝顶技术:断点+内存映射组合的CLR超强BUG？
为了验证这个状况，首先看下windows平台，通过windbg来看下。
内存映射代码很简答：
if (m_CodeHeaderRW != m_CodeHeader){ExecutableWriterHolder<void> codeWriterHolder((void *)m_CodeHeader, m_codeWriteBufferSize);memcpy(codeWriterHolder.GetRW(), m_CodeHeaderRW, m_codeWriteBufferSize);}
当m_CodeHeaderRW != m_CodeHeader条件成立，则进入括号逻辑执行，memcpy内存复制的同时进行了内存映射。如果这段逻辑在VS上Debug，则会进入括号，但是在Windbg上则如下所示。
00007fff`88e13135 48397d48 cmp qword ptr [rbp+48h],rdi00007fff`88e13139 0f8531e11200 jne coreclr!UnsafeJitFunction+0x12e9d0 (00007fff`88f41270)00007fff`88e1313f 4883c708 add rdi,800007fff`88e13143 488b5d60 mov rbx,qword ptr [rbp+60h]00007fff`88e13147 4c8b642448 mov r12,qword ptr [rsp+48h]00007fff`88e1314c 4d8d742418 lea r14,[r12+18h]00007fff`88e13151 4c89b560020000 mov qword ptr [rbp+260h],r14
地址00007fff`88e1313f跳出括号逻辑，可以看到windb里面m_CodeHeaderRW是等于m_CodeHeader，所以导致了括号逻辑不执行，这样就没有进行内存映射，所以就更无从谈起异常的情况。
那么Linux下面呢？通过lldb观察如下：
* thread #1, name = 'clrrun', stop reason = instruction step into* frame #0: 0x00007ffff798d730 libcoreclr.so`mmap64frame #1: 0x00007ffff788ea35 libcoreclr.so`CorUnix::InternalMapViewOfFile(pThread=0x00005555555c7e10, hFileMappingObject=0x00000000000000c8, dwDesiredAccess=4, dwFileOffsetHigh=0, dwFileOffsetLow=0, dwNumberOfBytesToMap=69632, ppvBaseAddress=0x00007fffffff3700) at map.cpp:1020:29frame #2: 0x00007ffff788efe3 libcoreclr.so`::MapViewOfFileEx(hFileMappingObject=0x00000000000000c8, dwDesiredAccess=4, dwFileOffsetHigh=0, dwFileOffsetLow=0, dwNumberOfBytesToMap=69632, lpBaseAddress=0x0000000000000000) at map.cpp:838:20
linux下更简单了，它用的Linux环境下的mmap进行的内存映射，不存在断点内存映射范围内的失败。所以也不会异常。
结尾
以上初步的分析，但是具体的情况，依然需要更详细验证。比如win平台下的m_CodeHeader在非debug的时候，不是通过内存映射赋值，那么它是从哪里赋值的呢？linux下托管断点为何失败？
