一:背景
1.讲故事
前几天 b 站上有位朋友让我从高级调试的角度来解读下 .net7 新出来的 aot,毕竟这东西是新的,所以这一篇我就简单摸索一下。
二:aot 的几个问题
1. 如何在 .net7 中开启 aot 功能
在 .net7 中开启 aot 非常方便,先来段测试代码。
internal class program {static void main(string[] args) { console.writeline("hello world!"); debugger.break(); } }
然后在项目配置上新增
节点,如下输出:
exe net7.0 enable enable true
接下来在项目中右键选择 发布
,选择一个输出地,这样一个 aot 程序就完成了。
2. sos 可以调试 aot 程序吗
这是很多朋友关心的话题,我们都知道 sos 是用来撬开 coreclr 的,只要能看到 coreclr.dll,那 sos 就能用,接下来用 windbg 附加到 consoleapp2.exe
上,使用 lm
观察。
0:000> lmstart end module name00007ff6`11680000 00007ff6`1196f000 consoleapp2 c (private pdb symbols) c:\test\consoleapp2.pdb00007ffe`692b0000 00007ffe`692c3000 kernel_appcore (deferred) 00007ffe`6b3e0000 00007ffe`6b47d000 msvcp_win (deferred) 00007ffe`6b480000 00007ffe`6b4ff000 bcryptprimitives (deferred) 00007ffe`6b660000 00007ffe`6b687000 bcrypt (deferred) 00007ffe`6b690000 00007ffe`6b6b2000 win32u (deferred) 00007ffe`6b720000 00007ffe`6b82a000 gdi32full (deferred) 00007ffe`6b830000 00007ffe`6b930000 ucrtbase (deferred) 00007ffe`6b9e0000 00007ffe`6bca7000 kernelbase (deferred) 00007ffe`6bcb0000 00007ffe`6bd5a000 advapi32 (deferred) 00007ffe`6be50000 00007ffe`6be7a000 gdi32 (deferred) 00007ffe`6be80000 00007ffe`6bf1b000 sechost (deferred) 00007ffe`6c180000 00007ffe`6c2a3000 rpcrt4 (deferred) 00007ffe`6c440000 00007ffe`6c470000 imm32 (deferred) 00007ffe`6c600000 00007ffe`6c729000 ole32 (deferred) 00007ffe`6c730000 00007ffe`6c7ce000 msvcrt (deferred) 00007ffe`6cc50000 00007ffe`6cfa4000 combase (deferred) 00007ffe`6d160000 00007ffe`6d300000 user32 (deferred) 00007ffe`6d410000 00007ffe`6d4cd000 kernel32 (deferred) 00007ffe`6dc50000 00007ffe`6de44000 ntdll (pdb symbols) c:\mysymbols\ntdll.pdb\63e12347526a46144b98f8cf61cded791\ntdll.pdb
从上面的输出中惊讶的发现,居然没有 clrjit.dll
和 coreclr.dll
,前者没有很好理解,后者没有就很奇怪了。。。
既然没看到 coreclr.dll
这个动态链接库,那至少目前用 sos 肯定是无法调试的,即使你强制加载也会报错。
0:000> .load c:\users\administrator\.dotnet\sos64\sos.dll0:000> !tfailed to find runtime module (coreclr.dll or clr.dll or libcoreclr.so), 0x80004002extension commands need it in order to have something to do.for more information see https://go.microsoft.com/fwlink/?linkid=2135652
到这里我的个人结论是:目前sos无法对这类程序进行调试,如果大家用在生产上出现各种内存暴涨,cpu爆高问题,就要当心了。
3. aot 真的没有 coreclr 吗
其实仔细想一想,这是不可能的,c# 的出发点就是作为一门托管语言而存在,再怎么发展也不会忘记这个初衷,所谓不忘初心,方得始终。
我们回过头看下 consoleapp.exe
这个程序,有没有发现,它居然有 3m 大小。
聪明的朋友应该猜到了,对,就是把 coreclr 打包到 exe 中了,这个太牛了,那怎么验证呢?可以用 ida 打开一下。
从图中可以清晰的看到各种 gc_heap
相关的函数,这也验证了为什么一个简简单单的 consoleapp.exe
有这么大size的原因。
4. 真的无法调试 aot 程序吗
在 windows 平台上就没有 windbg 不能调试的程序,所以 aot 程序自然不在话下,毕竟按托管不行,大不了按非托管调试,这里我们举一个 gc.collect()
的源码调试吧。
- 一段简单的测试代码。
internal class program {static void main(string[] args) { debugger.break(); gc.collect(); } }
- 下断点
熟悉 gc 的朋友应该知道我只需用 bp coreclr!wks::gcheap::garbagecollect
下一个断点就可以了,但刚才我也说了,内存中并没有 coreclr
模块,下面的 x 写法肯定会报错。
0:000> x coreclr!wks::gcheap::garbagecollect ^ couldn't resolve 'x coreclr'
那怎么下呢?先输个 k
观察下调用栈有没有什么新发现。
0:000> k# child-sp retaddr call site00 00000011`5e52f628 00007ff6`7f288c5a consoleapp2!rhdebugbreak 0x2 [d:\a\_work\1\s\src\coreclr\nativeaot\runtime\mischelpers.cpp @ 45] 01 00000011`5e52f630 00007ff6`7f2f0e28 consoleapp2!s_p_corelib_system_diagnostics_debugger__break 0x3a [/_/src/coreclr/nativeaot/system.private.corelib/src/system/diagnostics/debugger.cs @ 17] 02 00000011`5e52f6c0 00007ff6`7f1fe37e consoleapp2!consoleapp2__module___startupcodemain 0x11803 00000011`5e52f720 00007ff6`7f1f9540 consoleapp2!wmain 0xae [d:\a\_work\1\s\src\coreclr\nativeaot\bootstrap\main.cpp @ 205] 04 (inline function) --------`-------- consoleapp2!invoke_main 0x22 [d:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 90] 05 00000011`5e52f770 00007ffe`6d426fd4 consoleapp2!__scrt_common_main_seh 0x10c [d:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 06 00000011`5e52f7b0 00007ffe`6dc9cec1 kernel32!basethreadinitthunk 0x1407 00000011`5e52f7e0 00000000`00000000 ntdll!rtluserthreadstart 0x21
我去,int 3
函数也换了,成了 consoleapp2!rhdebugbreak 0x2
,不过也能看出来,应该将 coreclr 改成 consoleapp2 即可,输出如下:
0:000> bp consoleapp2!wks::gcheap::garbagecollectbreakpoint 0 redefined0:000> gbreakpoint 0 hitconsoleapp2!wks::gcheap::garbagecollect:00007ff6`7f1a9410 48894c2408 mov qword ptr [rsp 8],rcx ss:00000011`5e52f5f0=0000000000000000
源码也看的清清楚楚,路径也是在 gc 目录下。如下图所示:
4. aot 的实现源码在哪里
观察刚才的线程栈中的 d:\a\_work\1\s\src\coreclr\nativeaot\bootstrap\main.cpp
可以发现,新增了一个名为 nativeaot
的目录,这在 .net 6
的 coreclr 源码中是没有的。
如果有感兴趣的朋友,可以研究下源码。
三:总结
总的来说,aot 目前还是一个雏形阶段,大家慎用吧,一旦出了问题,可不好事后调试哦,希望后续加强对 sos 的支持。