gpt4 book ai didi

Linux/Golang/glibC系统调用

转载 作者:撒哈拉 更新时间:2024-05-18 19:07:08 57 4
gpt4 key购买 nike

Linux/Golang/glibC系统调用 。

本文主要通过分析Linux环境下Golang的系统调用,以此阐明整个流程 。

有时候涉略过多,反而遭到质疑~,写点文章证明自己实力也好 。

Golang系统调用

找个函数来分析 https://pkg.go.dev/os/exec#Cmd.Wait 。

源码文件在src/os目录下的: exec.go -> exec_unix.go -> pidfd_linux.go https://github.com/golang/go/blob/2f6426834c150c37cdb1330b48e9903963d4329c/src/os/exec.go#L134 。

go/src/os
/exec_unix.go

go/src/os
/pidfd_linux.go

往下是系统调用: src/syscall目录的 syscall_linux.go -> `` 。

image

runtime层的:src/internal/runtime/syscall/syscall_linux.go,如下图,可以看见Sysacll6只有声明没有函数体,是个外部声明.

其函数体内容实际上位于同目录下的 .s 汇编文件,与编译时采用的架构工具链相关.

  • 如编译工具链采用amd64则会编译链接位于 src/internal/runtime/syscall/asm_linux_amd64.s 的汇编文件
    image
  • 如编译工具链采用arm64,则会编译链接 src/internal/runtime/syscall/asm_linux_arm64.s 的汇编文件
    image

by the way: 这里的语法是Golang汇编,属于Plan9分支。 golang汇编参考资料

  1. 官网资料 https://go.dev/doc/asm
  2. 简洁概述 https://hopehook.com/post/golang_assembly/

总结:Golang直接了当地使用汇编实现了系统调用(软中断号),而不需要再通过 libc 去调用系统调用库。这样的好处是不需要考虑 glibc 繁杂沉重的兼容性方案.

Linux 定义的系统调用表

  • 很全的表格:https://gpages.juszkiewicz.com.pl/syscalls-table/syscalls.html
  • ARM64架构:
  • x86_32位架构tbl系统调用表: https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_32.tbl
  • x86_64位架构tbl系统调用表: https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_64.tbl

本地审计工具:ausyscall --dump 。

Linux系统调用

内核实现

通过软中断陷入内核态/特权模式 和STM32 ARM核心一样,都是由一个异常向量表描述中断对应的Handler地址,软硬中断也是一样。 系统调用函数在 include/linux/syscalls.h中定义 。

我们拿asmlinkage long sys_openat(int dfd, const char __user *filename, int flags, umode_t mode); 来分析 。

这里使用了汇编链接,它和上文提到的tbl系统调用表有关。我们拿x86/i386分析,arch/x86/entry/syscalls/syscall_32.tbl 中断号 295 架构i386即传统32位x86 sys_openat 是其回调函数/软中断Handler 。

linux/include/uapi/asm-generic/unistd.h 。

其实现位于 arch/处理器架构/include/之下 可以在 arch/x86 下搜索 openat 。

关于内核的系统调用这部分,本人会在再出一个文章.

Glibc 系统调用库

注意:Glibc属于库,不属于内核,是根文件系统的一部分。 我们在应用态陷入内核态,使用的c库里的open()等等函数,最后都是链式调用到了syscall()类的系统调用函数.

看glibc的源码,就会发现弯弯绕绕,最后是调用到 。

  • x86汇编 https://github.com/bminor/glibc/tree/master/sysdeps/unix/x86_64 。

  • arm汇编 https://github.com/bminor/glibc/tree/master/sysdeps/unix/arm 。

    • sysdeps/unix/arm/sysdep.S 。

    • sysdeps/unix/arm/sysdep.h 。

作用是将参数写入寄存器,让SoC自己触发软中断,根据Linux内核注册的软中断号执行对应地址段的函数,也就是我们常在STM32里注册定义的中断的handle函数.

Linux应用态到内核态例子

在线阅读代码:

  1. https://elixir.bootlin.com/glibc/glibc-2.29/source/include/errno.h#L37
  2. https://codebrowser.dev/glibc/glibc/io/read.c.html
  3. 带了编译产物的仓库 https://github.com/bminor/glibc/tree/a81cdde1cb9d514fc8f014ddf21771c96ff2c182
    这些在线网站都不错,但为了高亮,所以我截图放了github的

