linux system call,Linux系统调用x86的调用(Linux system call invocation for x86)

Linux系统调用x86的调用(Linux system call invocation for x86)

我试图了解在Linux机器上调用系统调用的方式。 为此，我在QEMU仿真器上运行了一台带有Linux 3.0.43内核的客户机。

为了知道系统调用号，我检测了qemu中的中断函数do_interrupt_all() target-i386/seg_helper.c do_interrupt_all() ---不是很重要)。 基本上每当我得到int 0x80中断时，我都会在EAX寄存器中打印该值。 运行的输出给出了系统调用号。 我期望exec系统首先调用init进程。 然后是一个fork和一些`brk系统调用。 但是，我不确定这是不是我得到的。 我在这里打印前100个系统电话号码。 我的客人是64位机器。 这是我内核的在线代码探索。

: 11

: 45

: 33

: 192

: 33

: 5

: 197

: 192

: 6

: 33

: 5

: 3

: 197

: 192

: 192

: 192

: 6

: 192

: 243

: 125

: 125

: 125

: 91

: 122

: 45

: 45

: 197

: 5

: 5

: 5

: 5

: 221

: 141

: 141

: 6

: 5

: 5

: 5

: 5

: 5

: 197

: 192

: 3

: 3

: 6

: 91

: 5

: 197

: 192

: 3

: 3

: 6

: 91

: 5

: 197

: 192

: 3

: 3

: 6

: 91

: 5

: 197

: 192

: 3

: 3

: 6

: 91

: 5

: 197

: 192

: 3

: 3

: 6

: 91

: 5

: 197

: 192

: 3

: 3

: 6

: 91

: 5

: 5

: 197

: 192

: 3

: 3

: 6

: 91

: 5

: 197

: 192

: 3

: 3

: 6

: 91

: 5

: 197

I am trying to understand the way system-calls are invoked on a Linux machine. For this, I ran a guest machine with a Linux 3.0.43 kernel on the QEMU emulator.

In order to know the system call numbers, I instrumented the interrupt function in qemu (do_interrupt_all() in target-i386/seg_helper.c --- not very important). Basically whenever I get an int 0x80 interrupt, I print the value in the EAX register. The output of the run gave the system call numbers. I expected the exec system call for the init process first. Then a fork and some `brk system calls. However, I am not sure if that is what I got. I am printing the first 100 system call numbers here. My guest is a 64-bit machine. Here is an online code exploration for my kernel.

: 11

: 45

: 33

: 192

: 33

: 5

: 197

: 192

: 6

: 33

: 5

: 3

: 197

: 192

: 192

: 192

: 6

: 192

: 243

: 125

: 125

: 125

: 91

: 122

: 45

: 45

: 197

: 5

: 5

: 5

: 5

: 221

: 141

: 141

: 6

: 5

: 5

: 5

: 5

: 5

: 197

: 192

: 3

: 3

: 6

: 91

: 5

: 197

: 192

: 3

: 3

: 6

: 91

: 5

: 197

: 192

: 3

: 3

: 6

: 91

: 5

: 197

: 192

: 3

: 3

: 6

: 91

: 5

: 197

: 192

: 3

: 3

: 6

: 91

: 5

: 197

: 192

: 3

: 3

: 6

: 91

: 5

: 5

: 197

: 192

: 3

: 3

: 6

: 91

: 5

: 197

: 192

: 3

: 3

: 6

: 91

: 5

: 197

原文：https://stackoverflow.com/questions/14360465

更新时间：2019-07-10 14:02

最满意答案

11： sys_exevce ，或exec的系统调用

45： sys_brk ，malloc下的东西

33： sys_access

192： lgetxattr

等等。

11 : sys_exevce, or exec's system call

45 : sys_brk, the thing under malloc

33 : sys_access

192 : lgetxattr

And so on.

2013-01-16

相关问答

