如何使用se.py在gem5 syscall仿真模式下编译和运行可执行文件? [英] How to compile and run an executable in gem5 syscall emulation mode with se.py?

问题描述

有很多可能的错误和解决方法散布在不同的地方，谁能在Ubuntu上提供至少一个详细的工作设置，准确的gem5和编译器版本?

解决方案

最小化Ubuntu设置

首先要警惕:动态链接的可执行文件首先运行动态加载程序，这意味着除了静态ELF的主要内容外，还有更多的启动指令.因此，如果您有一个小的用户态测试，并且此时间差恰好发生在"5秒到50秒"的障碍上，那么当您使用该测试用例迭代模拟器/测试用例补丁时，它可能会破坏您的生产率.例如，我观察到一个C ++ hello world调试版本，其中DerivO3CPU在6秒内运行一个静态可执行文件，在150秒内运行一个动态可执行文件！

截至gem5 8162e0da0285d346046151b2a45ceeb1baf63b8f 世界x86，2018年10月，全部C ，arm和aarch64只能在Ubuntu 16.04和18.04上使用. x86以前可以正常工作，但是该提交最终完成了一些必需的更改，以使glibc int代码在main 正常运行之前运行.

鉴于gem5版本和其中一个Ubuntu版本，您可以运行以下C程序:

main.c

#include <stdio.h>

int main(int argc, char **argv) {
    size_t i;
    for (i = 0; i < (size_t)argc; ++i)
        printf("%s\n", argv[i]);
    return 0;
}

简单地为:

sudo apt-get install gcc
gcc -O0 -ggdb3 -std=c99 -static -o x86.out main.c
build/X86/gem5.opt \
  configs/example/se.py \
  -c x86.out \
  -o 'asdf qwer' \
;

sudo apt-get install gcc-arm-linux-gnueabihf
arm-linux-gnueabihf-gcc -O0 -ggdb3 -std=c99 -static -o arm.out main.c
build/ARM/gem5.opt \
  configs/example/se.py \
  -c arm.out \
  -o 'asdf qwer' \
;

sudo apt-get install gcc-aarch64-linux-gnu
aarch64-linux-gnu-gcc -O0 -ggdb3 -std=c99 -static -o aarch64.out main.c
build/ARM/gem5.opt \
    configs/example/se.py \
    -c aarch64.out \
    -o 'asdf qwer' \
;

，并且在所有情况下都会产生正确的输出:

asdf
qwer

如如何在带有se.py的gem5 syscall仿真模式下编译和运行可执行文件?

在 8162e0da0285d346046151b2a45ceeb1

然后，如果您尝试了补丁程序但失败了，请开始对邮件列表中的人员执行ping操作，并寻求有关如何使补丁程序正常工作的指导.

多线程

这是已知的主要痛点.我不知道状态是什么，但是我听说它是​​片状的.

使ARM正常运行的最新修补程序

随着事情不可避免地再次发生，您可能可以从我们已完成的以下修复中汲取灵感，并可能自己解决问题:

• FATAL: kernel too old:已通过以下方式修复: 260b0fc5381a47c681e7ead8e4>/li>
• openat未实现. Ubuntu 18.04上的glibc ARM启动代码开始使用它，这打乱了世界.已通过以下方式修复: 8162e0da0285d346046151b2a45ceeb1baf63b8f
• panic: Attempted to execute unimplemented instruction 'mrs'.已通过以下方式修复: 6efe7e1abf9d289859eb23b52b3a319f15f2736a .通过手动解码，执行的指令为mrs x0, midr_el1.

crosstool-NG

使用crosstool-NG而不是glibc来启用ulibc有时可以作为glibc初始化代码的解决方法，因为ulibc比glibc最少，所执行的代码更少.这不是理想的方法，但是如果您真的无法修补gem5，则可能会起作用.描述于:如何解决致命的:内核太旧"在系统调用仿真SE模式下运行gem5时?

如果您还需要从头开始生成完整的系统映像，则另一种可能性是使用Buildroot构建的交叉编译器， util/build_cross_gcc ，但是我只使用crosstool-NG，它排除了与其他项目的交叉编译器的维护.

There are many possible errors and workarounds scattered in may different places, can anyone provide at least one detailed working setup, with exact gem5 and compiler versions, hopefully on Ubuntu?

解决方案

Minimal working Ubuntu setup

