Hi Jason,
I have it working now, thanks for getting me on the right track.
I was including the m5op_x86.o that was created for the m5 application in
utils/m5, which had the -DM5OP_ADDR=0x cdef.
To make it work I compiled m5op_x86.S directly through my benchmark
makefile, along with m5_mm
And a correction, I ran it again on Ubuntu 18.04, and I reproduce without Ruby
as well.
So it is not a Ruby bug.
We need to trace it with --debug-flags ExecAll,SyscallBase and try to
understand what is going on.
From: Rafael Pintar Alevato
Sent: Wednesday, Nove
Hi Santilli, thanks for the response!
I'm on commit 70bfe7aa57c3fac79433bfdfb1c6732996bfc727 and I have the error
with both std::mutex and pthread mutex. The patch you mentioned is already
applied on my version, so it does not solve the issue.
Programs that doesn't use mutex don't present any pro
Hi Daniel,
I think the problem is that you need to compile/link in the m5op_.S
file. For instance, if you're using x86: m5op_x86.S (
https://gem5.googlesource.com/public/gem5/+/master/util/m5/m5op_x86.S).
The mmap version of the m5ops is required only if you're using the KVM CPU.
Otherwise, you s
Hello,
Just joined the mailing list, glad to be here!
I am just starting out with the latest version of gem5 running on Ubuntu
16.04, and trying to instrument the code. I am running in SE mode.
#include "gem5/m5ops.h"
...
m5_work_begin(0,0);
printf("Hello World!\n");
m5_work_end(0,0);
When m5_w
Greetings,
I am building a custom full system configuration (largely influenced by ARM in
configs/FSConfig.py) and am running into an issue where the kernel hangs on
boot, being unable to access the disk image to mount the root filesystem.
Looking at the kernel boot logs and gem5 call trace,
