3rd-party/linux-kernel-module-cheat
1
0
Fork 0
mirror of https://github.com/cirosantilli/linux-kernel-module-cheat.git synced 2026-01-23 10:15:57 +01:00
Code Issues Releases Wiki Activity

run-gem5-se

Browse Source
This commit is contained in:
Ciro Santilli 六四事件 法轮功
2018-10-22 00:00:01 +00:00
parent 65acd6b36f
commit b6ccceb344
2 changed files with 19 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
README.adoc
View File

@@ -7781,9 +7781,9 @@ Works and prints `hello`:
./run-toolchain --arch x86_64 gcc -- -static -o x86_64.out "$(./getvar kernel_modules_src_dir)/user/hello.c" ./run-toolchain --arch x86_64 gcc -- -static -o x86_64.out "$(./getvar kernel_modules_src_dir)/user/hello.c"
./run-toolchain --arch arm gcc -- -static -o arm.out "$(./getvar kernel_modules_src_dir)/user/hello.c" ./run-toolchain --arch arm gcc -- -static -o arm.out "$(./getvar kernel_modules_src_dir)/user/hello.c"
./run-toolchain --arch aarch64 gcc -- -static -o aarch64.out "$(./getvar kernel_modules_src_dir)/user/hello.c" ./run-toolchain --arch aarch64 gcc -- -static -o aarch64.out "$(./getvar kernel_modules_src_dir)/user/hello.c"
"$(./getvar --arch x86_64 --gem5 executable)" "$(./getvar gem5_se_file)" -c ./x86_64.out ./run-gem5-se --arch x86_64 ./x86_64.out
"$(./getvar --arch arm --gem5 executable)" "$(./getvar gem5_se_file)" -c ./arm.out ./run-gem5-se --arch arm ./arm.out
"$(./getvar --arch aarch64 --gem5 executable)" "$(./getvar gem5_se_file)" -c ./aarch64.out ./run-gem5-se --arch aarch64 ./aarch64.out
.... ....
But I think this is unreliable, and only works because we are using uclibc which does not check the kernel version as glibc does: https://stackoverflow.com/questions/48959349/how-to-solve-fatal-kernel-too-old-when-running-gem5-in-syscall-emulation-se-m/50542301#50542301 But I think this is unreliable, and only works because we are using uclibc which does not check the kernel version as glibc does: https://stackoverflow.com/questions/48959349/how-to-solve-fatal-kernel-too-old-when-running-gem5-in-syscall-emulation-se-m/50542301#50542301
@@ -7791,9 +7791,9 @@ But I think this is unreliable, and only works because we are using uclibc which
Ignoring that insanity, we then try it with dynamically linked executables: Ignoring that insanity, we then try it with dynamically linked executables:
.... ....
"$(./getvar --arch x86_64 --gem5 executable)" "$(./getvar gem5_se_file)" -c "$(./getvar --arch x86_64 --gem5 target_dir)/hello.out" ./run-gem5-se --arch x86_64 "$(./getvar --arch x86_64 --gem5 target_dir)/hello.out"
"$(./getvar --arch arm --gem5 executable)" "$(./getvar gem5_se_file)" -c "$(./getvar --arch arm --gem5 target_dir)/hello.out" ./run-gem5-se --arch arm "$(./getvar --arch arm --gem5 target_dir)/hello.out"
"$(./getvar --arch aarch64 --gem5 executable)" "$(./getvar gem5_se_file)" -c "$(./getvar --arch aarch64 --gem5 target_dir)/hello.out" ./run-gem5-se --arch aarch64 "$(./getvar --arch aarch64 --gem5 target_dir)/hello.out"
.... ....
But at 185c2730cc78d5adda683d76c0e3b35e7cb534f0 they fail with: But at 185c2730cc78d5adda683d76c0e3b35e7cb534f0 they fail with:

13
run-gem5-se Executable file
View File

@@ -0,0 +1,13 @@
#!/usr/bin/env python3
import common
parser = common.get_argparse(
default_args={'gem5':True},
argparse_args={'description':'Run executable in gem5 se.py syscall emulation mode'}
)
parser.add_argument(
'executable',
)
args = common.setup(parser)
common.run_cmd([common.executable, common.gem5_se_file, '-c', args.executable])