我们在应用层调用 系统库的 fread()函数 其链接到glibc库的 libio/iofread.c 。

其中第44行可见其为 _IO_fread 声明了weak弱链接别名 fread,有关别名表可见编译产物如sysdeps/unix/syscalls.list等 做了一些预操作之后,调用libio/libio.h 声明的 libio/genops.c:_IO_sgetn 宏定义 libio/libioP.h ps: JUMP2代表两个参数 。

展开宏 展开宏 。

展开宏 。

展开宏 。

结构体 。

也就说调用了 FP.__xsgetn(FP, DATA, N) ,展开差不多是 。

struct _IO_FILE_plus *THIS;
THIS->vtable->__xsgetn; 即_IO_xsgetn_t类型函数指针

即THIS/file对象的函数地址 size_t __xsgetn (FILE *FP, void *DATA, size_t N),

初始化 _IO_jump_t 位于 JUMP_INIT 。

宏展开 函数定义 。

相关的计数器 。

再看另一个,我们常用的fopen 。

_IO_file_fopen

compat_symbol (libc, _IO_old_file_fopen, _IO_file_fopen, GLIBC_2_0);

_IO_old_file_fopen

#define __open open

这里定向到了 open, 我们需要通过编译产物 sysdeps/unix/syscalls.list 找到其链接段 。

可在 io/open.c 找到函数 __libc_open 位于 由于弱定义,所以被以下覆盖 sysdeps/unix/sysv/linux/open.c 。

关键在于第43行的SYSCALL_CANCEL,其中的宏 展开宏INLINE_SYSCALL_CALL 展开宏 展开宏 展开宏 。

展开为 。

//展开
__INLINE_SYSCALL4(openat, AT_FDCWD, file, oflag, mode)
//继续展开为
__INLINE_SYSCALL(openat, 4, AT_FDCWD, file, oflag, mode)

image

  • ARM64位于 sysdeps/unix/sysv/linux/aarch64/sysdep.h
  • X86的位于 sysdeps/unix/sysv/linux/x86_64/sysdep.h
//x86
#define SYS_ify(syscall_name)	__NR_##syscall_name

#define INTERNAL_SYSCALL(name, nr, args...)				\
	internal_syscall##nr (SYS_ify (name), args)
//aarch64即 arm64
# define INTERNAL_SYSCALL_AARCH64(name, nr, args...)		\
	INTERNAL_SYSCALL_RAW(__ARM_NR_##name, nr, args)

x86的展开为 internal_syscall4 (__NR_openat, AT_FDCWD, file, oflag, mode) 可在 sysdeps/unix/sysv/linux/sh/arch-syscall.h 找到,其中断号为 295 。

对应openat的x86/i386中断号,刚好就是295,源码分析完全正确!每种平台的中断号都不一样,但是这样分析是正确的。 体验一下GNU宏地狱吧! 。

而ARM64的就高明得多,直接通过asm汇编指令写寄存器跳转执行__libc_do_syscall完成 glibc/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S 。

总之是一个系统调用,等价于 openat(AT_FDCWD, file, oflag, mode),

总结:sysdeps是系统调用的实现,向上屏蔽细节,但是封装的过程用于一堆条件宏,根本没办法用代码分析工具,也难以调试。 对GNU LIBC代码的个人拙见: 好处:节省空间,较好的运行速度。 坏处:作为计算机世界的底层支持,这样还不如在编译器优化阶段下功夫,过多的黑魔法必然写出难以理解的代码,牵一发动全身,没有人愿意去改这堆疯狂嵌套的代码。作为新兴语言爱好者的我,始终认为程序要少点黑魔法,简洁直接才是最优解,剩下的东西都应该交给编译器,何况系统调用的耗时从来就不在这里,主要性能影响都是在内核态用户态切换的时候,并不在c库本身.

GNU的代码向来很难读,glibc更是个寄吧,各种宏和硬链接乱飞,有再好的代码阅读工具也难找出来。 但要说来,说到底还是c语言/链接器的设计缺陷,没办法更好的实现动态表和静态表。(多态组合、编译期间的函数静态段的多分支链接) 。

微软的代码是框架难以理解,因为他们也不给出架构图和代码结构的...,,而GNU的代码是宏和链接难以理解.

最后

请指正批评!感谢阅读.

最后此篇关于Linux/Golang/glibC系统调用的文章就讲到这里了,如果你想了解更多关于Linux/Golang/glibC系统调用的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。

57 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com