Gem5在执行python脚本时不工作

Question

我试图执行一个简单的python脚本，并传递命令行参数，以便在gem5中简单地添加数字 命令：

sudo ./build/X86/gem5.opt configs/example/se.py --cmd /usr/bin/python3 --options "sum.py 3 4"

sum.py源代码：

import sys
x=int(sys.argv[1])
y=int(sys.argv[2])
sum=x+y
print("The addition is :",sum)

我得到的错误是：

osboxes@osboxes:~/gem5$ sudo ./build/X86/gem5.opt configs/example/se.py --cmd /usr/bin/python3 --options "sum.py 3 4"
gem5 Simulator System.  http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.

gem5 version 21.0.0.0
gem5 compiled Aug  5 2021 21:03:24
gem5 started Aug 11 2021 20:44:15
gem5 executing on osboxes, pid 4072
command line: ./build/X86/gem5.opt configs/example/se.py --cmd /usr/bin/python3 --options 'sum.py 3 4'

warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.master is deprecated. `master` is now called `mem_side_ports`
warn: membus.master is deprecated. `master` is now called `mem_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
Global frequency set at 1000000000000 ticks per second
warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (512 Mbytes)
warn: Not reserving swap space. May cause SIGSEGV on actual usage
0: system.remote_gdb: listening for remote gdb on port 7000
** REAL SIMULATION **
info: Entering event queue @ 0.  Starting simulation...
warn: ignoring syscall access(...)
warn: ignoring syscall access(...)
warn: ignoring syscall access(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall access(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall access(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall access(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall access(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall access(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall access(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall set_robust_list(...)
warn: ignoring syscall rt_sigaction(...)
      (further warnings will be suppressed)
warn: ignoring syscall rt_sigprocmask(...)
      (further warnings will be suppressed)
fatal: Syscall 318 out of range
Memory Usage: 705664 KBytes

有人能告诉我在执行python脚本时哪里出了问题吗。任何帮助都将不胜感激

谢谢

Answer 1

对于x86-64 Linux，系统调用#318是__NR_getrandom（请参见asm/unistd_64.h）。有关系统调用，请参见^{} man page。作为os.getrandom实现的一部分，CPython使用它（如果可用）代替open("/dev/urandom")。（仅仅通过更改运行解释器的.py来避免调用它可能是不切实际的，甚至是不可能的。）

这是一个非常新的版本，例如getrandom syscall in C not found提到2017年的许多GNU/Linux发行版还没有更新到包含包装函数的glibc（以方便从C调用）。所以我并不奇怪gem5的单进程模式（不是系统模式）没有处理程序

https://bugs.python.org/issue27955表示Python的os.getrandom将尝试使用它，只有当它不存在时才返回到open("/dev/urandom")（即返回-ENOSYS）。这个问题是NAS内核返回-EPERM，通过让CPython也将其视为不可用来修复

您的情况与此类似：GEM5没有为不知道的系统调用返回-ENOSYS（在这种情况下会触发优雅的回退），而是将其视为致命错误。这意味着CPython没有办法保持安全，除非一开始就从未尝试使用该系统调用。一个旧版本的python3可能是安全的，或者是一个自定义的构建来注释乐观的尝试

如果有办法改变GEM5的行为，那也可以。e、 g.找到打印该错误的代码，并将其更改为返回-ENOSYS不支持的呼叫号码，就像真正的Linux内核一样。（如果没有一个GEM5选项可以这样做。）

TL:DR：您的选项是：

• 找到一个GEM5选项，以便在存在未知系统调用时以不同方式处理该调用
• 或者：将GEM5源代码更改为返回-ENOSYS，而不是使用该致命错误中止，然后从该源代码构建GEM5
• 或者：在C中更改其os.getrandom实现后从源代码重新生成CPython
• 或者：在尝试使用Linux getrandom(2)之前使用旧的python3二进制文件

---

CPython解释器不是一个简单的小程序；它是用C写的，而且很大

请记住，您正在使用.py作为已编译二进制可执行文件的输入数据对/usr/bin/python3进行评测这就是你要分析的内容；请记住，CPython纯粹是一个解释器

您的“简单加法”在任何时候都不会作为本机代码直接运行，除非解释器最终会将其分派给加法运算符的处理程序，该处理程序将检查输入是否都是“简单的”（适合Python的扩展精度整数数据结构的一块），如果是这样做的话，这个特例可能涉及一个C+操作，它可能编译成一个x86add或lea指令，但是更多的代码就是为了达到这一点。与编译的C程序相比，巨大的解释器开销