[gem5-dev] Change in gem5/gem5[develop]: sim: Use off_t for mmap offset arguments
Matthew Poremba has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/27367 )
Change subject: sim: Use off_t for mmap offset arguments
..
sim: Use off_t for mmap offset arguments
The GuestABI used to call the system-calls infers the size of values
read from the registers based on the function signature of the system
call. For mmap this was causing offset to be truncated to a 32-bit
value. In the GPUComputeDriver mmap, the offset must be a 64-bit
value. This fixes a bug where the doorbell memory was not setup and
causing GPU applications to fail.
Change-Id: I75d9b32c0470d1907c68826ef81cf6cd46f60ea7
---
M src/sim/syscall_emul.hh
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/sim/syscall_emul.hh b/src/sim/syscall_emul.hh
index e1a23a0..a2e0f38 100644
--- a/src/sim/syscall_emul.hh
+++ b/src/sim/syscall_emul.hh
@@ -1643,7 +1643,7 @@
SyscallReturn
mmapFunc(SyscallDesc *desc, ThreadContext *tc,
Addr start, uint64_t length, int prot, int tgt_flags,
- int tgt_fd, int offset)
+ int tgt_fd, off_t offset)
{
auto p = tc->getProcessPtr();
Addr page_bytes = tc->getSystemPtr()->getPageBytes();
@@ -1826,7 +1826,7 @@
SyscallReturn
mmap2Func(SyscallDesc *desc, ThreadContext *tc,
Addr start, uint64_t length, int prot, int tgt_flags,
- int tgt_fd, int offset)
+ int tgt_fd, off_t offset)
{
return mmapFunc(desc, tc, start, length, prot, tgt_flags,
tgt_fd, offset *
tc->getSystemPtr()->getPageBytes());
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/27367
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I75d9b32c0470d1907c68826ef81cf6cd46f60ea7
Gerrit-Change-Number: 27367
Gerrit-PatchSet: 1
Gerrit-Owner: Matthew Poremba
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[develop]: configs: Enabling SimObj CLI for baremetal platform
Giacomo Travaglini has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/27347 )
Change subject: configs: Enabling SimObj CLI for baremetal platform
..
configs: Enabling SimObj CLI for baremetal platform
Change-Id: I0d4059976c8fb6a1d796998af302eaa764609f86
Signed-off-by: Giacomo Travaglini
Reviewed-by: Ciro Santilli
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27347
Tested-by: Gem5 Cloud Project GCB service account
<345032938...@cloudbuild.gserviceaccount.com>
Tested-by: kokoro
---
M configs/example/arm/baremetal.py
1 file changed, 10 insertions(+), 0 deletions(-)
Approvals:
Ciro Santilli: Looks good to me, approved
Giacomo Travaglini: Looks good to me, approved
kokoro: Regressions pass
Gem5 Cloud Project GCB service account: Regressions pass
diff --git a/configs/example/arm/baremetal.py
b/configs/example/arm/baremetal.py
index 1eb2a82..87e8952 100644
--- a/configs/example/arm/baremetal.py
+++ b/configs/example/arm/baremetal.py
@@ -225,12 +225,22 @@
"(default: gem5's stderr)")
parser.add_argument("args", default=[], nargs="*",
help="Semihosting arguments to pass to benchmark")
+parser.add_argument("-P", "--param", action="append", default=[],
+help="Set a SimObject parameter relative to the root node. "
+ "An extended Python multi range slicing syntax can be used "
+ "for arrays. For example: "
+ "'system.cpu[0,1,3:8:2].max_insts_all_threads = 42' "
+ "sets max_insts_all_threads for cpus 0, 1, 3, 5 and 7 "
+ "Direct parameters of the root object are not accessible, "
+ "only parameters of its children.")
args = parser.parse_args()
root = Root(full_system=True)
root.system = create(args)
+root.apply_config(args.param)
+
if args.restore is not None:
m5.instantiate(args.restore)
else:
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/27347
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I0d4059976c8fb6a1d796998af302eaa764609f86
Gerrit-Change-Number: 27347
Gerrit-PatchSet: 2
Gerrit-Owner: Giacomo Travaglini
Gerrit-Reviewer: Ciro Santilli
Gerrit-Reviewer: Gem5 Cloud Project GCB service account
<345032938...@cloudbuild.gserviceaccount.com>
Gerrit-Reviewer: Giacomo Travaglini
Gerrit-Reviewer: kokoro
Gerrit-MessageType: merged
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[develop]: util: Update the m5 util Makefiles to not use javah.
Gabe Black has submitted this change. ( https://gem5-review.googlesource.com/c/public/gem5/+/27210 ) Change subject: util: Update the m5 util Makefiles to not use javah. .. util: Update the m5 util Makefiles to not use javah. In more recent versions of the JDK, the javah tool has been dropped. The same job can be accomplished by passing a -h option to javac, telling it where to put the header files javah would have generated. Change-Id: Ibc543d5fa222848458f45b1945f8050b85b77ca2 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27210 Maintainer: Jason Lowe-Power Tested-by: kokoro Reviewed-by: Daniel Carvalho --- M util/m5/src/Makefile.aarch64 M util/m5/src/Makefile.arm 2 files changed, 2 insertions(+), 6 deletions(-) Approvals: Daniel Carvalho: Looks good to me, approved Jason Lowe-Power: Looks good to me, approved kokoro: Regressions pass diff --git a/util/m5/src/Makefile.aarch64 b/util/m5/src/Makefile.aarch64 index c1c084d..7724b85 100644 --- a/util/m5/src/Makefile.aarch64 +++ b/util/m5/src/Makefile.aarch64 @@ -46,7 +46,6 @@ AR=$(CROSS_COMPILE)ar JC=javac -JH=javah JR=jar ### JDK_PATH must be set to build gem5OpJni #JDK_PATH=/path/to/jdk/version_number @@ -81,8 +80,7 @@ $(CC) --shared -o lib$@.so $(JNI_OBJS) gem5OpJni.jar: - $(JC) jni/gem5Op.java; \ - $(JH) jni.gem5Op; \ + $(JC) jni/gem5Op.java -h .; \ $(JR) cvf $@ jni/*.class lua_gem5Op.o: lua_gem5Op.c diff --git a/util/m5/src/Makefile.arm b/util/m5/src/Makefile.arm index 042cf00..2588f09 100644 --- a/util/m5/src/Makefile.arm +++ b/util/m5/src/Makefile.arm @@ -46,7 +46,6 @@ AR=$(CROSS_COMPILE)ar JC=javac -JH=javah JR=jar ### JDK_PATH must be set to build gem5OpJni #JDK_PATH=/path/to/jdk/version_number @@ -82,8 +81,7 @@ $(CC) --shared -o lib$@.so $(JNI_OBJS) gem5OpJni.jar: - $(JC) jni/gem5Op.java; \ - $(JH) jni.gem5Op; \ + $(JC) jni/gem5Op.java -h .; \ $(JR) cvf $@ jni/*.class lua_gem5Op.o: lua_gem5Op.c -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/27210 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: develop Gerrit-Change-Id: Ibc543d5fa222848458f45b1945f8050b85b77ca2 Gerrit-Change-Number: 27210 Gerrit-PatchSet: 4 Gerrit-Owner: Gabe Black Gerrit-Reviewer: Bobby R. Bruce Gerrit-Reviewer: Daniel Carvalho Gerrit-Reviewer: Earl Ou Gerrit-Reviewer: Gabe Black Gerrit-Reviewer: Giacomo Travaglini Gerrit-Reviewer: Jason Lowe-Power Gerrit-Reviewer: Yu-hsin Wang Gerrit-Reviewer: kokoro Gerrit-MessageType: merged ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[develop]: util, sparc: Use M5OP_FOREACH to define the m5op entry points for sparc.
Gabe Black has submitted this change. ( https://gem5-review.googlesource.com/c/public/gem5/+/27207 ) Change subject: util,sparc: Use M5OP_FOREACH to define the m5op entry points for sparc. .. util,sparc: Use M5OP_FOREACH to define the m5op entry points for sparc. Change-Id: I9b125c843425ef4a7a59061d5897dd8e83e06abb Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27207 Tested-by: kokoro Reviewed-by: Jason Lowe-Power Reviewed-by: Daniel Carvalho Maintainer: Bobby R. Bruce --- M util/m5/m5op_sparc.S 1 file changed, 13 insertions(+), 116 deletions(-) Approvals: Jason Lowe-Power: Looks good to me, but someone else must approve Daniel Carvalho: Looks good to me, approved Bobby R. Bruce: Looks good to me, approved kokoro: Regressions pass diff --git a/util/m5/m5op_sparc.S b/util/m5/m5op_sparc.S index fe70e0a..9ed9a99 100644 --- a/util/m5/m5op_sparc.S +++ b/util/m5/m5op_sparc.S @@ -31,120 +31,17 @@ #include -#define INST(func, rs1, rs2, rd) \ -.long (m5_op) << 30 | (rd) << 25 | (m5_op3) << 19 | (func) << 7 | \ - (rs1) << 14 | (rs2) << 0; +.macro m5op_func name, func +.section ".text"; +.align 4; +.global \name; +.type \name, #function; +\name: +retl +.long (m5_op) << 30 | (m5_op3) << 19 | (\func) << 7; +.size \name, (.-\name) +.endm - -#define LEAF(func)\ -.section ".text"; \ -.align 4; \ -.global func;\ -.typefunc, #function; \ -func: - -#define END(func) \ -.sizefunc, (.-func) - -#define DEBUGBREAK INST(M5OP_DEBUG_BREAK, 0, 0, 0) -#define M5EXIT INST(M5OP_EXIT, 0, 0, 0) -#define PANIC INST(M5OP_PANIC, 0, 0, 0) -#define READFILE INST(M5OP_READ_FILE, 0, 0, 0) - -LEAF(m5_exit) -retl -M5EXIT -END(m5_exit) - -LEAF(m5_panic) -retl -PANIC -END(m5_panic) - -LEAF(m5_read_file) -retl -READFILE -END(m5_read_file) - -LEAF(m5_debug_break) -retl -DEBUGBREAK -END(m5_debug_break) - -/* !! All code below here just panics !! */ -LEAF(m5_arm) -retl -PANIC -END(m5_arm) - -LEAF(m5_quiesce) -retl -PANIC -END(m5_quiesce) - -LEAF(m5_quiesce_ns) -retl -PANIC -END(m5_quiesce_ns) - -LEAF(m5_quiesce_cycle) -retl -PANIC -END(m5_quiesce_cycle) - -LEAF(m5_quiesce_time) -retl -PANIC -END(m5_quiesce_time) - -LEAF(m5_init_param) -retl -PANIC -END(m5_init_param) - -LEAF(m5_load_symbol) -retl -PANIC -END(m5_load_symbol) - -LEAF(m5_reset_stats) -retl -PANIC -END(m5_reset_stats) - -LEAF(m5_dump_stats) -retl -PANIC -END(m5_dump_stats) - -LEAF(m5_dump_reset_stats) -retl -PANIC -END(m5_dump_reset_stats) - -LEAF(m5_checkpoint) -retl -PANIC -END(m5_checkpoint) - -LEAF(m5_switch_cpu) -retl -PANIC -END(m5_switch_cpu) - -LEAF(m5_add_symbol) -retl -PANIC -END(m5_add_symbol) - -LEAF(m5_anbegin) -retl -PANIC -END(m5_anbegin) - -LEAF(m5_anwait) -retl -PANIC -END(m5_anwait) - - +#define M5OP(name, func) m5op_func name, func +M5OP_FOREACH +#undef M5OP -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/27207 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: develop Gerrit-Change-Id: I9b125c843425ef4a7a59061d5897dd8e83e06abb Gerrit-Change-Number: 27207 Gerrit-PatchSet: 4 Gerrit-Owner: Gabe Black Gerrit-Reviewer: Bobby R. Bruce Gerrit-Reviewer: Daniel Carvalho Gerrit-Reviewer: Earl Ou Gerrit-Reviewer: Gabe Black Gerrit-Reviewer: Giacomo Travaglini Gerrit-Reviewer: Jason Lowe-Power Gerrit-Reviewer: Yu-hsin Wang Gerrit-Reviewer: kokoro Gerrit-MessageType: merged ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Making the verification bit sicky(ier) in gerrit
I just went ahead and did it with git. I don't think going through the gerrit UI with the configuration as we have it now would have worked. Gabe On Wed, Apr 1, 2020 at 3:21 AM Gabe Black wrote: > That is definitely something that can (and has at least once) gone wrong, > but I know it can go wrong even with the current setup since it did :-) I'm > not 100% sure if this will work, but I tried to edit the configuration for > the label through the gerrit interface over here: > > https://gem5-review.googlesource.com/c/All-Projects/+/27330 > > I think it's still going to insist on the verification bit getting set on > that CL, but I don't think anything is going to pick it up and set that > bit... I might need to jam it in directly through git, or some other > hackery to make the actual change. > > Gabe > > On Wed, Apr 1, 2020 at 2:30 AM Giacomo Travaglini < > giacomo.travagl...@arm.com> wrote: > >> Name clash is not the only scenario where you have conflicting patches. >> It might be that I have two patches targeting different portions of the >> code where I am not breaking the build but I am breaking simulation. >> Two patches that work on their own but they break gem5 once combined. >> >> This is just to be accurate; there are definitely downsides but >> considering the frequency of these cases I am fine on trying to reduce the >> computational load >> >> Giacomo >> >> -Original Message- >> From: gem5-dev On Behalf Of Daniel Carvalho >> Sent: 01 April 2020 10:09 >> To: gem5 Developer List >> Subject: Re: [gem5-dev] Making the verification bit sicky(ier) in gerrit >> >> I believe that in the case 2 changes from different people add a >> variable with the same name to the same scope, the rebase could still be >> trivial, yet the second change will generate a compilation error due to >> variable declaration repetition. Similar situations (variable removal, >> things being done twice, etc) could raise other compilation errors, and >> even runtime errors. >> Anyway, I think this is quite rare (IIRC, a compilation error like this >> happened only once since I joined), and it will be caught right away on the >> following kokoro run, so the benefits far outweigh any potential issue. >> Regards,Daniel >> Em quarta-feira, 1 de abril de 2020 06:57:27 GMT+2, Bobby Bruce < >> bbr...@ucdavis.edu> escreveu: >> >> Sounds like a great idea to me. I fail to see any downside. >> -- >> Dr. Bobby R. Bruce >> Room 2235, >> Kemper Hall, UC Davis >> Davis, >> CA, 95616 >> >> web: https://www.bobbybruce.net >> >> >> On Tue, Mar 31, 2020 at 7:03 PM Gabe Black wrote: >> >> > Hi folks. I (and probably many of you) have noticed that gerrit >> > sometimes decides something needs to be rebased when it doesn't really >> > seem to, and that rebase ends up forcing a rerun of verification which >> > delays getting a patch checked in, and incurs extra cost for gem5 for >> > the compute resources which run the verification. >> > >> > I asked for potential solutions from the gerrit team within google, >> > and they suggested turning on this property of the verified label: >> > >> > >> > https://gerrit-review.googlesource.com/Documentation/config-labels.htm >> > l#label_copyAllScoresOnTrivialRebase >> > >> > They said that since we already have the "Rebase Always" merge >> > strategy selected it wouldn't reduce the level of verification for >> > changes, and while it wouldn't avoid having to do trivial rebases >> > (there's a button in gerrit for that), it would avoid having to rerun >> verification. >> > >> > Note that this would not make the verification label permanent, it >> > would just mean that as long as the rebase was trivial (no commit >> > message change, no diff change including context lines) then it would >> stay verified. >> > >> > Does that sound like a good idea to everyone? If so, I can look into >> > how to make that happen. >> > >> > Gabe >> > ___ >> > gem5-dev mailing list >> > gem5-dev@gem5.org >> > http://m5sim.org/mailman/listinfo/gem5-dev >> ___ >> gem5-dev mailing list >> gem5-dev@gem5.org >> http://m5sim.org/mailman/listinfo/gem5-dev >> ___ >> gem5-dev mailing list >> gem5-dev@gem5.org >> http://m5sim.org/mailman/listinfo/gem5-dev >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy the >> information in any medium. Thank you. >> ___ >> gem5-dev mailing list >> gem5-dev@gem5.org >> http://m5sim.org/mailman/listinfo/gem5-dev > > ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[develop]: util, x86: Use M5OP_FOREACH to define the m5op entry points for x86.
Gabe Black has submitted this change. ( https://gem5-review.googlesource.com/c/public/gem5/+/27208 ) Change subject: util,x86: Use M5OP_FOREACH to define the m5op entry points for x86. .. util,x86: Use M5OP_FOREACH to define the m5op entry points for x86. Change-Id: Idbfa3341a5e0d2cf57ce7dbe8cf45834b3aa067a Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27208 Tested-by: kokoro Reviewed-by: Jason Lowe-Power Reviewed-by: Daniel Carvalho Maintainer: Bobby R. Bruce --- M util/m5/m5op_x86.S 1 file changed, 3 insertions(+), 24 deletions(-) Approvals: Jason Lowe-Power: Looks good to me, approved Daniel Carvalho: Looks good to me, approved Bobby R. Bruce: Looks good to me, approved kokoro: Regressions pass diff --git a/util/m5/m5op_x86.S b/util/m5/m5op_x86.S index 453cdc9..cd83a94 100644 --- a/util/m5/m5op_x86.S +++ b/util/m5/m5op_x86.S @@ -79,27 +79,6 @@ #endif -TWO_BYTE_OP(m5_arm, M5OP_ARM) -TWO_BYTE_OP(m5_quiesce, M5OP_QUIESCE) -TWO_BYTE_OP(m5_quiesce_ns, M5OP_QUIESCE_NS) -TWO_BYTE_OP(m5_quiesce_cycle, M5OP_QUIESCE_CYCLE) -TWO_BYTE_OP(m5_quiesce_time, M5OP_QUIESCE_TIME) -TWO_BYTE_OP(m5_rpns, M5OP_RPNS) -TWO_BYTE_OP(m5_wake_cpu, M5OP_WAKE_CPU) -TWO_BYTE_OP(m5_exit, M5OP_EXIT) -TWO_BYTE_OP(m5_fail, M5OP_FAIL) -TWO_BYTE_OP(m5_init_param, M5OP_INIT_PARAM) -TWO_BYTE_OP(m5_load_symbol, M5OP_LOAD_SYMBOL) -TWO_BYTE_OP(m5_reset_stats, M5OP_RESET_STATS) -TWO_BYTE_OP(m5_dump_stats, M5OP_DUMP_STATS) -TWO_BYTE_OP(m5_dump_reset_stats, M5OP_DUMP_RESET_STATS) -TWO_BYTE_OP(m5_checkpoint, M5OP_CHECKPOINT) -TWO_BYTE_OP(m5_read_file, M5OP_READ_FILE) -TWO_BYTE_OP(m5_write_file, M5OP_WRITE_FILE) -TWO_BYTE_OP(m5_debug_break, M5OP_DEBUG_BREAK) -TWO_BYTE_OP(m5_switch_cpu, M5OP_SWITCH_CPU) -TWO_BYTE_OP(m5_add_symbol, M5OP_ADD_SYMBOL) -TWO_BYTE_OP(m5_panic, M5OP_PANIC) -TWO_BYTE_OP(m5_work_begin, M5OP_WORK_BEGIN) -TWO_BYTE_OP(m5_work_end, M5OP_WORK_END) -TWO_BYTE_OP(m5_dist_toggle_sync, M5OP_DIST_TOGGLE_SYNC) +#define M5OP(name, number) TWO_BYTE_OP(name, number) +M5OP_FOREACH +#undef M5OP -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/27208 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: develop Gerrit-Change-Id: Idbfa3341a5e0d2cf57ce7dbe8cf45834b3aa067a Gerrit-Change-Number: 27208 Gerrit-PatchSet: 4 Gerrit-Owner: Gabe Black Gerrit-Reviewer: Bobby R. Bruce Gerrit-Reviewer: Daniel Carvalho Gerrit-Reviewer: Earl Ou Gerrit-Reviewer: Gabe Black Gerrit-Reviewer: Giacomo Travaglini Gerrit-Reviewer: Jason Lowe-Power Gerrit-Reviewer: Yu-hsin Wang Gerrit-Reviewer: kokoro Gerrit-MessageType: merged ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[develop]: util: Update jni_gem5Op.c so it will compile again.
Gabe Black has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/27211 )
Change subject: util: Update jni_gem5Op.c so it will compile again.
..
util: Update jni_gem5Op.c so it will compile again.
The header for the m5op entry points had moved. Also the names of the
entry points had been normalized to have a consistent structure. Neither
of those changes were ported to this file, making it no longer compile.
Change-Id: I890c0486bd19fe2692cce92983290e854dc87afa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27211
Maintainer: Jason Lowe-Power
Tested-by: kokoro
Reviewed-by: Daniel Carvalho
---
M util/m5/src/jni_gem5Op.c
1 file changed, 15 insertions(+), 16 deletions(-)
Approvals:
Daniel Carvalho: Looks good to me, approved
Jason Lowe-Power: Looks good to me, approved
kokoro: Regressions pass
diff --git a/util/m5/src/jni_gem5Op.c b/util/m5/src/jni_gem5Op.c
index 4d10750..ba61fc0 100644
--- a/util/m5/src/jni_gem5Op.c
+++ b/util/m5/src/jni_gem5Op.c
@@ -37,42 +37,41 @@
#include
+#include "gem5/m5ops.h"
#include "jni_gem5Op.h"
-#include "m5op.h"
-/**
- C library interface for gem5Op JNI
-
-*/
+/*
+ * C library interface for gem5Op JNI
+ */
JNIEXPORT void JNICALL
Java_jni_gem5Op_arm(JNIEnv *env, jobject obj, jlong j_address)
{
-arm(j_address);
+m5_arm(j_address);
}
JNIEXPORT void JNICALL
Java_jni_gem5Op_quiesce(JNIEnv *env, jobject obj)
{
-quiesce();
+m5_quiesce();
}
JNIEXPORT void JNICALL
Java_jni_gem5Op_quiesceNs(JNIEnv *env, jobject obj, jlong j_ns)
{
-quiesceNs(j_ns);
+m5_quiesce_ns(j_ns);
}
JNIEXPORT void JNICALL
Java_jni_gem5Op_quiesceCycle(JNIEnv *env, jobject obj, jlong j_cycles)
{
-quiesceCycle(j_cycles);
+m5_quiesce_cycle(j_cycles);
}
JNIEXPORT jlong JNICALL
Java_jni_gem5Op_quiesceTime(JNIEnv *env, jobject obj)
{
-uint64_t time = quiesceTime();
+uint64_t time = m5_quiesce_time();
if (time & 0x8000ULL)
printf("Truncated return value from quiesceTime() to 63 bits\n");
return (time & 0x7FFFULL);
@@ -81,7 +80,7 @@
JNIEXPORT jlong JNICALL
Java_jni_gem5Op_rpns(JNIEnv *env, jobject obj)
{
-uint64_t time = rpns();
+uint64_t time = m5_rpns();
if (time & 0x8000ULL)
printf("Truncated return value from rpns() to 63 bits\n");
return (time & 0x7FFFULL);
@@ -90,7 +89,7 @@
JNIEXPORT void JNICALL
Java_jni_gem5Op_wakeCPU(JNIEnv *env, jobject obj, jlong j_cpuid)
{
-wakeCPU(j_cpuid);
+m5_wake_cpu(j_cpuid);
}
JNIEXPORT void JNICALL
@@ -109,7 +108,7 @@
Java_jni_gem5Op_initparam(JNIEnv *env, jobject obj, jlong j_key_str1,
jlong j_key_str2)
{
-uint64_t param = m5_initparam(j_key_str1, j_key_str2);
+uint64_t param = m5_init_param(j_key_str1, j_key_str2);
if (param & 0x8000ULL)
printf("Truncated return value from m_initparam() to 63 bits\n");
return (param & 0x7FFFULL);
@@ -140,19 +139,19 @@
Java_jni_gem5Op_dumpreset_1stats(JNIEnv *env, jobject obj,
jlong j_ns_delay, jlong j_ns_period)
{
-m5_dumpreset_stats(j_ns_delay, j_ns_period);
+m5_dump_reset_stats(j_ns_delay, j_ns_period);
}
JNIEXPORT void JNICALL
Java_jni_gem5Op_debugbreak(JNIEnv *env, jobject obj)
{
-m5_debugbreak();
+m5_debug_break();
}
JNIEXPORT void JNICALL
Java_jni_gem5Op_switchcpu (JNIEnv *env, jobject obj)
{
-m5_switchcpu();
+m5_switch_cpu();
}
JNIEXPORT void JNICALL
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/27211
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I890c0486bd19fe2692cce92983290e854dc87afa
Gerrit-Change-Number: 27211
Gerrit-PatchSet: 4
Gerrit-Owner: Gabe Black
Gerrit-Reviewer: Bobby R. Bruce
Gerrit-Reviewer: Daniel Carvalho
Gerrit-Reviewer: Earl Ou
Gerrit-Reviewer: Gabe Black
Gerrit-Reviewer: Giacomo Travaglini
Gerrit-Reviewer: Jason Lowe-Power
Gerrit-Reviewer: Yu-hsin Wang
Gerrit-Reviewer: kokoro
Gerrit-MessageType: merged
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[develop]: util: Move source files into a src directory.
Gabe Black has submitted this change. ( https://gem5-review.googlesource.com/c/public/gem5/+/27209 ) Change subject: util: Move source files into a src directory. .. util: Move source files into a src directory. This also moves the Makefiles, which will still produce build output in the src directory. This is to prepare for a scons based build system which will create a separate build directory with build artifacts. Change-Id: I7c6d325e1d0a428656b2e3070b5e942515543696 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27209 Tested-by: kokoro Reviewed-by: Daniel Carvalho Maintainer: Bobby R. Bruce --- R util/m5/src/Android.mk R util/m5/src/Makefile.aarch64 R util/m5/src/Makefile.arm R util/m5/src/Makefile.sparc R util/m5/src/Makefile.thumb R util/m5/src/Makefile.x86 R util/m5/src/jni/gem5Op.java R util/m5/src/jni_gem5Op.c R util/m5/src/lua_gem5Op.c R util/m5/src/m5.c R util/m5/src/m5_mmap.c R util/m5/src/m5_mmap.h R util/m5/src/m5op_arm.S R util/m5/src/m5op_arm_A64.S R util/m5/src/m5op_sparc.S R util/m5/src/m5op_x86.S 16 files changed, 5 insertions(+), 5 deletions(-) Approvals: Daniel Carvalho: Looks good to me, approved Bobby R. Bruce: Looks good to me, approved kokoro: Regressions pass diff --git a/util/m5/Android.mk b/util/m5/src/Android.mk similarity index 100% rename from util/m5/Android.mk rename to util/m5/src/Android.mk diff --git a/util/m5/Makefile.aarch64 b/util/m5/src/Makefile.aarch64 similarity index 98% rename from util/m5/Makefile.aarch64 rename to util/m5/src/Makefile.aarch64 index f0b6494..c1c084d 100644 --- a/util/m5/Makefile.aarch64 +++ b/util/m5/src/Makefile.aarch64 @@ -52,7 +52,7 @@ #JDK_PATH=/path/to/jdk/version_number CFLAGS=-O2 -I $(JDK_PATH)/include/ -I $(JDK_PATH)/include/linux \ - -I../../include -march=armv8-a + -I../../../include -march=armv8-a LDFLAGS=-static -L. -lm5 LIB_OBJS=m5op_arm_A64.o m5_mmap.o diff --git a/util/m5/Makefile.arm b/util/m5/src/Makefile.arm similarity index 98% rename from util/m5/Makefile.arm rename to util/m5/src/Makefile.arm index 1fd1840..042cf00 100644 --- a/util/m5/Makefile.arm +++ b/util/m5/src/Makefile.arm @@ -52,7 +52,7 @@ #JDK_PATH=/path/to/jdk/version_number CFLAGS=-O2 -I $(JDK_PATH)/include/ -I $(JDK_PATH)/include/linux \ - -I../../include -march=armv7-a + -I../../../include -march=armv7-a LDFLAGS=-L. -lm5 -static LIB_OBJS=m5op_arm.o m5_mmap.o diff --git a/util/m5/Makefile.sparc b/util/m5/src/Makefile.sparc similarity index 97% rename from util/m5/Makefile.sparc rename to util/m5/src/Makefile.sparc index 9f19db9..2424784 100644 --- a/util/m5/Makefile.sparc +++ b/util/m5/src/Makefile.sparc @@ -32,7 +32,7 @@ AS=$(CROSS_COMPILE)as LD=$(CROSS_COMPILE)ld -CFLAGS=-O2 -m64 -I../../include +CFLAGS=-O2 -m64 -I../../../include OBJS=m5.o m5op_sparc.o m5_mmap.o all: m5 diff --git a/util/m5/Makefile.thumb b/util/m5/src/Makefile.thumb similarity index 98% rename from util/m5/Makefile.thumb rename to util/m5/src/Makefile.thumb index 1d7ad51..1eb5b3d 100644 --- a/util/m5/Makefile.thumb +++ b/util/m5/src/Makefile.thumb @@ -46,7 +46,7 @@ AR=$(CROSS_COMPILE)ar #CFLAGS=-O2 -march=armv7 -mthumb -I../../include -CFLAGS=-O2 -mthumb -I../../include +CFLAGS=-O2 -mthumb -I../../../include LDFLAGS=-L. -lm5 OBJS=m5.o diff --git a/util/m5/Makefile.x86 b/util/m5/src/Makefile.x86 similarity index 97% rename from util/m5/Makefile.x86 rename to util/m5/src/Makefile.x86 index fae81bb..59493ce 100644 --- a/util/m5/Makefile.x86 +++ b/util/m5/src/Makefile.x86 @@ -28,7 +28,7 @@ AS=as LD=ld -CFLAGS?=-O2 -DM5OP_ADDR=0x -I../../include +CFLAGS?=-O2 -DM5OP_ADDR=0x -I../../../include OBJS=m5.o m5op_x86.o m5_mmap.o LUA_HEADER_INCLUDE=$(shell pkg-config --cflags-only-I lua51) LUA_OBJS=lua_gem5Op.opic m5op_x86.opic m5_mmap.opic diff --git a/util/m5/jni/gem5Op.java b/util/m5/src/jni/gem5Op.java similarity index 100% rename from util/m5/jni/gem5Op.java rename to util/m5/src/jni/gem5Op.java diff --git a/util/m5/jni_gem5Op.c b/util/m5/src/jni_gem5Op.c similarity index 100% rename from util/m5/jni_gem5Op.c rename to util/m5/src/jni_gem5Op.c diff --git a/util/m5/lua_gem5Op.c b/util/m5/src/lua_gem5Op.c similarity index 100% rename from util/m5/lua_gem5Op.c rename to util/m5/src/lua_gem5Op.c diff --git a/util/m5/m5.c b/util/m5/src/m5.c similarity index 100% rename from util/m5/m5.c rename to util/m5/src/m5.c diff --git a/util/m5/m5_mmap.c b/util/m5/src/m5_mmap.c similarity index 100% rename from util/m5/m5_mmap.c rename to util/m5/src/m5_mmap.c diff --git a/util/m5/m5_mmap.h b/util/m5/src/m5_mmap.h similarity index 100% rename from util/m5/m5_mmap.h rename to util/m5/src/m5_mmap.h diff --git a/util/m5/m5op_arm.S b/util/m5/src/m5op_arm.S similarity index 100% rename from util/m5/m5op_arm.S rename to util/m5/src/m5op_arm.S diff --git a/util/m5/m5op_arm_A64.S b/util/m5/src/m5op_arm_A64.S similarity index 100% rename from
[gem5-dev] Change in gem5/gem5[develop]: util: Undef M5OP at the end of assembly files that use M5OP_FOREACH.
Gabe Black has submitted this change. ( https://gem5-review.googlesource.com/c/public/gem5/+/27206 ) Change subject: util: Undef M5OP at the end of assembly files that use M5OP_FOREACH. .. util: Undef M5OP at the end of assembly files that use M5OP_FOREACH. This may not be necessary since M5OP is defined/used at the end of the function, but it's best to clean up after ourselves. Change-Id: I524d92cb8dc44c6004dfa8109f3b17f56dba763e Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27206 Tested-by: kokoro Reviewed-by: Daniel Carvalho Reviewed-by: Giacomo Travaglini Maintainer: Bobby R. Bruce --- M util/m5/m5op_arm.S M util/m5/m5op_arm_A64.S 2 files changed, 2 insertions(+), 0 deletions(-) Approvals: Giacomo Travaglini: Looks good to me, approved Daniel Carvalho: Looks good to me, approved Bobby R. Bruce: Looks good to me, approved kokoro: Regressions pass diff --git a/util/m5/m5op_arm.S b/util/m5/m5op_arm.S index b4f7fb3..bd3bb4d 100644 --- a/util/m5/m5op_arm.S +++ b/util/m5/m5op_arm.S @@ -62,3 +62,4 @@ .text #define M5OP(name, func) m5op_func name, func M5OP_FOREACH +#undef M5OP diff --git a/util/m5/m5op_arm_A64.S b/util/m5/m5op_arm_A64.S index 011da0a..c0224e2 100644 --- a/util/m5/m5op_arm_A64.S +++ b/util/m5/m5op_arm_A64.S @@ -61,3 +61,4 @@ .text #define M5OP(name, func) m5op_func name, func M5OP_FOREACH +#undef M5OP -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/27206 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: develop Gerrit-Change-Id: I524d92cb8dc44c6004dfa8109f3b17f56dba763e Gerrit-Change-Number: 27206 Gerrit-PatchSet: 4 Gerrit-Owner: Gabe Black Gerrit-Reviewer: Bobby R. Bruce Gerrit-Reviewer: Ciro Santilli Gerrit-Reviewer: Daniel Carvalho Gerrit-Reviewer: Earl Ou Gerrit-Reviewer: Gabe Black Gerrit-Reviewer: Giacomo Travaglini Gerrit-Reviewer: Jason Lowe-Power Gerrit-Reviewer: Yu-hsin Wang Gerrit-Reviewer: kokoro Gerrit-MessageType: merged ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[develop]: configs: Enabling SimObj CLI for baremetal platform
Hello Ciro Santilli,
I'd like you to do a code review. Please visit
https://gem5-review.googlesource.com/c/public/gem5/+/27347
to review the following change.
Change subject: configs: Enabling SimObj CLI for baremetal platform
..
configs: Enabling SimObj CLI for baremetal platform
Change-Id: I0d4059976c8fb6a1d796998af302eaa764609f86
Signed-off-by: Giacomo Travaglini
Reviewed-by: Ciro Santilli
---
M configs/example/arm/baremetal.py
1 file changed, 10 insertions(+), 0 deletions(-)
diff --git a/configs/example/arm/baremetal.py
b/configs/example/arm/baremetal.py
index 1eb2a82..87e8952 100644
--- a/configs/example/arm/baremetal.py
+++ b/configs/example/arm/baremetal.py
@@ -225,12 +225,22 @@
"(default: gem5's stderr)")
parser.add_argument("args", default=[], nargs="*",
help="Semihosting arguments to pass to benchmark")
+parser.add_argument("-P", "--param", action="append", default=[],
+help="Set a SimObject parameter relative to the root node. "
+ "An extended Python multi range slicing syntax can be used "
+ "for arrays. For example: "
+ "'system.cpu[0,1,3:8:2].max_insts_all_threads = 42' "
+ "sets max_insts_all_threads for cpus 0, 1, 3, 5 and 7 "
+ "Direct parameters of the root object are not accessible, "
+ "only parameters of its children.")
args = parser.parse_args()
root = Root(full_system=True)
root.system = create(args)
+root.apply_config(args.param)
+
if args.restore is not None:
m5.instantiate(args.restore)
else:
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/27347
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I0d4059976c8fb6a1d796998af302eaa764609f86
Gerrit-Change-Number: 27347
Gerrit-PatchSet: 1
Gerrit-Owner: Giacomo Travaglini
Gerrit-Reviewer: Ciro Santilli
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Making the verification bit sicky(ier) in gerrit
That is definitely something that can (and has at least once) gone wrong, but I know it can go wrong even with the current setup since it did :-) I'm not 100% sure if this will work, but I tried to edit the configuration for the label through the gerrit interface over here: https://gem5-review.googlesource.com/c/All-Projects/+/27330 I think it's still going to insist on the verification bit getting set on that CL, but I don't think anything is going to pick it up and set that bit... I might need to jam it in directly through git, or some other hackery to make the actual change. Gabe On Wed, Apr 1, 2020 at 2:30 AM Giacomo Travaglini < giacomo.travagl...@arm.com> wrote: > Name clash is not the only scenario where you have conflicting patches. > It might be that I have two patches targeting different portions of the > code where I am not breaking the build but I am breaking simulation. > Two patches that work on their own but they break gem5 once combined. > > This is just to be accurate; there are definitely downsides but > considering the frequency of these cases I am fine on trying to reduce the > computational load > > Giacomo > > -Original Message- > From: gem5-dev On Behalf Of Daniel Carvalho > Sent: 01 April 2020 10:09 > To: gem5 Developer List > Subject: Re: [gem5-dev] Making the verification bit sicky(ier) in gerrit > > I believe that in the case 2 changes from different people add a variable > with the same name to the same scope, the rebase could still be trivial, > yet the second change will generate a compilation error due to variable > declaration repetition. Similar situations (variable removal, things being > done twice, etc) could raise other compilation errors, and even runtime > errors. > Anyway, I think this is quite rare (IIRC, a compilation error like this > happened only once since I joined), and it will be caught right away on the > following kokoro run, so the benefits far outweigh any potential issue. > Regards,Daniel > Em quarta-feira, 1 de abril de 2020 06:57:27 GMT+2, Bobby Bruce < > bbr...@ucdavis.edu> escreveu: > > Sounds like a great idea to me. I fail to see any downside. > -- > Dr. Bobby R. Bruce > Room 2235, > Kemper Hall, UC Davis > Davis, > CA, 95616 > > web: https://www.bobbybruce.net > > > On Tue, Mar 31, 2020 at 7:03 PM Gabe Black wrote: > > > Hi folks. I (and probably many of you) have noticed that gerrit > > sometimes decides something needs to be rebased when it doesn't really > > seem to, and that rebase ends up forcing a rerun of verification which > > delays getting a patch checked in, and incurs extra cost for gem5 for > > the compute resources which run the verification. > > > > I asked for potential solutions from the gerrit team within google, > > and they suggested turning on this property of the verified label: > > > > > > https://gerrit-review.googlesource.com/Documentation/config-labels.htm > > l#label_copyAllScoresOnTrivialRebase > > > > They said that since we already have the "Rebase Always" merge > > strategy selected it wouldn't reduce the level of verification for > > changes, and while it wouldn't avoid having to do trivial rebases > > (there's a button in gerrit for that), it would avoid having to rerun > verification. > > > > Note that this would not make the verification label permanent, it > > would just mean that as long as the rebase was trivial (no commit > > message change, no diff change including context lines) then it would > stay verified. > > > > Does that sound like a good idea to everyone? If so, I can look into > > how to make that happen. > > > > Gabe > > ___ > > gem5-dev mailing list > > gem5-dev@gem5.org > > http://m5sim.org/mailman/listinfo/gem5-dev > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Making the verification bit sicky(ier) in gerrit
Name clash is not the only scenario where you have conflicting patches. It might be that I have two patches targeting different portions of the code where I am not breaking the build but I am breaking simulation. Two patches that work on their own but they break gem5 once combined. This is just to be accurate; there are definitely downsides but considering the frequency of these cases I am fine on trying to reduce the computational load Giacomo -Original Message- From: gem5-dev On Behalf Of Daniel Carvalho Sent: 01 April 2020 10:09 To: gem5 Developer List Subject: Re: [gem5-dev] Making the verification bit sicky(ier) in gerrit I believe that in the case 2 changes from different people add a variable with the same name to the same scope, the rebase could still be trivial, yet the second change will generate a compilation error due to variable declaration repetition. Similar situations (variable removal, things being done twice, etc) could raise other compilation errors, and even runtime errors. Anyway, I think this is quite rare (IIRC, a compilation error like this happened only once since I joined), and it will be caught right away on the following kokoro run, so the benefits far outweigh any potential issue. Regards,Daniel Em quarta-feira, 1 de abril de 2020 06:57:27 GMT+2, Bobby Bruce escreveu: Sounds like a great idea to me. I fail to see any downside. -- Dr. Bobby R. Bruce Room 2235, Kemper Hall, UC Davis Davis, CA, 95616 web: https://www.bobbybruce.net On Tue, Mar 31, 2020 at 7:03 PM Gabe Black wrote: > Hi folks. I (and probably many of you) have noticed that gerrit > sometimes decides something needs to be rebased when it doesn't really > seem to, and that rebase ends up forcing a rerun of verification which > delays getting a patch checked in, and incurs extra cost for gem5 for > the compute resources which run the verification. > > I asked for potential solutions from the gerrit team within google, > and they suggested turning on this property of the verified label: > > > https://gerrit-review.googlesource.com/Documentation/config-labels.htm > l#label_copyAllScoresOnTrivialRebase > > They said that since we already have the "Rebase Always" merge > strategy selected it wouldn't reduce the level of verification for > changes, and while it wouldn't avoid having to do trivial rebases > (there's a button in gerrit for that), it would avoid having to rerun > verification. > > Note that this would not make the verification label permanent, it > would just mean that as long as the rebase was trivial (no commit > message change, no diff change including context lines) then it would stay > verified. > > Does that sound like a good idea to everyone? If so, I can look into > how to make that happen. > > Gabe > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Making the verification bit sicky(ier) in gerrit
I believe that in the case 2 changes from different people add a variable with the same name to the same scope, the rebase could still be trivial, yet the second change will generate a compilation error due to variable declaration repetition. Similar situations (variable removal, things being done twice, etc) could raise other compilation errors, and even runtime errors. Anyway, I think this is quite rare (IIRC, a compilation error like this happened only once since I joined), and it will be caught right away on the following kokoro run, so the benefits far outweigh any potential issue. Regards,Daniel Em quarta-feira, 1 de abril de 2020 06:57:27 GMT+2, Bobby Bruce escreveu: Sounds like a great idea to me. I fail to see any downside. -- Dr. Bobby R. Bruce Room 2235, Kemper Hall, UC Davis Davis, CA, 95616 web: https://www.bobbybruce.net On Tue, Mar 31, 2020 at 7:03 PM Gabe Black wrote: > Hi folks. I (and probably many of you) have noticed that gerrit sometimes > decides something needs to be rebased when it doesn't really seem to, and > that rebase ends up forcing a rerun of verification which delays getting a > patch checked in, and incurs extra cost for gem5 for the compute resources > which run the verification. > > I asked for potential solutions from the gerrit team within google, and > they suggested turning on this property of the verified label: > > > https://gerrit-review.googlesource.com/Documentation/config-labels.html#label_copyAllScoresOnTrivialRebase > > They said that since we already have the "Rebase Always" merge strategy > selected it wouldn't reduce the level of verification for changes, and > while it wouldn't avoid having to do trivial rebases (there's a button in > gerrit for that), it would avoid having to rerun verification. > > Note that this would not make the verification label permanent, it would > just mean that as long as the rebase was trivial (no commit message change, > no diff change including context lines) then it would stay verified. > > Does that sound like a good idea to everyone? If so, I can look into how to > make that happen. > > Gabe > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
