no_std 环境下的可执行文件 - Rust精选
utterances-bot opened this issue · 4 comments
no_std 环境下的可执行文件 - Rust精选
The roots aren't deep but the seeds are planted!
https://rustmagazine.github.io/rust_magazine_2021/chapter_3/no_std_binary.html
我认为并不是这样的，我觉得no_std和平台并没有任何关系。我是这样思考的，std实际上是比no_std更多的存在，既然std都能支持，那么no_std更应该没问题才对。
在windows和linux上测试过了，这是我的测试代码。
@umaYnit 多谢反馈！我个人理解Rust的no_std环境下的可执行文件其实跟C语言的gcc -nostdlib类似，你windows部分的代码里调用了extern "stdcall"应该是win32的C API吧，你linux那部分也用了extern "C"，这样生成的可执行文件用ldd去看应该会有动态库的链接，其实我文章更多讲述的是完全不用Rust或C语言的API,只用操作系统汇编语言提供的syscall
我再改下文章的表述吧，我的no_std定义过于狭义了，基本都在讲述rust如何编译一个纯静态链接的可执行文件。广义的no_std应该只是不用rust的标准库，没说一定要用汇编纯静态链接，也没说不能用C语言的标准库。其实mac环境下no_std你调用下glibc API一样能干不少事情，但是我在mac上调用汇编的syscall指令，编译没问题，运行时进程就不能正常退出
我个人理解Rust的no_std环境下的可执行文件其实跟C语言的gcc -nostdlib类似，
我还是认为和gcc等，具体编译器的实现没关系。
你windows部分的代码里调用了extern "stdcall"应该是win32的C API吧，
正如我仓库中READE.me说的一样，windows并没有提供系统调用的资料和保证，而且内部一直在变化，所以没有直接用纯汇编系统调用的方式进行打印，实际上也是能做到的，不过可能需要查阅社区逆向成果，或自己去逆向。
你linux那部分也用了extern "C"，这样生成的可执行文件用ldd去看应该会有动态库的链接，
linux我是写了两种不同的调用方式，一种是通过动态链接libc并调用（为了说明no_std和动态、静态链接没有关系）；另一种（feature="asm"）就是纯汇编调用，可通过cargo run --release --features asm进行测试查看。
其实我文章更多讲述的是完全不用Rust或C语言的API,只用操作系统汇编语言提供的syscall
这个正是我觉得不合理的点。既然是代码这边写的API，那么API里也就是系统调用，没有魔法，所以API库里能写的，自然自己的代码里也能写。
我再改下文章的表述吧，我的no_std定义过于狭义了，基本都在讲述rust如何编译一个纯静态链接的可执行文件。广义的no_std应该只是不用rust的标准库，没说一定要用汇编纯静态链接，也没说不能用C语言的标准库。
是的。我这里感觉你想的是no_std大部分场景下都是“无依赖”的，所以强调了静态链接的情况。但是能够动态链接的，我认为也能够直接把代码内联进去。
其实mac环境下no_std你调用下glibc API一样能干不少事情，但是我在mac上调用汇编的syscall指令，编译没问题，运行时进程就不能正常退出
之前手边没有mac机器，所以没能测试mac下面的情况。今天在查阅了一些资料后，完成了测试，详见仓库的更新部分。
mac相关的部分参考资料如下：
https://developer.apple.com/library/archive/qa/qa1118/_index.html
rust-lang/rust#30147