First beware of one thing: a dynamically linked executable first runs the dynamic loader, which means a lot more startup instructions in addition to a static ELF's pre main stuff. Therefore if you have a small userland test, and this time difference happens to happen across the "5 seconds to 50 seconds" barrier, it could destroy your productivity as you iterate an emulator/testcase patch with that testcase. I have observed for example a C++ hello world debug builds in which DerivO3CPU runs a static executable in 6 seconds, and a dynamic one in 150 seconds!

As of gem5 8162e0da0285d346046151b2a45ceeb1baf63b8f Oct 2018, a C hello world for all of x86, arm and aarch64 just works on both Ubuntu 16.04 and 18.04. x86 was working previously, but that commit finalized some required arm changes to make the glibc int code run before main work properly.

Given that gem5 version and one of those Ubuntu versions, you can run the following C program:

main.c

#include <stdio.h>

int main(int argc, char **argv) {
    size_t i;
    for (i = 0; i < (size_t)argc; ++i)
        printf("%s\n", argv[i]);
    return 0;
}

simply as:

sudo apt-get install gcc
gcc -O0 -ggdb3 -std=c99 -static -o x86.out main.c
build/X86/gem5.opt \
  configs/example/se.py \
  -c x86.out \
  -o 'asdf qwer' \
;

sudo apt-get install gcc-arm-linux-gnueabihf
arm-linux-gnueabihf-gcc -O0 -ggdb3 -std=c99 -static -o arm.out main.c
build/ARM/gem5.opt \
  configs/example/se.py \
  -c arm.out \
  -o 'asdf qwer' \
;

sudo apt-get install gcc-aarch64-linux-gnu
aarch64-linux-gnu-gcc -O0 -ggdb3 -std=c99 -static -o aarch64.out main.c
build/ARM/gem5.opt \
    configs/example/se.py \
    -c aarch64.out \
    -o 'asdf qwer' \
;

and in all cases produces the correct output:

asdf
qwer

-static was required on ARM as mentioned at: How to run a dynamically linked executable syscall emulation mode se.py in gem5? Although it is not required anymore, it still requires less CLI options and is easier to use.

Ubuntu cross compiler installation is also mentioned at: How to compile and run an executable in gem5 syscall emulation mode with se.py?

There are also some gem5 in-tree user examples, some of which with proper cross compilation support, under tests/test-progs.

If anyone finds a setup at a newer gem5 revision or Ubuntu version for which such minimal C program does not execute correctly in one of the previously mentioned arches, please send an email describing your system setup in detail to the mailing list and CC me.

Missing syscalls

Then of course, as you try to run more complex userland programs, you will inevitably meet unimplemented syscalls, as there are many of those.

Please don't report those as bugs unless they appear on the glibc setup code for a minimal C example, since we already have a list of the missing syscalls on the source code itself.

Rather, don't be put off, and try a patch!

Many of the syscalls are trivial to implement, see for example 8162e0da0285d346046151b2a45ceeb1baf63b8f.

Only then, if you have tried a patch, but failed, start pinging people on the mailing list and asking for guidance on how to make your patch work.

Multi-threading

TODO this is a known major pain point. I don't know what the status is, but I've heard it is flaky.

Recent fixes that made ARM work

As things inevitably break again, you might be able to take some inspiration from the following fixes that we have done, and possibly patch the problem yourself:

• FATAL: kernel too old: How to solve "FATAL: kernel too old" when running gem5 in syscall emulation SE mode? Fixed by: 260b0fc5381a47c681e7ead8e4f13aad45069665
• openat unimplemented. The glibc ARM startup code on Ubuntu 18.04 started using it, which broke the hello world. Fixed by: 8162e0da0285d346046151b2a45ceeb1baf63b8f
• panic: Attempted to execute unimplemented instruction 'mrs'. Fixed by: 6efe7e1abf9d289859eb23b52b3a319f15f2736a. By decoding it manually, instruction executed was mrs x0, midr_el1.

crosstool-NG

Using crosstool-NG to enable ulibc instead of glibc can sometimes serve as a workaround for glibc init code, since ulibc is more minimal an exercises less code than glibc. It is not ideal, but might work if you really can't manage to patch gem5. Described at: How to solve "FATAL: kernel too old" when running gem5 in syscall emulation SE mode?

Another possibility is to use the crosscompilers built by Buildroot if you also need to generate full system images from scratch, see this example.

There are also some in-tree scripts to build across compiler under: util/build_cross_gcc but I would just use crosstool-NG which factors out maintenance of cross compilers with other projects.

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