如何在gem5中运行动态链接的可执行syscall仿真模式se.py? [英] How to run a dynamically linked executable syscall emulation mode se.py in gem5?

问题描述

在某些条件下，我设法运行了一个静态链接的hello世界.

After How to solve "FATAL: kernel too old" when running gem5 in syscall emulation SE mode? I managed to run a statically linked hello world under certain conditions.

但是，如果我尝试通过以下方式运行针对stdlib的ARM动态链接的服务器:

But if I try to run an ARM dynamically linked one against the stdlib with:

./out/common/gem5/build/ARM/gem5.opt ./gem5/gem5/configs/example/se.py -c ./a.out

它失败并显示:

fatal: Unable to open dynamic executable's interpreter.

如何使它找到口译员?希望不要在主机的根目录上复制"cross"工具链的解释器.

How to make it find the interpreter? Hopefully without copying my cross' toolchain's interpreter on my host's root.

对于x86_64，如果我使用本机编译器，则可以使用，并且如预期的那样，strace说它正在使用本机解释器，但是，如果使用交叉编译器，则不起作用.

For x86_64 it works if I use my native compiler, and as expected strace says that it is using the native interpreter, but it does not work if I use a cross compiler.

当前的常见问题解答说不可能使用动态可执行文件: http://gem5.org/Frequently_Asked_Questions但我不信任它，然后这些演示文稿提到了它:

The current FAQ says it is not possible to use dynamic executables: http://gem5.org/Frequently_Asked_Questions but I don't trust it, and then these presentations mention it:

• http://www.gem5.org/wiki/images/0/0c/2015_ws_08_dynamic-linker.pdf
• http://research.cs.wisc.edu/multifacet/papers/learning_gem5_tutorial.pdf

• http://www.gem5.org/wiki/images/0/0c/2015_ws_08_dynamic-linker.pdf
• http://research.cs.wisc.edu/multifacet/papers/learning_gem5_tutorial.pdf

但不实际使用它.

QEMU用户模式具有-L选项.

QEMU user mode has the -L option for that.

在gem5 49f96e7b77925837aa5bc84d4c3453ab5f07408e中进行了测试

Tested in gem5 49f96e7b77925837aa5bc84d4c3453ab5f07408e

https://www.mail-archive.com/[e-mail]/msg15582.html

推荐答案

动态链接支持已于2019年11月添加

在: https://gem5-review.googlesource.com/c/public/gem5/+/23066

如果您要使用根文件系统，例如

If you have a root filesystem to use, for example one generated by Buildroot you can do:

./build/ARM/gem5.opt configs/example/se.py \
  --redirects /lib=/path/to/build/target/lib \
  --redirects /lib64=/path/to/build/target/lib64 \
  --redirects /usr/lib=/path/to/build/target/usr/lib \
  --redirects /usr/lib64=/path/to/build/target/usr/lib64 \
  --interp-dir /path/to/build/target \
  --cmd /path/to/build/target/bin/hello

或者如果您正在使用Ubuntu交叉编译器工具链(例如在Ubuntu 18.04中):

Or if you are using an Ubuntu cross compiler toolchain for example in Ubuntu 18.04:

sudo apt install gcc-aarch64-linux-gnu
aarch64-linux-gnu-gcc -o hello.out hello.c
./build/ARM/gem5.opt configs/example/se.py \
  --interp-dir /usr/aarch64-linux-gnu \
  --redirects /lib=/usr/aarch64-linux-gnu/lib \
  --cmd hello.out

32位臂臂后来在以下位置断裂: https://gem5.atlassian. net/browse/GEM5-461 需要修复.

The arm 32-bit one broke later on at: https://gem5.atlassian.net/browse/GEM5-461 needs fixing.

您还必须添加可能包含动态库的所有路径作为单独的--redirect.这些对于C可执行文件就足够了.

You have to add any paths that might contain dynamic libraries as a separate --redirect as well. Those are enough for C executables.

--interp-dir根据ELF元数据(表示加载程序的路径)，设置将在其中搜索动态加载程序的根目录.例如，buildroot ELF文件将该路径设置为/lib/ld-linux-aarch64.so.1，而加载程序是/path/to/build/target/lib/ld-linux-aarch64.so.1上的文件.正如布兰登(Brandon)所述，可以通过以下方式找到此路径:

--interp-dir sets the root directory where the dynamic loader will be searched for, based on ELF metadata which says the path of the loader. For example, buildroot ELF files set that path to /lib/ld-linux-aarch64.so.1, and the loader is a file present at /path/to/build/target/lib/ld-linux-aarch64.so.1. As mentioned by Brandon, this path can be found with:

 readelf -a $bin_name | grep interp

syscall仿真动态链接的主要困难在于我们想要某种方式:

The main difficulty with syscall emulation dynamic linking, is that we want somehow:

