warn: ignoring syscall mprotect(...) during simple gem5 simulation - gem5

I built gem5 for X86 and am running simple configs and binaries. To be more specific, I am using following config file
gem5/configs/learning_gem5/part1/two_level.py
When I use officially provided binaries such as gem5/tests/test-progs/hello/bin/x86/linux/hello, it gives the Hello World output without any warning. As following
Beginning simulation!
info: Entering event queue # 0. Starting simulation...
Hello world!
Exiting # tick 57562000 because exiting with last active thread context
However, when I code and compile the simple hello world example, the output of the simulation still works but it gives some warnings and it takes many more ticks. As,
Beginning simulation!
info: Entering event queue # 0. Starting simulation...
warn: ignoring syscall access(...)
info: Increasing stack size by one page.
warn: ignoring syscall mprotect(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall mprotect(...)
warn: ignoring syscall mprotect(...)
Hello - Custom
Exiting # tick 883281000 because exiting with last active thread context
What is the reason for this? Is there a way to solve these warnings so that my custom coded binaries take less time (or ticks)?

The syscall is not implemented, but gem5 devs decided it is usually not needed for the program to run normally enough, and so marked as ignore rather than crash. Syscalls are always 1 tick in SE mode, so implementing it generally won't make much of a difference, unless you have good reason to believe otherwise due to side-effects of the call. See also: gem5 syscall emulation arm C hello world fails with "fatal: syscall gettid (#224) unimplemented"

Related

Terminal process get killed with code ELIFECYCLE errno: 137 when VS Code is open. Quitting VS Code resolves the issue?

I've only recently in the last two days begun encountering this issue.
When I attempt to build my Angular project, It's getting to this one point and failing with errors below.
The only way I can get it to run is to quit VS code and rerun the exact same command and it builds without issue.
Any ideas what may be causing this?
137 is 128 + 9. In some situations—and I'm guessing that this is one of them—this indicates that the process died with a signal 9. Signal 9 is, on macOS (and multiple other OSes), SIGKILL. This signal is sent by the "out of memory" killer.
This also explains why exiting VSCode fixes things: VSCode is a memory hog. Exiting it returns the memory to the system.
To fix this more permanently, either reduce the memory needs of your build and/or of VSCode, or add more memory to your system.
See also What killed my process and why?

What prevents device files from being executed?

I'm writing a kernel character device driver for which I've implemented the fops.read, and the FIONREAD (0x541B) ioctl. The data returned by read is an ELF executable. ls -l confirms that the device has r-x permissions, and both of the following commands allow me to execute the contained ELF binary:
# cp /dev/foo0 /tmp/bar && /tmp/bar
-or-
# cat /dev/foo0 > /tmp/bar && /tmp/bar
foo_open
foo_ioctl 0x0000541B
foo_read size=131072 off=0
foo_ioctl 0x0000541B
foo_read size=131072 off=13096
foo_release
Hello from /tmp/bar!
...
Note that the kernel messages indicate the various driver messages that are called. When I try to run the device directly, however, I get an error:
# /dev/foo0
foo_open
foo_release
/bin/sh: 6: /dev/foo0: Permission denied
What check might be causing the permissions error, and is it possible to override it without fundamentally breaking linux? I'm using the 4.18.3 kernel with a minimal sysroot image.
From man 2 execve:
EACCES The file or a script interpreter is not a regular file.
The Linux kernel only allows regular files to be executed, not character devices or any other special files. The kernel does that check in the do_open_execat function in fs/exec.c:
if (!S_ISREG(file_inode(file)->i_mode))
goto exit;
You can rebuild the kernel without that check if you really want, but it's probably there for a good reason.
Short answer: you’re not (ever) allowed to exec device files. 
The execve man page lists
EACCES
The file or a script interpreter is not a regular file.
in the ERRORS section.

Getting rid of Persistent SIGABRT error

I keep getting the SIGABRT error with my app. I've tried re-downloading my entire developer profile certificates and provisioning certs etc and still no change. I've also played with changing architectures. The activity log for my project when it crashes is below - any one know what's causing it?
[CODE]GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Fri Sep 16 06:56:50 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i386-apple-darwin --target=arm-apple-darwin".tty /dev/ttys001
sharedlibrary apply-load-rules all
target remote-mobile /tmp/.XcodeGDBRemote-1268-71
Switching to remote-macosx protocol
mem 0x1000 0x3fffffff cache
mem 0x40000000 0xffffffff none
mem 0x00000000 0x0fff none
[Switching to process 7171 thread 0x1c03]
[Switching to process 7171 thread 0x1c03]
Couldn't register sh.heather.reactionfree with the bootstrap server. Error: unknown error code.
This generally means that another instance of this process was already running or is hung in the debugger.(gdb) [/CODE]
I've had this problem a few times. I'm not sure but it seems to occur for me when I continually build and run without stopping the previous build in the simulator. (I try to always press the stop button now)
Things to try
Sometimes this is fixed by just quitting the simulator and Xcode.
Sometimes I've had to do a full system restart.
So they may get you back on your feet quickly but I would also enjoy hearing the reason/fix from someone who knows more.
you must be having memory management issues,. just clean build it and then press analyze for any issues/ leaks and dead memory management problems... once all are cleared then your program functions as per your coding.

No debugging data in vmlinux when running crash to analyze kernel panic

I'm trying to analyze a Linux kernel panic on openSUSE 11.3 using kdump and the crash utility. The system is successfully creating the vmcore file, but when I go to analyze it, crash complains about the lack of symbols.
# crash -s vmlinux-2.6.34-12-desktop.gz vmcore
crash: vmlinux-2.6.34-12-desktop.gz: no debugging data available
crash: vmlinux-2.6.34-12-desktop.debug: debuginfo file not found
crash: either install the appropriate kernel debuginfo package, or
copy vmlinux-2.6.34-12-desktop.debug to this machine
The system is running a stock desktop kernel
# uname -r
2.6.34-12-desktop
and has the kernel-devel and kernel-desktop-devel packages installed. Does some other package have the debug symbols (similar to Red Hat's kernel-debuginfo rpm) or is there another approach / kernel I should be using?
The symbols for openSUSE are named similarly to Red Hat and variants (CentOS, Fedora, ...) but live in a different repository. For this example, the vmlinux symbols are in the kernel-desktop-devel-debuginfo package, but practically, you'd probably also want to grab the kernel-desktop-debuginfo for the module symbols.
Load the "kernel-debug-devel" package for your kernel.

How do you start running the program over again in gdb with 'target remote'?

When you're doing a usual gdb session on an executable file on the same computer, you can give the run command and it will start the program over again.
When you're running gdb on an embedded system, as with the command target localhost:3210, how do you start the program over again without quitting and restarting your gdb session?
You are looking for Multi-Process Mode for gdbserver and set remote exec-file filename
Unfortunately, I don't know of a way to restart the application and still maintain your session. A workaround is to set the PC back to the entry point of your program. You can do this by either calling:
jump function
or
set $pc=address.
If you munged the arguments to main you may need set them up again.
Edit:
There are a couple of caveats with the above method that could cause problems.
If you are in a multi-threaded program jumping to main will jump the current thread to main, all other threads remain. If the current thread held a lock...then you have some problems.
Memory leaks, if you program flow allocates some stuff during initialization then you just leaked a bunch of memory with the jump.
Open files will still remain open. If you mmap some files or an address, the call will most likely fail.
So, using jump isn't the same thing as restarting the program.
"jump _start" is the usual way.
Presumably you are running gdbserver on the embedded system.
You can ask it to restart your program instead of exiting with target extended-remote
Step-by-step procedure
Remote:
# pwd contains cross-compiled ./myexec
gdbserver --multi :1234
Local:
# pwd also contains the same cross-compiled ./myexec
gdb -ex 'target extended-remote 192.168.0.1:1234' \
-ex 'set remote exec-file ./myexec' \
--args ./myexec arg1 arg2
(gdb) r
[Inferior 1 (process 1234) exited normally]
(gdb) r
[Inferior 1 (process 1235) exited normally]
(gdb) monitor exit
Tested in Ubuntu 14.04.
It is also possible to pass CLI arguments to the program as:
gdbserver --multi :1234 ./myexec arg1 arg2
and the ./myexec part removes the need for set remote exec-file ./myexec, but this has the following annoyances:
undocumented: https://sourceware.org/bugzilla/show_bug.cgi?id=21981
does not show on show args and does not persist across restarts: https://sourceware.org/bugzilla/show_bug.cgi?id=21980
Pass environment variables and change working directory without restart: How to modify the environment variables and working directory of gdbserver --multi without restarting it?
If you are running regular gdb you can type 'run' shortcut 'r' and gdb asks you if you wish to restart the program
For me the method described in 21.2 Sample GDB session startup works great. When I enter monitor reset halt later at the “(gdb)” prompt the target hardware is reset and I can re-start the application with c (= continue).
The load command can be omitted between the runs because there is no need to flash the program again and again.
You can use jump gdb command. For that, you can check your startup script.
My startup script has a symbol.
.section .text.Reset_Handler
.weak Reset_Handler
.type Reset_Handler, %function
Reset_Handler:
ldr r0, =_estack
mov sp, r0 /* set stack pointer */
I wanted to jump to start. That's why I used:
jump Reset_Handler
On EFM32 Happy Gecko none of the suggestions would work for me, so here is what I have learned from the documentation on integrating GDB into the Eclipse environment.
(gdb) mon reset 0
(gdb) continue
(gdb) continue
This puts me in the state that I would have expected when hitting reset from the IDE.