Gem5 не работает при выполнении скрипта Python

avatar
Kailash gogineni
12 августа 2021 в 00:57
312
1
0


Я пытаюсь выполнить простой скрипт 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. Будем признательны за любую помощь.

Спасибо

Источник

Ответы (1)

avatar
Peter Cordes
12 августа 2021 в 02:36
0

Системный вызов #318 — __NR_getrandom для x86-64 Linux (см. asm/unistd_64.h). См. справочную страницу getrandom(2) для системного вызова. CPython использует его, если он доступен, вместо open("/dev/urandom") как часть реализации для os.getrandom. (Это может быть непрактично или даже невозможно избежать этого, просто изменив .py, на котором вы запускаете интерпретатор.)

Это довольно новое, т.е. getrandom syscall in C not found упоминает, что многие дистрибутивы GNU/Linux в 2017 году еще не обновились до glibc, который содержал для него функцию-оболочку (чтобы упростить вызов из C). Так что я не удивлен, что однопроцессный режим gem5 (не системный режим) не имеет для него обработчика.

https://bugs.python.org/issue27955 указывает, что os.getrandom Python попытается использовать его, возвращаясь к open("/dev/urandom") только в том случае, если он не существует (т. е. возвращает <172919892 >). Эта проблема заключалась в том, что ядро ​​NAS вместо этого возвращало -EPERM, что было исправлено за счет того, что CPython также рассматривал это как недоступное.

Ваш случай аналогичен: вместо того, чтобы возвращать -ENOSYS для системных вызовов, о которых он не знает (что в этом случае вызовет изящный откат), GEM5 рассматривает это как фатальную ошибку. Это означает у CPython нет никакого способа оставаться в безопасности, кроме как никогда не пытаться использовать этот системный вызов в первую очередь. Старая версия python3, вероятно, была бы безопасной, или пользовательская сборка, которая комментирует оптимистичную попытку.

Если есть способ изменить поведение GEM5, то это тоже сработает. например найдите код, который печатает эту ошибку, и измените его, чтобы он вместо этого возвращал -ENOSYS для неподдерживаемых номеров вызова, как настоящее ядро ​​​​Linux. (Если для этого еще нет опции GEM5.)

TL:DR: один из вариантов:

  • Найдите опцию GEM5 для другой обработки неизвестных системных вызовов, если они есть.
  • или: Измените исходный код GEM5 так, чтобы он возвращал -ENOSYS вместо прерывания с этой фатальной ошибкой, и соберите GEM5 из этого исходного кода.
  • или: Пересоберите CPython из исходного кода после изменения его реализации os.getrandom в C.
  • или: использовать старый двоичный файл python3, который использовался до того, как он пытался использовать Linux getrandom(2).

Интерпретатор CPython — это не простая маленькая программа; он написан на C и имеет большой размер.

Помните, что вы профилируете /usr/bin/python3 с помощью .py как входных данных для этого скомпилированного двоичного исполняемого файла. Это то, что вы профилируете; помните, что CPython — это всего лишь интерпретатор.

Ваше «простое сложение» ни в коем случае не будет выполняться напрямую как собственный машинный код, за исключением того, что интерпретатор в конечном итоге отправит обработчику оператора сложения, который проверит, являются ли входные данные «простыми» (соответствующими часть целочисленной структуры данных расширенной точности Python) или нет, и если это так, то особый случай, который, вероятно, включает операцию C +, которая, вероятно, компилируется в инструкцию x86 add или lea, но много еще код, чтобы добраться до этой точки. Огромные накладные расходы интерпретатора по сравнению с скомпилированной программой C.