• 访问链接器文件可转到魔术目录以在其中找到库
从主应用程序访问
• 其他文件以转到常规路径，例如读取当前工作目录中的输入文件

• linker file accesses to go to a magic directory to find libraries there
• other file accesses from the main application to go to normal paths, e.g. to read an input file in the current working directory

并且很难检测我们是否在加载程序中，特别是因为这可以通过程序中间的dlopen发生.

and it is hard to detect if we are in the loader or not, especially because this can happen via dlopen in the middle of a program.

--redirects选项是一个简单的解决方案.

The --redirects option is a simple solution for that.

例如，/lib=/path/to/build/target/lib这样做是为了使如果来宾可以访问C标准库/lib/libc.so.6，则gem5会发现它位于/lib内部，并将路径重定向到/path/to/build/target/lib/libc.so.6.

For example /lib=/path/to/build/target/lib makes it so that if the guest would access the C standard library /lib/libc.so.6, then gem5 sees that this is inside /lib and redirects the path to /path/to/build/target/lib/libc.so.6 instead.

不利的一面是，实际上无法访问主机的/lib目录中的文件，但这并不常见，因此在大多数情况下都可以使用.

The slight downside is that it becomes impossible to actually access files in the /lib directory of the host, but this is not common, so it works in most cases.

如果您错过任何--redirect，则动态链接程序可能会抱怨找不到该库，并显示以下消息:

If you miss any --redirect, the dynamic linker will likely complain that the library was not found with a message of type:

hello.out: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

如果发生这种情况，则必须在目标文件系统/工具链中找到libstdc++.so.6库，并添加缺少的--redirect.

If that happens, you have to find the libstdc++.so.6 library in the target filesystem / toolchain and add the missing --redirect.

它后来在> https://gem5.atlassian.net/browse/GEM5-430处中断，但又被修复.

It later broke at https://gem5.atlassian.net/browse/GEM5-430 but was fixed again.

动态链接的缺点

一旦我可以使用动态链接，我注意到它实际上有一个缺点:动态链接器必须运行一些指令，并且如果您的userland测试可执行文件非常少，并且运行在O3等低CPU上，那么这个启动会主导运行时，所以要当心.

Once I got dynamic linking to work, I noticed that it actually has one downside: the dynamic linker has to run some instructions, and if you have a very minimal userland test executable, and are running on a low CPU like O3, then this startup can dominate runtime, so watch out for that.

解释器，例如Python和Java

Python和Java只是可执行文件，是用于执行可执行文件参数的脚本.

Python and Java are just executables, and the script to execute an argument to the executable.

因此，从理论上讲，您可以在syscall仿真模式下运行它们，例如与:

So in theory, you can run them in syscall emulation mode e.g. with:

build/ARM/gem5.opt configs/example/se.py --cmd/usr/bin/python --options ='hello.py arg1 arg2'

build/ARM/gem5.opt configs/example/se.py --cmd /usr/bin/python --options='hello.py arg1 arg2'

实际上，鉴于截至2019年11月gem5的当前状态，像解释器这样的非常复杂的可执行文件可能尚未实现系统调用，另请参见:

In practice however hugely complex executable like interpreters are likely to have syscalls that not yet implemented given the current state of gem5 as of November 2019, see also: When to use full system FS vs syscall emulation SE with userland programs in gem5?

通常来说，实现/忽略不需要的电话并不难，因此请尝试一下.相关主题:

Generally it is not hard to implement / ignore uneeded calls though, so give it a shot. Related threads:

• Java:在gem5中运行Java程序(或任何非C语言)
• Python:3.6.8 aarch64失败，并显示致命:未实现syscall未使用#278(#278)."，测试设置

• Java: Running Java programs in gem5(or any language which is not C)
• Python: 3.6.8 aarch64 fails with "fatal: syscall unused#278 (#278) unimplemented.", test setup

旧答案

有人告诉我，截至49f96e7b77925837aa5bc84d4c3453ab5f07408e(2018年5月)，没有一种方便/经过测试的方法可以在syscall仿真中运行动态链接的跨链可执行文件:/[e-mail]/msg15585.html"rel =" nofollow noreferrer> https://www.mail-archive.com/[e-mail]/msg15585.html

I have been told that as of 49f96e7b77925837aa5bc84d4c3453ab5f07408e (May 2018) there is no convenient / well tested way for running dynamically linked cross arch executables in syscall emulation: https://www.mail-archive.com/[e-mail]/msg15585.html

但是我怀疑打补丁gem5来支持它并不难. QEMU用户模式已经支持该功能，您只需使用-L指向根文件系统即可.

I suspect however that it wouldn't be very hard to patch gem5 to support it. QEMU user mode already supports that, you just have to point to the root filesystem with -L.

这篇关于如何在gem5中运行动态链接的可执行syscall仿真模式se.py?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！