当一个系统调用返回时，我得到％eax中的系统调用返回值，但是在入口处得到-38，这是hex的0xFFFFFFDA。 这是为了写/读。 这个数字是多less？ 它可以用来安全区分出入口吗？
系统调用条目中eax中的-38显然是ENOSYS（函数未实现），由arch / x86 / kernel / entry_32.S中的syscall_trace_entry放在那里。 我想假设它会一直存在于syscall入口上，但是如果系统调用返回ENOSYS， 它也可以在系统调用结束处出现 。
就我个人而言，我总是跟踪系统调用是否进入或使用ptrace时是否退出，尽管我也看到了一些依赖于ENOSYS的代码。 （我假设你正在使用ptrace）我想这不会工作，如果进程恰好在系统调用时附加到它，但我很幸运，不会碰到这个问题。
我简单地看了一下strace来源，我猜也跟踪了这个状态，因为有一个评论说：“我们正在附加一个已经运行的进程，试着弄清syscalls中进程的状态，来处理第一件事很好。“ 稍微有一点说：“这个进程在系统调用中间睡着了，假的是syscall入口事件。”
总之，这个价值不能被安全地用来区分一个入口和一个出口。 也就是说，我不确定手动跟踪是最好的方法，因为我没有真正的来源，肯定会告诉你使用这种技术，对不起。 🙂
在eax中得到-38的时候我仍然没有得到，但是当做一个系统调用时，eax包含一个定义系统调用的数字（在2.6内核中你可以看看arch / x86 / include / asm / unistd_64.h来看每个电话的号码）。
所以序列如下：
也许你的问题没有这么明确，但是如果你没有编写内核代码/驱动程序，最简单的方法就是告诉你，你是在系统调用之前还是在系统调用结束之后是：当你在你的代码中时是TRUE ;-)。 入口/出口本身在一条指令中立即发生（或多或少），所以无论是在系统调用（那么你会知道，因为它必须是一些内核代码或阻塞调用），或者你不是（几乎每次当你调试你的代码）。