设计i386 / x86-64架构的部分方式是CS和其他段寄存器引用GDT中的条目。 除了描述当前运行任务的操作模式和权限级别的基数和限制之外，GDT条目还有一些特殊位。 如果CS寄存器指的是32位代码段 ，则处理器将以基本上与i386兼容模式运行。 同样，64位代码需要64位代码段。 所以，把这一切都放在一起。 当操作系统想要运行32位任务时，在任务切换到它期间，它会将一个值加载到CS中，该值指的是32位代码段。 中断处理程序也有与之关联的段寄存器，因此当发生系统调用或发生中断时，处理程序将切换

...

是的，这就是你得到的( Linux系统调用号码 ， 64位Linux系统调用号码 )： 11： sys_exevce ，或exec的系统调用 45： sys_brk ，malloc下的东西 33： sys_access 192： lgetxattr 等等。 Yes, it's what you got (Linux System Call Numbers, 64-bit Linux System Call Numbers): 11 : sys_exevce, or exec's system ca

...

我只能建议在隔离的位置(而不是/usr/目录)重建ImageMagick和委托。 curl -O http://www.imagemagick.org/download/ImageMagick.tar.gz

tar zvxf ImageMagick.tar.gz && cd ImageMagick-6.9.2-4

CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32 \

./configure --build=i686-pc-linux-gnu --prefix=/opt/

...

您可以使用SystemProperties来获取信息。 System.getProperty("os.arch"); //Operating system architecture

You can Use SystemProperties to get the information. System.getProperty("os.arch"); //Operating system architecture

我在Linux上使用GNU Assembler(gas)验证了这些。 内核接口 x86-32 Linux系统调用约定： 在x86-32参数中，Linux系统调用使用寄存器传递。 %eax为syscall_number。 ％ebx，％ecx，％edx，％esi，％edi，％ebp用于将6个参数传递给系统调用。 返回值为%eax 。 所有其他寄存器(包括EFLAGS)都保留在int $0x80 。 我从Linux装配教程中引用了以下代码段，但我对此感到怀疑。 如果有人可以举个例子，那会是很棒的。 如果

...

编辑如果你正在使用NASM，那么你的int2abin宏有问题。 开始： %macro int2abin 2

mov eax, dword[%1]

但是当你打电话给它时，你会使用 int2abin dword [cubeAreas+rsi*4], tempString

...

int2abin dword [cubeAreasAve], tempString

这复制了方括号( [] ) - 所以我将宏更改为： mov eax, %1

您的代码包含以下行： add al,

...

如何期望以下代码设置堆栈？ 你写的是ES而不是SS！ mov ax, 0x9000

mov es, ax ; setup a stack

mov sp, 0x2000 ; 8 kb

KERNEL.BIN应该在内存地址0x2000，下一个代码加载它更高。 mov ax, 2000h ; Segment where we'll load the kernel

mov es, ax

将它改为mov ax,0200h mov es,ax How to you expect that

...

CALL指令的类型是： 近，相对(操作码E8)( call func ) 远，绝对(操作码9A)( call 0x12:0x12345678 ) 近，绝对，间接(操作码FF / 2)( call [edi] ) 远，绝对，间接(操作码FF / 3)( call far [edi] ) 远程调用意味着除了eip之外它还会更改段选择器( cs )的值。 近呼叫仅改变ip / eip / rip 。 相对意味着地址将相对于下一条指令的地址，而绝对调用则提供跳转到的确切地址。 间接调用指定寄存器或存储器内

...

stdin的问题在于它是一个宏，它不仅扩展到特定于平台的东西，而且很可能很难从手工装配中访问。 如果您愿意牺牲stdio并使用POSIX调用，则stdin与众所周知的文件描述符＃0相同。 因此，您可以传递0来read并获得您所寻找的几乎所有内容。 我很确定这比stdin C宏更适合汇编程序。 The problem with stdin is that it's a macro that expands to something not only platform-specific, but mo

...

你不想推长度 - C中的字符串只是文本的地址，用零字节标记结尾。 你可以使用gdb找出这样的东西崩溃的地方。 You don't want to push the length - strings in C is just the address of the text with a zero byte to mark the end. You can use gdb to figure out where something like this crashes.