[gem5-dev] Alpha ABI?
Hey, does anybody have some documentation tucked away somewhere which documents the Alpha ABI? I don't seem to have that anywhere, and the internet isn't being very helpful. Gabe ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] pending CLs
Hi folks. I have a lot of pending CLs in flight right now, I think about 70 of which are currently active. That's a lot, so I thought I'd point out the ones which, from my perspective, are the highest priority. Top priority would be this one, the next one in my GuestABI series: https://gem5-review.googlesource.com/c/public/gem5/+/23178 After that are the 6 GDB related ones currently starting here: https://gem5-review.googlesource.com/c/public/gem5/+/22118 Giacomo has been doing a great job reviewing those so far, but we're still crunching through them. Finally, it would be nice to get this one in to close out it's little peripheral series: https://gem5-review.googlesource.com/c/public/gem5/+/23361 Beyond that plowing into the remaining 60 or so GuestABI patches would be great. I've got a design doc for that mechanism which will hopefully make the rounds internally in the near future, and then I'll share it on gem5-dev to give folks a better idea of what's going on without having to decipher the code itself. But to reiterate, the top priority for me is that first one above. Getting that in is blocking some other work I'm trying to do with Fast Model, so sooner would be better than later. Gabe ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: sim: Make it possible for a GuestABI to init its Position based on a TC.
Gabe Black has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/23749 )
Change subject: sim: Make it possible for a GuestABI to init its Position
based on a TC.
..
sim: Make it possible for a GuestABI to init its Position based on a TC.
It may be necessary to initialize the GuestABI Position type based on
the current state of the thread, for instance by reading the current
stack pointer.
This change makes it possible (but not mandantory) for an ABI to supply
a constructor for Position which accepts a ThreadContext * which it can
use to intiialize itself.
Change-Id: I5609b185f746368c5f9eb2a04074dcafa088f925
---
M src/sim/guest_abi.hh
M src/sim/guest_abi.test.cc
2 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/src/sim/guest_abi.hh b/src/sim/guest_abi.hh
index 2dd27c4..5432af3 100644
--- a/src/sim/guest_abi.hh
+++ b/src/sim/guest_abi.hh
@@ -61,6 +61,32 @@
* std::enable_if style conditional specializations.
*/
+/*
+ * Position may need to be initialized based on the ThreadContext, for
instance
+ * to find out where the stack pointer is initially.
+ */
+template
+struct PositionInitializer
+{
+static typename ABI::Position
+init(const ThreadContext *tc)
+{
+return typename ABI::Position();
+}
+};
+
+template
+struct PositionInitializer+std::is_constructible*>::value
+>::type>
+{
+static typename ABI::Position
+init(const ThreadContext *tc)
+{
+return typename ABI::Position(tc);
+}
+};
+
template
struct Result
{
@@ -407,7 +433,7 @@
{
// Default construct a Position to track consumed resources. Built in
// types will be zero initialized.
-auto position = typename ABI::Position();
+auto position = GuestABI::PositionInitializer::init(tc);
GuestABI::ResultAllocator::allocate(tc, position);
return GuestABI::callFrom(tc, position, target);
}
@@ -427,7 +453,7 @@
{
// Default construct a Position to track consumed resources. Built in
// types will be zero initialized.
-auto position = typename ABI::Position();
+auto position = GuestABI::PositionInitializer::init(tc);
GuestABI::callFrom(tc, position, target);
}
@@ -450,7 +476,7 @@
std::function target=
std::function())
{
-auto position = typename ABI::Position();
+auto position = GuestABI::PositionInitializer::init(tc);
std::ostringstream ss;
GuestABI::ResultAllocator::allocate(tc, position);
diff --git a/src/sim/guest_abi.test.cc b/src/sim/guest_abi.test.cc
index 2f896f9..506163e 100644
--- a/src/sim/guest_abi.test.cc
+++ b/src/sim/guest_abi.test.cc
@@ -46,6 +46,8 @@
int intResult = DefaultIntResult;
double floatResult = DefaultFloatResult;
+
+int intOffset = 0;
};
const int ThreadContext::ints[] = {
@@ -80,6 +82,15 @@
using Position = std::pair;
};
+struct TestABI_TcInit
+{
+struct Position
+{
+int pos;
+Position(const ThreadContext *tc) : pos(tc->intOffset) {}
+};
+};
+
namespace GuestABI
{
@@ -188,6 +199,17 @@
}
};
+// Hooks for the TcInit ABI arguments.
+template <>
+struct Argument
+{
+static int
+get(ThreadContext *tc, TestABI_TcInit::Position )
+{
+return tc->ints[position.pos++];
+}
+};
+
} // namespace GuestABI
// Test function which verifies that its arguments reflect the 1D ABI and
@@ -237,6 +259,13 @@
EXPECT_EQ(varargs.get(), tc->floats[3]);
}
+void
+testTcInit(ThreadContext *tc, int a)
+{
+EXPECT_EQ(tc->intOffset, 2);
+EXPECT_EQ(a, tc->ints[2]);
+}
+
// Test functions which returns various types of values.
const int IntRetValue = 50;
const float FloatRetValue = 3.14;
@@ -271,6 +300,13 @@
EXPECT_EQ(tc.floatResult, tc.DefaultFloatResult);
}
+TEST(GuestABI, ABI_TC_init)
+{
+ThreadContext tc;
+tc.intOffset = 2;
+invokeSimcall(, testTcInit);
+}
+
TEST(GuestABI, ABI_returns)
{
// 1D returns.
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23749
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I5609b185f746368c5f9eb2a04074dcafa088f925
Gerrit-Change-Number: 23749
Gerrit-PatchSet: 1
Gerrit-Owner: Gabe Black
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: sim: Add a GuestABI mechanism to allocate space for a return value.
Gabe Black has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/23747 )
Change subject: sim: Add a GuestABI mechanism to allocate space for a
return value.
..
sim: Add a GuestABI mechanism to allocate space for a return value.
Some ABIs (including 32 bit ARM, 64 bit x86) allocate their argument
registers differently depending on their return value. For instance,
if the value needs to be returned in memory because it's too big,
the caller could pass a pointer to where the result should be stored
when the function returns. This pointer acts like an invisible first
argument, offsetting where all the normal arguments actually live.
This change adds a mechanism to handle that case. The Result templates
can now declare an allocate() static method which is given a
ThreadContext *, and a reference to the Position object. It can perform
any adjustment it needs to before the normal argument extraction
starts.
Change-Id: Ibda9095f0e8c9882742d24f5effe309ccb514188
---
M src/sim/guest_abi.hh
M src/sim/guest_abi.test.cc
2 files changed, 90 insertions(+), 0 deletions(-)
diff --git a/src/sim/guest_abi.hh b/src/sim/guest_abi.hh
index ff1464e..2dd27c4 100644
--- a/src/sim/guest_abi.hh
+++ b/src/sim/guest_abi.hh
@@ -74,8 +74,23 @@
* of this method which actually does something and is public.
*/
static void store(ThreadContext *tc, const Ret );
+
+/*
+ * Adjust the position of arguments based on the return type, if
necessary.
+ *
+ * This method can be excluded if no adjustment is necessary.
+ */
+static void allocate(ThreadContext *tc, typename ABI::Position
);
};
+/*
+ * This partial specialization prevents having to special case 'void' when
+ * working with return types.
+ */
+template
+struct Result
+{};
+
template
struct Argument
{
@@ -92,6 +107,35 @@
/*
+ * This struct template provides a default allocate() method in case the
+ * Result template doesn't provide one. This is the default in cases where
the
+ * return type doesn't affect how arguments are laid out.
+ */
+template
+struct ResultAllocator
+{
+static void
+allocate(ThreadContext *tc, typename ABI::Position )
+{}
+};
+
+/*
+ * If the return type *does* affect how the arguments are laid out, the ABI
+ * can implement an allocate() method for the various return types, and
this
+ * specialization will call into it.
+ */
+template
+struct ResultAllocatorRet>::allocate)>
+{
+static void
+allocate(ThreadContext *tc, typename ABI::Position )
+{
+Result::allocate(tc, position);
+}
+};
+
+
+/*
* These templates implement a variadic argument mechanism for guest ABI
* functions. A function might be written like this:
*
@@ -364,6 +408,7 @@
// Default construct a Position to track consumed resources. Built in
// types will be zero initialized.
auto position = typename ABI::Position();
+GuestABI::ResultAllocator::allocate(tc, position);
return GuestABI::callFrom(tc, position, target);
}
@@ -408,6 +453,7 @@
auto position = typename ABI::Position();
std::ostringstream ss;
+GuestABI::ResultAllocator::allocate(tc, position);
ss << name;
GuestABI::dumpArgsFrom(0, ss, tc, position);
return ss.str();
diff --git a/src/sim/guest_abi.test.cc b/src/sim/guest_abi.test.cc
index 19efb7d..2f896f9 100644
--- a/src/sim/guest_abi.test.cc
+++ b/src/sim/guest_abi.test.cc
@@ -66,6 +66,12 @@
using Position = int;
};
+// ABI anchor for an ABI which allocates a register for non-void return
types.
+struct TestABI_RetReg
+{
+using Position = int;
+};
+
// ABI anchor for an ABI which has 2D progress. Conceptually, this could be
// because integer and floating point arguments are stored in separate
// registers.
@@ -121,6 +127,22 @@
}
};
+// Hooks for the return value allocating ABI. It uses the same rules as the
+// 1D ABI for arguments, but allocates space for and discards return
values.
+template
+struct Argument : public Argument {};
+
+template
+struct Result
+{
+static void store(ThreadContext *tc, const Ret ) {}
+static void
+allocate(ThreadContext *tc, TestABI_RetReg::Position )
+{
+position++;
+}
+};
+
// Hooks for the 2D ABI arguments and return value. Add 2 or 2.0 to return
// values so we can tell they went through the right set of hooks.
@@ -184,6 +206,21 @@
EXPECT_EQ(varargs.get(), tc->floats[6]);
}
+// Test functions which verify that the return allocating ABI allocates
space
+// for its return value successfully.
+void
+testRetRegVoid(ThreadContext *tc, int a)
+{
+EXPECT_EQ(a, tc->ints[0]);
+}
+
+int
+testRetRegInt(ThreadContext *tc, int a)
+{
+EXPECT_EQ(a, tc->ints[1]);
+return 0;
+}
+
// Test function which verifies that its arguments reflect the 2D ABI and
// which doesn't return anything.
void
@@ -219,6 +256,13 @@
[gem5-dev] Change in gem5/gem5[master]: kern: Stop using a pseudo instruction to quiesce the ThreadContext.
Gabe Black has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/23748 )
Change subject: kern: Stop using a pseudo instruction to quiesce the
ThreadContext.
..
kern: Stop using a pseudo instruction to quiesce the ThreadContext.
The pseudo instruction implementation is very short, and so doing the
work it was doing directly doesn't really add much to the
implementation of the udelay events. By not calling the pseudo
instruction we also uncouple these unrelated mechanisms and don't,
for instance, cause pseudo instruction debug output every time udelay
executes.
Change-Id: I5c9b32509562487e53b2acfa1a3f6226d33d1cfd
---
M src/kern/freebsd/events.cc
M src/kern/linux/events.cc
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/src/kern/freebsd/events.cc b/src/kern/freebsd/events.cc
index 15954d6..a9e2854 100644
--- a/src/kern/freebsd/events.cc
+++ b/src/kern/freebsd/events.cc
@@ -40,7 +40,6 @@
#include "debug/DebugPrintf.hh"
#include "kern/system_events.hh"
#include "sim/arguments.hh"
-#include "sim/pseudo_inst.hh"
#include "sim/system.hh"
namespace FreeBSD {
@@ -69,9 +68,8 @@
// __delay and __loop_delay functions. One form involves setting
quiesce
// time to 0 with the assumption that quiesce will not happen. To avoid
// the quiesce handling in this case, only execute the quiesce if time
0.
-if (time > 0) {
-PseudoInst::quiesceNs(tc, time);
-}
+if (time > 0)
+tc->quiesceTick(curTick() + SimClock::Int::ns * time);
}
} // namespace FreeBSD
diff --git a/src/kern/linux/events.cc b/src/kern/linux/events.cc
index f4e6944..8c5fe33 100644
--- a/src/kern/linux/events.cc
+++ b/src/kern/linux/events.cc
@@ -55,7 +55,7 @@
#include "kern/linux/printk.hh"
#include "kern/system_events.hh"
#include "sim/arguments.hh"
-#include "sim/pseudo_inst.hh"
+#include "sim/core.hh"
#include "sim/system.hh"
namespace Linux {
@@ -93,9 +93,8 @@
// __delay and __loop_delay functions. One form involves setting
quiesce
// time to 0 with the assumption that quiesce will not happen. To avoid
// the quiesce handling in this case, only execute the quiesce if time
0.
-if (time > 0) {
-PseudoInst::quiesceNs(tc, time);
-}
+if (time > 0)
+tc->quiesceTick(curTick() + SimClock::Int::ns * time);
}
void
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23748
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I5c9b32509562487e53b2acfa1a3f6226d33d1cfd
Gerrit-Change-Number: 23748
Gerrit-PatchSet: 1
Gerrit-Owner: Gabe Black
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: arm: Implement the AAPCS64 ABI.
Gabe Black has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/23751 )
Change subject: arm: Implement the AAPCS64 ABI.
..
arm: Implement the AAPCS64 ABI.
This implementation has been tested a tiny bit by intercepting a call
which passed an argument of this type to a function.
struct Test
{
int32_t a;
float *b;
};
The gem5 intercept printed out the value of a, the value of b, and the
value of the float it pointed to.
I was able to get things to work by commenting out the panic in
fixFuncEventAddr and making it return its argument unmodified, and by
calling addFuncEvent instead of addKernelFuncEvent which injects the
kernel symbol table. I substitured the Process's debugSymbolTable which
had the right symbols.
Note that this implementation is not completely correct. First of all,
I used a dummy type in place of the Short Vector type which is just
a byte array with the appropriate alignment forced on it. It sounds
like this type would be something the compiler would need an intrinsic
and architecture specific type for to behave correctly, and so in
gem5 we'd have to define our own type for ARM which could feed in here.
Also, strictly speaking, it sounds like HVA and HFA category of types,
the Homogeneous Short-Vector Aggregates and Homogeneous Floating-point
Aggregates, are supposed to apply to any type which is an aggregate of
all the same type (short vector for one, floating point for the other)
with 4 or fewer members.
In this implementation, I capture any *array* of 4 or fewer elements of
the appropriate type as an HVA or HFA, but I believe these structures
would also count and are not included in my implementation.
struct {
float a;
float b;
float c;
};
struct {
ShortVector a;
ShortVector b;
};
This only matters if those sorts of structures are passed by value as
top level arguments to a function, ie they are not included in some
larger structure.
Also, rule B.6 talks about what to do with an "aignment adjusted type",
and I have no idea what that's supposed to be. Those may not be handled
correctly either.
Change-Id: I5a599a03d38075d7c0a06988c05e7fb5423c68c0
---
A src/arch/arm/aapcs64.hh
1 file changed, 399 insertions(+), 0 deletions(-)
diff --git a/src/arch/arm/aapcs64.hh b/src/arch/arm/aapcs64.hh
new file mode 100644
index 000..12c9d99
--- /dev/null
+++ b/src/arch/arm/aapcs64.hh
@@ -0,0 +1,399 @@
+/*
+ * Copyright 2019 Google Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
+ * met: redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer;
+ * redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution;
+ * neither the name of the copyright holders nor the names of its
+ * contributors may be used to endorse or promote products derived from
+ * this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * Authors: Gabe Black
+ */
+
+#ifndef __ARCH_ARM_AAPCS64_HH__
+#define __ARCH_ARM_AAPCS64_HH__
+
+#include
+#include
+#include
+#include
+
+#include "arch/arm/intregs.hh"
+#include "arch/arm/utility.hh"
+#include "base/intmath.hh"
+#include "cpu/thread_context.hh"
+#include "sim/guest_abi.hh"
+#include "sim/syscall_emul_buf.hh"
+
+class ThreadContext;
+
+struct Aapcs64
+{
+struct Position
+{
+int ngrn=0; // Next general purpose register number.
+int nsrn=0; // Next SIMD and floating point register number.
+Addr nsaa; // Next stacked argument address.
+
+// The maximum allowed general purpose register number.
+static const int MAX_GRN = 7;
+// The maximum allowed SIMD and floating point register number.
+static const int MAX_SRN = 7;
+
+explicit Position(const ThreadContext *tc) :
+nsaa(tc->readIntReg(ArmISA::INTREG_SPX))
+{}
+};
+};
+
[gem5-dev] Change in gem5/gem5[master]: sim: Add a typetraits style mechanism to test for VarArgs.
Gabe Black has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/23750 )
Change subject: sim: Add a typetraits style mechanism to test for VarArgs.
..
sim: Add a typetraits style mechanism to test for VarArgs.
This family of types can be cumbersome to check for when building
ABI rules. This struct template makes that a little easier.
Change-Id: Ic3a1b8424f8ca04564f8228365371b357f33276c
---
M src/sim/guest_abi.hh
M src/sim/guest_abi.test.cc
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/src/sim/guest_abi.hh b/src/sim/guest_abi.hh
index 5432af3..9726c49 100644
--- a/src/sim/guest_abi.hh
+++ b/src/sim/guest_abi.hh
@@ -284,6 +284,12 @@
}
};
+template
+struct IsVarArgs : public std::false_type {};
+
+template
+struct IsVarArgs> : public std::true_type {};
+
template
std::ostream &
operator << (std::ostream , const VarArgs )
diff --git a/src/sim/guest_abi.test.cc b/src/sim/guest_abi.test.cc
index 506163e..bd444aa 100644
--- a/src/sim/guest_abi.test.cc
+++ b/src/sim/guest_abi.test.cc
@@ -362,3 +362,14 @@
std::string dump = dumpSimcall("test", , testIntVoid);
EXPECT_EQ(dump, "test(0, 11, 2, 13, ...)");
}
+
+TEST(GuestABI, isVarArgs)
+{
+EXPECT_TRUE(GuestABI::IsVarArgs>::value);
+EXPECT_FALSE(GuestABI::IsVarArgs::value);
+EXPECT_FALSE(GuestABI::IsVarArgs::value);
+struct FooStruct {};
+EXPECT_FALSE(GuestABI::IsVarArgs::value);
+union FooUnion {};
+EXPECT_FALSE(GuestABI::IsVarArgs::value);
+}
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23750
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: Ic3a1b8424f8ca04564f8228365371b357f33276c
Gerrit-Change-Number: 23750
Gerrit-PatchSet: 1
Gerrit-Owner: Gabe Black
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: arm: Delete the unused onKvmExitHypercall method.
Gabe Black has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/23746 )
Change subject: arm: Delete the unused onKvmExitHypercall method.
..
arm: Delete the unused onKvmExitHypercall method.
The KVM_EXIT_HYPERCALL KVM exit is now unused, and so even if this
exit handler was plumbed to receive these exits, they would probably
never come.
Change-Id: Ic3ecc789102e761a6dbe80caaf57d61dd95f70a6
---
M src/arch/arm/kvm/arm_cpu.cc
M src/arch/arm/kvm/arm_cpu.hh
2 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/src/arch/arm/kvm/arm_cpu.cc b/src/arch/arm/kvm/arm_cpu.cc
index 80576a2..46c7e0a 100644
--- a/src/arch/arm/kvm/arm_cpu.cc
+++ b/src/arch/arm/kvm/arm_cpu.cc
@@ -312,26 +312,6 @@
updateTCStateMisc();
}
-Tick
-ArmKvmCPU::onKvmExitHypercall()
-{
-ThreadContext *tc(getContext(0));
-const uint32_t reg_ip(tc->readIntRegFlat(INTREG_R12));
-const uint8_t func((reg_ip >> 8) & 0xFF);
-
-DPRINTF(Kvm, "KVM Hypercall: %#x/%#x\n", func, subfunc);
-const uint64_t ret =
-PseudoInst::pseudoInst(getContext(0), func);
-
-// Just set the return value using the KVM API instead of messing
-// with the context. We could have used the context, but that
-// would have required us to request a full context sync.
-setOneReg(REG_CORE32(usr_regs.ARM_r0), ret & 0x);
-setOneReg(REG_CORE32(usr_regs.ARM_r1), (ret >> 32) & 0x);
-
-return 0;
-}
-
const ArmKvmCPU::RegIndexVector &
ArmKvmCPU::getRegList() const
{
diff --git a/src/arch/arm/kvm/arm_cpu.hh b/src/arch/arm/kvm/arm_cpu.hh
index f567214..bf8cce1 100644
--- a/src/arch/arm/kvm/arm_cpu.hh
+++ b/src/arch/arm/kvm/arm_cpu.hh
@@ -94,8 +94,6 @@
void updateKvmState();
void updateThreadContext();
-Tick onKvmExitHypercall();
-
/**
* Get a list of registers supported by getOneReg() and setOneReg().
*/
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23746
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: Ic3ecc789102e761a6dbe80caaf57d61dd95f70a6
Gerrit-Change-Number: 23746
Gerrit-PatchSet: 1
Gerrit-Owner: Gabe Black
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: tests: Setup Kokoro to run the GTest suite.
Bobby R. Bruce has submitted this change. ( https://gem5-review.googlesource.com/c/public/gem5/+/23724 ) Change subject: tests: Setup Kokoro to run the GTest suite. .. tests: Setup Kokoro to run the GTest suite. Change-Id: If700eed24b2902d04a9b0ee72b72e9e6a3472ef5 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23724 Reviewed-by: Daniel Carvalho Reviewed-by: Jason Lowe-Power Maintainer: Jason Lowe-Power Tested-by: kokoro --- M tests/jenkins/presubmit.sh 1 file changed, 2 insertions(+), 1 deletion(-) Approvals: Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved Daniel Carvalho: Looks good to me, approved kokoro: Regressions pass diff --git a/tests/jenkins/presubmit.sh b/tests/jenkins/presubmit.sh index e76aa4c..f564bc4 100755 --- a/tests/jenkins/presubmit.sh +++ b/tests/jenkins/presubmit.sh @@ -47,4 +47,5 @@ # Build with 4 threads (i.e., pass -j4 to scons) # Run 4 tests in parallel # Look for tests in the gem5 subdirectory -./main.py run -j4 -t4 gem5 +# Once complete, run the Google Tests +./main.py run -j4 -t4 gem5 && scons -C .. build/NULL/unittests.opt -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23724 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: If700eed24b2902d04a9b0ee72b72e9e6a3472ef5 Gerrit-Change-Number: 23724 Gerrit-PatchSet: 2 Gerrit-Owner: Bobby R. Bruce Gerrit-Reviewer: Bobby R. Bruce Gerrit-Reviewer: Daniel Carvalho Gerrit-Reviewer: Jason Lowe-Power Gerrit-Reviewer: Rahul Thakur 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[master]: scons: Added channel_addr.cc dependency to channel_addr GTest
Bobby R. Bruce has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/23603 )
Change subject: scons: Added channel_addr.cc dependency to channel_addr
GTest
..
scons: Added channel_addr.cc dependency to channel_addr GTest
In some circumstances not including channel_addr.cc as a dependency for
the channel_addr.test compilation resulted in a build failure (this was
observed in gem5's Kokoro CI system). This commit fixes this problem.
Change-Id: Ic38a104a1e6bf655fc64158b556e6227d5ac3981
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23603
Reviewed-by: Daniel Carvalho
Reviewed-by: Jason Lowe-Power
Maintainer: Jason Lowe-Power
Tested-by: kokoro
---
M src/base/SConscript
1 file changed, 1 insertion(+), 1 deletion(-)
Approvals:
Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
Daniel Carvalho: Looks good to me, approved
kokoro: Regressions pass
diff --git a/src/base/SConscript b/src/base/SConscript
index e2a3215..818428e 100644
--- a/src/base/SConscript
+++ b/src/base/SConscript
@@ -98,7 +98,7 @@
GTest('addr_range.test', 'addr_range.test.cc')
GTest('addr_range_map.test', 'addr_range_map.test.cc')
GTest('bitunion.test', 'bitunion.test.cc')
-GTest('channel_addr.test', 'channel_addr.test.cc')
+GTest('channel_addr.test', 'channel_addr.test.cc', 'channel_addr.cc')
GTest('circlebuf.test', 'circlebuf.test.cc')
GTest('circular_queue.test', 'circular_queue.test.cc')
GTest('sat_counter.test', 'sat_counter.test.cc')
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23603
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: Ic38a104a1e6bf655fc64158b556e6227d5ac3981
Gerrit-Change-Number: 23603
Gerrit-PatchSet: 4
Gerrit-Owner: Bobby R. Bruce
Gerrit-Reviewer: Bobby R. Bruce
Gerrit-Reviewer: Daniel Carvalho
Gerrit-Reviewer: Jason Lowe-Power
Gerrit-Reviewer: Rahul Thakur
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[master]: fastmodel: Add a header for IRIS MSN constants.
Gabe Black has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/23643 )
Change subject: fastmodel: Add a header for IRIS MSN constants.
..
fastmodel: Add a header for IRIS MSN constants.
Change-Id: I06a7d7db95ec1ce65945c9e09f812f0b69aaa8e6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23643
Reviewed-by: Gabe Black
Reviewed-by: Giacomo Travaglini
Maintainer: Gabe Black
Maintainer: Giacomo Travaglini
Tested-by: kokoro
---
A src/arch/arm/fastmodel/iris/memory_spaces.hh
1 file changed, 53 insertions(+), 0 deletions(-)
Approvals:
Gabe Black: Looks good to me, approved; Looks good to me, approved
Giacomo Travaglini: Looks good to me, approved; Looks good to me, approved
kokoro: Regressions pass
diff --git a/src/arch/arm/fastmodel/iris/memory_spaces.hh
b/src/arch/arm/fastmodel/iris/memory_spaces.hh
new file mode 100644
index 000..026904c
--- /dev/null
+++ b/src/arch/arm/fastmodel/iris/memory_spaces.hh
@@ -0,0 +1,53 @@
+/*
+ * Copyright 2019 Google, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
+ * met: redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer;
+ * redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution;
+ * neither the name of the copyright holders nor the names of its
+ * contributors may be used to endorse or promote products derived from
+ * this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * Authors: Gabe Black
+ */
+
+#ifndef __ARCH_ARM_FASTMODEL_IRIS_MEMORY_SPACES_HH__
+#define __ARCH_ARM_FASTMODEL_IRIS_MEMORY_SPACES_HH__
+
+namespace Iris
+{
+
+enum CanonicalMsn
+{
+SecureMonitorMsn = 0x1000,
+GuestMsn = 0x1001,
+NsHypMsn = 0x1002,
+MemoryMsn = 0x1003,
+HypAppMsn = 0x1004,
+HostMsn = 0x1005,
+CurrentMsn = 0x10ff,
+IpaMsn = 0x1100,
+PhysicalMemorySecureMsn = 0x1200,
+PhysicalMemoryNonSecureMsn = 0x1201,
+PhysicalMemoryMsn = 0x1202
+};
+
+} // namespace Iris
+
+#endif // __ARCH_ARM_FASTMODEL_IRIS_MEMORY_SPACES_HH__
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23643
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I06a7d7db95ec1ce65945c9e09f812f0b69aaa8e6
Gerrit-Change-Number: 23643
Gerrit-PatchSet: 4
Gerrit-Owner: Gabe Black
Gerrit-Reviewer: Andreas Sandberg
Gerrit-Reviewer: Chun-Chen TK Hsu
Gerrit-Reviewer: Gabe Black
Gerrit-Reviewer: Giacomo Travaglini
Gerrit-Reviewer: Jason Lowe-Power
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[master]: config: Default the indirect branch predictor to "None".
Gabe Black has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/23360 )
Change subject: config: Default the indirect branch predictor to "None".
..
config: Default the indirect branch predictor to "None".
Other scripts (like se.py) blindly try to apply the indirect predictor
if one is set. Because this option defaults to something, there's no
way (as far as I know) to purposefully select nothing, and so the
simulator crashes. Users shouldn't have to proactively prevent gem5
from killing itself regardless, so the default was changed to "None".
Change-Id: Ic3382b8065442d6705b1c6a656646598d9d5c322
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23360
Reviewed-by: Ciro Santilli
Reviewed-by: Giacomo Travaglini
Reviewed-by: Jason Lowe-Power
Maintainer: Jason Lowe-Power
Tested-by: kokoro
---
M configs/common/Options.py
1 file changed, 1 insertion(+), 2 deletions(-)
Approvals:
Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
Giacomo Travaglini: Looks good to me, approved
Ciro Santilli: Looks good to me, approved
kokoro: Regressions pass
diff --git a/configs/common/Options.py b/configs/common/Options.py
index 71d22a4..173bd48 100644
--- a/configs/common/Options.py
+++ b/configs/common/Options.py
@@ -183,8 +183,7 @@
type of branch predictor to run with
(if not set, use the default branch predictor of
the selected CPU)""")
-parser.add_option("--indirect-bp-type", type="choice",
- default="SimpleIndirectPredictor",
+parser.add_option("--indirect-bp-type", type="choice", default=None,
choices=ObjectList.indirect_bp_list.get_names(),
help = "type of indirect branch predictor to run
with")
parser.add_option("--list-hwp-types",
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23360
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: Ic3382b8065442d6705b1c6a656646598d9d5c322
Gerrit-Change-Number: 23360
Gerrit-PatchSet: 2
Gerrit-Owner: Gabe Black
Gerrit-Reviewer: Alexandru Duțu
Gerrit-Reviewer: Ciro Santilli
Gerrit-Reviewer: Gabe Black
Gerrit-Reviewer: Giacomo Travaglini
Gerrit-Reviewer: Jason Lowe-Power
Gerrit-Reviewer: kokoro
Gerrit-MessageType: merged
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] gem5 stable release proposal [PLEASE VOTE!]
On 16 Dec 2019, at 19:50, Jason Lowe-Power wrote: I think master should be development. I think gem5 should “”””release once per year (a release is not what you described the stable branch would be). I kept thinking ... feel free to ignore my 50 cents below: (i) I don’t want to fight the rest of the world treating git one way, where development is master. (ii) I am still not sure how “stable” will be screwed up 1 or 3 times a year if you “merge” “development” over a “stable” branch. If “stable” is “master” and the next pull accidentally ends on top of it it’ll be in conflict hell. Do you plan to point HEAD to development instead? Your plan very much sounds nice (fast forward) for the one having no changes in “stable” but horrible for anyone doing their work there. (iii) I am still not sure how referencing “one stable branch” can be named in a paper if you need a git hash or a date as well (sounds like CVS times). Even if you’d provide tags, any bugfix merges will still not be the same code. And in the end local modifications will mean it wasn’t gem5 “stable” but a local tree of a gem5 stable + changes (which also should be published). Like many I’ve seen plenty of research projects being done on a (stale) “stable” branch and once the research was done the work was forgotten or at best tarballed away or a “dead repo somewhere” and basically lost. I have seen few people doing their engineering for the research on development branch and then actually merging to stable and that’s usually the projects which are in use, cited often, look for something beyond a paper, .. Strangely this is also how release engineering usually seems to work. One will need to branch for once own research anyway, be it from master, development, or stable. If you work directly on master you simply screw yourself or you don’t use git. One will need to be able to diff ones own work to a “parent” in order to extract changes to be pushed to gem5 for upstreaming. If I work on a stable branch which gets a major upgrade in between, I need to solve those changes and conflicts first and then again against development when porting forward (which usually is a lot harder than back-porting)? I think gem5’s interest should be to make research easy and to engage the community to make their changes upstreamable so that the work is not lost but integrated and available for many. The big companies named do a great job of doing this, but how much 3rd party research community actually comes back into the tree? If I were to do gem5 research I’d do for 1 project (if you do multiple in parallel you do more sophisticated naming of multiple branches ;-): (a) branch development (ideally “master”) -> bz_master & do continuous changes and pull/merge regularly from upstream. (b) upstream all changes not needing “confidentiality” until publication (easy given they are based off the development branch). (c) pick the latest stable branch (which kind of implies there is a release structure again of say stable/20200401 or whatever name you give it. (d) make a branch if (c) bz_stable_20200401 and backport my changes to that. This is the branch I might be stuck with for 3-6 years for my research (think of a PhD lifetime in various parts of the world). In a real world I’ll probably have a bz_stable_20201001 by the time I finally get to the point when the 1st bit of engineering is done and I can write up a first paper. Either a forward port stable->stable or a backport to a different stable; the first real pain unless you chose wisely and your development branch basically matches your new stable branch at that point. (e) keep the cycle alive with back porting becoming harder and harder as the years go by. (f) publish and upstream rest of the changes. (g) go through the “review process, refine changes, ...” (h) Say paper 1/2/3. Peer reviewed. Work upstreamed to community, reviewed. Found mistake from 1st paper during that process, updated the results since. Being honest ;-) While your question of “what will be master?” seems important, the question you are asking is “do we want to be using the SCM system differently than most of the world raising the bar to entry just an extra bit?” If I look up there, I, as a developer and user, have totally different things to sort out than the default of a branch. /bz ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] gem5 stable release proposal [PLEASE VOTE!]
- I think master should be stable - I think gem5 should be released three times per year Regards,Daniel Em segunda-feira, 16 de dezembro de 2019 22:33:14 GMT+1, Bobby Bruce escreveu: * I think master should be stable * I think gem5 should be released three times per year -- Dr. Bobby R. Bruce Room 2235, Kemper Hall, UC Davis Davis, CA, 95616 On Mon, Dec 16, 2019 at 11:50 AM Jason Lowe-Power wrote: > Hi all, > > As many of you have seen on gem5-dev, we are going to be adding a > "stable" version of gem5. Below is the current proposal. There are a > couple of points below where there has not been general consensus > reached. We would appreciate feedback *from everyone in the community* > on the points where a decision hasn't been made below. gem5 is a > community-driven project, and we need feedback to make sure we're > making community-focused decisions. > > We will be introducing a new "stable" branch type to gem5. We are > doing this for the following reasons: > - Provide a way for developers to communicate major changes to the > code. We will be providing detailed release notes for each stable > release. > - Increase our test coverage. At each stable release, we will test a > large number of "common" benchmarks and configurations and publicize > the current state of gem5. > - Provide a way for researchers to communicate to the rest of the > community information about their simulation infrastructure (e.g., in > a paper you can say which version of gem5 you used). > > On the stable version of gem5, we will provide bugfixes until the > next release, but we will not make any API changes or add new > features. > > We would like your feedback on the following two questions: > > **Which branch should be default?** > > We can either have the master branch in git be the "stable" or the > "development" branch. If master is the stable branch, then it's easier > for users to get the most recent stable branch. If master is the > development branch, it's more familiar and easier for most developers. > Either way, we will be updating all of the documentation to make it > clear. > > Please let us know which you prefer by replying "I think master should > be stable" or "I think master should be development". > > **How often should we create a new gem5 release?** > > We can have a gem5 release once per year (likely in April) or three > times per year (April, August, and December). Once per year means that > if you use the stable branch you will get updates less frequently. > Three times per year will mean there are more releases to choose from > (but a newer release should always be better). On the development > side, I don't think one will be more work than the other. Once per > year means more backporting, and three times per year means more > testing and time spent on releases. > > Please let us know which you prefer by replying "I think gem5 should > be released once per year" or "I think gem5 should be released three > times per year." > > > > > A couple of notes to everyone who's been following the discussion on > the gem5-dev mailing list: > - We have dropped the proposal for major vs minor releases. Note that > there was some pushback on having only major releases when this was > proposed on the gem5 roadmap, but it sounded like the consensus was to > drop minor releases for now. > - We will still allow feature branches *in rare circumstances*. This > will be by request only (send mail to gem5-dev if you would like to > discuss adding a new branch), and the goal will be integration within > a few months. All code review will still happen in the open on gerrit. > The benefits will be > 1) rebases won't be required as you can just make changes to the head > of the branch > 2) many features take more than a few months to implement, so if it's > not ready by a release it can be pushed to the next > 3) large changes won't be hidden in AMD or Arm-specific repositories > and *anyone* will be able to request a branch. > > Thanks everyone for the discussions so far! It would be most useful to > hear back by the end of the week. However, I don't expect any concrete > actions will be taken until after the holidays. > > Cheers, > Jason > ___ > 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
[gem5-dev] Change in gem5/gem5[master]: tests: Setup Kokoro to run the GTest suite.
Bobby R. Bruce has uploaded this change for review. ( https://gem5-review.googlesource.com/c/public/gem5/+/23724 ) Change subject: tests: Setup Kokoro to run the GTest suite. .. tests: Setup Kokoro to run the GTest suite. Change-Id: If700eed24b2902d04a9b0ee72b72e9e6a3472ef5 --- M tests/jenkins/presubmit.sh 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/jenkins/presubmit.sh b/tests/jenkins/presubmit.sh index e76aa4c..f564bc4 100755 --- a/tests/jenkins/presubmit.sh +++ b/tests/jenkins/presubmit.sh @@ -47,4 +47,5 @@ # Build with 4 threads (i.e., pass -j4 to scons) # Run 4 tests in parallel # Look for tests in the gem5 subdirectory -./main.py run -j4 -t4 gem5 +# Once complete, run the Google Tests +./main.py run -j4 -t4 gem5 && scons -C .. build/NULL/unittests.opt -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23724 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: If700eed24b2902d04a9b0ee72b72e9e6a3472ef5 Gerrit-Change-Number: 23724 Gerrit-PatchSet: 1 Gerrit-Owner: Bobby R. Bruce Gerrit-MessageType: newchange ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] gem5 stable release proposal [PLEASE VOTE!]
* I think master should be stable * I think gem5 should be released three times per year -- Dr. Bobby R. Bruce Room 2235, Kemper Hall, UC Davis Davis, CA, 95616 On Mon, Dec 16, 2019 at 11:50 AM Jason Lowe-Power wrote: > Hi all, > > As many of you have seen on gem5-dev, we are going to be adding a > "stable" version of gem5. Below is the current proposal. There are a > couple of points below where there has not been general consensus > reached. We would appreciate feedback *from everyone in the community* > on the points where a decision hasn't been made below. gem5 is a > community-driven project, and we need feedback to make sure we're > making community-focused decisions. > > We will be introducing a new "stable" branch type to gem5. We are > doing this for the following reasons: > - Provide a way for developers to communicate major changes to the > code. We will be providing detailed release notes for each stable > release. > - Increase our test coverage. At each stable release, we will test a > large number of "common" benchmarks and configurations and publicize > the current state of gem5. > - Provide a way for researchers to communicate to the rest of the > community information about their simulation infrastructure (e.g., in > a paper you can say which version of gem5 you used). > > On the stable version of gem5, we will provide bugfixes until the > next release, but we will not make any API changes or add new > features. > > We would like your feedback on the following two questions: > > **Which branch should be default?** > > We can either have the master branch in git be the "stable" or the > "development" branch. If master is the stable branch, then it's easier > for users to get the most recent stable branch. If master is the > development branch, it's more familiar and easier for most developers. > Either way, we will be updating all of the documentation to make it > clear. > > Please let us know which you prefer by replying "I think master should > be stable" or "I think master should be development". > > **How often should we create a new gem5 release?** > > We can have a gem5 release once per year (likely in April) or three > times per year (April, August, and December). Once per year means that > if you use the stable branch you will get updates less frequently. > Three times per year will mean there are more releases to choose from > (but a newer release should always be better). On the development > side, I don't think one will be more work than the other. Once per > year means more backporting, and three times per year means more > testing and time spent on releases. > > Please let us know which you prefer by replying "I think gem5 should > be released once per year" or "I think gem5 should be released three > times per year." > > > > > A couple of notes to everyone who's been following the discussion on > the gem5-dev mailing list: > - We have dropped the proposal for major vs minor releases. Note that > there was some pushback on having only major releases when this was > proposed on the gem5 roadmap, but it sounded like the consensus was to > drop minor releases for now. > - We will still allow feature branches *in rare circumstances*. This > will be by request only (send mail to gem5-dev if you would like to > discuss adding a new branch), and the goal will be integration within > a few months. All code review will still happen in the open on gerrit. > The benefits will be > 1) rebases won't be required as you can just make changes to the head > of the branch > 2) many features take more than a few months to implement, so if it's > not ready by a release it can be pushed to the next > 3) large changes won't be hidden in AMD or Arm-specific repositories > and *anyone* will be able to request a branch. > > Thanks everyone for the discussions so far! It would be most useful to > hear back by the end of the week. However, I don't expect any concrete > actions will be taken until after the holidays. > > Cheers, > Jason > ___ > 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] [gem5-users] gem5 stable release proposal [PLEASE VOTE!]
Hi Jason, "I think master should be stable"as common case should be to use gem5 and not to dev it. "I think gem5 should be released three times per year." as I assume there would be too much to digest after one year. Best, On Mon, Dec 16, 2019 at 12:21 PM Tao Zhang wrote: > Hi Jason, > > Thanks for the proposal. > > Regarding the branch option for stable release, can we do it by git > tagging? > > I think one-release per year is too long. I prefer three-release per year. > > Thanks, > > -Tao > > > On Mon, Dec 16, 2019 at 11:50 AM Jason Lowe-Power > wrote: > >> Hi all, >> >> As many of you have seen on gem5-dev, we are going to be adding a >> "stable" version of gem5. Below is the current proposal. There are a >> couple of points below where there has not been general consensus >> reached. We would appreciate feedback *from everyone in the community* >> on the points where a decision hasn't been made below. gem5 is a >> community-driven project, and we need feedback to make sure we're >> making community-focused decisions. >> >> We will be introducing a new "stable" branch type to gem5. We are >> doing this for the following reasons: >> - Provide a way for developers to communicate major changes to the >> code. We will be providing detailed release notes for each stable >> release. >> - Increase our test coverage. At each stable release, we will test a >> large number of "common" benchmarks and configurations and publicize >> the current state of gem5. >> - Provide a way for researchers to communicate to the rest of the >> community information about their simulation infrastructure (e.g., in >> a paper you can say which version of gem5 you used). >> >> On the stable version of gem5, we will provide bugfixes until the >> next release, but we will not make any API changes or add new >> features. >> >> We would like your feedback on the following two questions: >> >> **Which branch should be default?** >> >> We can either have the master branch in git be the "stable" or the >> "development" branch. If master is the stable branch, then it's easier >> for users to get the most recent stable branch. If master is the >> development branch, it's more familiar and easier for most developers. >> Either way, we will be updating all of the documentation to make it >> clear. >> >> Please let us know which you prefer by replying "I think master should >> be stable" or "I think master should be development". >> >> **How often should we create a new gem5 release?** >> >> We can have a gem5 release once per year (likely in April) or three >> times per year (April, August, and December). Once per year means that >> if you use the stable branch you will get updates less frequently. >> Three times per year will mean there are more releases to choose from >> (but a newer release should always be better). On the development >> side, I don't think one will be more work than the other. Once per >> year means more backporting, and three times per year means more >> testing and time spent on releases. >> >> Please let us know which you prefer by replying "I think gem5 should >> be released once per year" or "I think gem5 should be released three >> times per year." >> >> >> >> >> A couple of notes to everyone who's been following the discussion on >> the gem5-dev mailing list: >> - We have dropped the proposal for major vs minor releases. Note that >> there was some pushback on having only major releases when this was >> proposed on the gem5 roadmap, but it sounded like the consensus was to >> drop minor releases for now. >> - We will still allow feature branches *in rare circumstances*. This >> will be by request only (send mail to gem5-dev if you would like to >> discuss adding a new branch), and the goal will be integration within >> a few months. All code review will still happen in the open on gerrit. >> The benefits will be >> 1) rebases won't be required as you can just make changes to the head >> of the branch >> 2) many features take more than a few months to implement, so if it's >> not ready by a release it can be pushed to the next >> 3) large changes won't be hidden in AMD or Arm-specific repositories >> and *anyone* will be able to request a branch. >> >> Thanks everyone for the discussions so far! It would be most useful to >> hear back by the end of the week. However, I don't expect any concrete >> actions will be taken until after the holidays. >> >> Cheers, >> Jason >> ___ >> gem5-users mailing list >> gem5-us...@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > ___ > gem5-users mailing list > gem5-us...@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users -- Pouya Fotouhi PhD Candidate Department of Electrical and Computer Engineering University of California, Davis ___ gem5-dev mailing list gem5-dev@gem5.org
Re: [gem5-dev] gem5 stable release proposal [PLEASE VOTE!]
- "I think master should be stable" - "I think gem5 should be released three times per year." Matt On Mon, Dec 16, 2019 at 1:57 PM Abhishek Singh < abhishek.singh199...@gmail.com> wrote: > Hello Jason, > Thanks for such a nice and detailed explanation. > My votes are as follows: > > > *I think master should be development* > > > *I think gem5 should be released once per year* > > > Best regards, > > Abhishek > > > On Mon, Dec 16, 2019 at 2:50 PM Jason Lowe-Power > wrote: > > > Hi all, > > > > As many of you have seen on gem5-dev, we are going to be adding a > > "stable" version of gem5. Below is the current proposal. There are a > > couple of points below where there has not been general consensus > > reached. We would appreciate feedback *from everyone in the community* > > on the points where a decision hasn't been made below. gem5 is a > > community-driven project, and we need feedback to make sure we're > > making community-focused decisions. > > > > We will be introducing a new "stable" branch type to gem5. We are > > doing this for the following reasons: > > - Provide a way for developers to communicate major changes to the > > code. We will be providing detailed release notes for each stable > > release. > > - Increase our test coverage. At each stable release, we will test a > > large number of "common" benchmarks and configurations and publicize > > the current state of gem5. > > - Provide a way for researchers to communicate to the rest of the > > community information about their simulation infrastructure (e.g., in > > a paper you can say which version of gem5 you used). > > > > On the stable version of gem5, we will provide bugfixes until the > > next release, but we will not make any API changes or add new > > features. > > > > We would like your feedback on the following two questions: > > > > **Which branch should be default?** > > > > We can either have the master branch in git be the "stable" or the > > "development" branch. If master is the stable branch, then it's easier > > for users to get the most recent stable branch. If master is the > > development branch, it's more familiar and easier for most developers. > > Either way, we will be updating all of the documentation to make it > > clear. > > > > Please let us know which you prefer by replying "I think master should > > be stable" or "I think master should be development". > > > > **How often should we create a new gem5 release?** > > > > We can have a gem5 release once per year (likely in April) or three > > times per year (April, August, and December). Once per year means that > > if you use the stable branch you will get updates less frequently. > > Three times per year will mean there are more releases to choose from > > (but a newer release should always be better). On the development > > side, I don't think one will be more work than the other. Once per > > year means more backporting, and three times per year means more > > testing and time spent on releases. > > > > Please let us know which you prefer by replying "I think gem5 should > > be released once per year" or "I think gem5 should be released three > > times per year." > > > > > > > > > > A couple of notes to everyone who's been following the discussion on > > the gem5-dev mailing list: > > - We have dropped the proposal for major vs minor releases. Note that > > there was some pushback on having only major releases when this was > > proposed on the gem5 roadmap, but it sounded like the consensus was to > > drop minor releases for now. > > - We will still allow feature branches *in rare circumstances*. This > > will be by request only (send mail to gem5-dev if you would like to > > discuss adding a new branch), and the goal will be integration within > > a few months. All code review will still happen in the open on gerrit. > > The benefits will be > > 1) rebases won't be required as you can just make changes to the head > > of the branch > > 2) many features take more than a few months to implement, so if it's > > not ready by a release it can be pushed to the next > > 3) large changes won't be hidden in AMD or Arm-specific repositories > > and *anyone* will be able to request a branch. > > > > Thanks everyone for the discussions so far! It would be most useful to > > hear back by the end of the week. However, I don't expect any concrete > > actions will be taken until after the holidays. > > > > Cheers, > > Jason > > ___ > > 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
Re: [gem5-dev] gem5 stable release proposal [PLEASE VOTE!]
Hello Jason, Thanks for such a nice and detailed explanation. My votes are as follows: *I think master should be development* *I think gem5 should be released once per year* Best regards, Abhishek On Mon, Dec 16, 2019 at 2:50 PM Jason Lowe-Power wrote: > Hi all, > > As many of you have seen on gem5-dev, we are going to be adding a > "stable" version of gem5. Below is the current proposal. There are a > couple of points below where there has not been general consensus > reached. We would appreciate feedback *from everyone in the community* > on the points where a decision hasn't been made below. gem5 is a > community-driven project, and we need feedback to make sure we're > making community-focused decisions. > > We will be introducing a new "stable" branch type to gem5. We are > doing this for the following reasons: > - Provide a way for developers to communicate major changes to the > code. We will be providing detailed release notes for each stable > release. > - Increase our test coverage. At each stable release, we will test a > large number of "common" benchmarks and configurations and publicize > the current state of gem5. > - Provide a way for researchers to communicate to the rest of the > community information about their simulation infrastructure (e.g., in > a paper you can say which version of gem5 you used). > > On the stable version of gem5, we will provide bugfixes until the > next release, but we will not make any API changes or add new > features. > > We would like your feedback on the following two questions: > > **Which branch should be default?** > > We can either have the master branch in git be the "stable" or the > "development" branch. If master is the stable branch, then it's easier > for users to get the most recent stable branch. If master is the > development branch, it's more familiar and easier for most developers. > Either way, we will be updating all of the documentation to make it > clear. > > Please let us know which you prefer by replying "I think master should > be stable" or "I think master should be development". > > **How often should we create a new gem5 release?** > > We can have a gem5 release once per year (likely in April) or three > times per year (April, August, and December). Once per year means that > if you use the stable branch you will get updates less frequently. > Three times per year will mean there are more releases to choose from > (but a newer release should always be better). On the development > side, I don't think one will be more work than the other. Once per > year means more backporting, and three times per year means more > testing and time spent on releases. > > Please let us know which you prefer by replying "I think gem5 should > be released once per year" or "I think gem5 should be released three > times per year." > > > > > A couple of notes to everyone who's been following the discussion on > the gem5-dev mailing list: > - We have dropped the proposal for major vs minor releases. Note that > there was some pushback on having only major releases when this was > proposed on the gem5 roadmap, but it sounded like the consensus was to > drop minor releases for now. > - We will still allow feature branches *in rare circumstances*. This > will be by request only (send mail to gem5-dev if you would like to > discuss adding a new branch), and the goal will be integration within > a few months. All code review will still happen in the open on gerrit. > The benefits will be > 1) rebases won't be required as you can just make changes to the head > of the branch > 2) many features take more than a few months to implement, so if it's > not ready by a release it can be pushed to the next > 3) large changes won't be hidden in AMD or Arm-specific repositories > and *anyone* will be able to request a branch. > > Thanks everyone for the discussions so far! It would be most useful to > hear back by the end of the week. However, I don't expect any concrete > actions will be taken until after the holidays. > > Cheers, > Jason > ___ > 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] gem5 stable release proposal [PLEASE VOTE!]
Hi all, As many of you have seen on gem5-dev, we are going to be adding a "stable" version of gem5. Below is the current proposal. There are a couple of points below where there has not been general consensus reached. We would appreciate feedback *from everyone in the community* on the points where a decision hasn't been made below. gem5 is a community-driven project, and we need feedback to make sure we're making community-focused decisions. We will be introducing a new "stable" branch type to gem5. We are doing this for the following reasons: - Provide a way for developers to communicate major changes to the code. We will be providing detailed release notes for each stable release. - Increase our test coverage. At each stable release, we will test a large number of "common" benchmarks and configurations and publicize the current state of gem5. - Provide a way for researchers to communicate to the rest of the community information about their simulation infrastructure (e.g., in a paper you can say which version of gem5 you used). On the stable version of gem5, we will provide bugfixes until the next release, but we will not make any API changes or add new features. We would like your feedback on the following two questions: **Which branch should be default?** We can either have the master branch in git be the "stable" or the "development" branch. If master is the stable branch, then it's easier for users to get the most recent stable branch. If master is the development branch, it's more familiar and easier for most developers. Either way, we will be updating all of the documentation to make it clear. Please let us know which you prefer by replying "I think master should be stable" or "I think master should be development". **How often should we create a new gem5 release?** We can have a gem5 release once per year (likely in April) or three times per year (April, August, and December). Once per year means that if you use the stable branch you will get updates less frequently. Three times per year will mean there are more releases to choose from (but a newer release should always be better). On the development side, I don't think one will be more work than the other. Once per year means more backporting, and three times per year means more testing and time spent on releases. Please let us know which you prefer by replying "I think gem5 should be released once per year" or "I think gem5 should be released three times per year." A couple of notes to everyone who's been following the discussion on the gem5-dev mailing list: - We have dropped the proposal for major vs minor releases. Note that there was some pushback on having only major releases when this was proposed on the gem5 roadmap, but it sounded like the consensus was to drop minor releases for now. - We will still allow feature branches *in rare circumstances*. This will be by request only (send mail to gem5-dev if you would like to discuss adding a new branch), and the goal will be integration within a few months. All code review will still happen in the open on gerrit. The benefits will be 1) rebases won't be required as you can just make changes to the head of the branch 2) many features take more than a few months to implement, so if it's not ready by a release it can be pushed to the next 3) large changes won't be hidden in AMD or Arm-specific repositories and *anyone* will be able to request a branch. Thanks everyone for the discussions so far! It would be most useful to hear back by the end of the week. However, I don't expect any concrete actions will be taken until after the holidays. Cheers, Jason ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: misc: Add Giacomo Travaglini to PMC
Jason Lowe-Power has uploaded this change for review. ( https://gem5-review.googlesource.com/c/public/gem5/+/23723 ) Change subject: misc: Add Giacomo Travaglini to PMC .. misc: Add Giacomo Travaglini to PMC Change-Id: I025a4bcde558187d02a7e13c6d644555f7148676 Signed-off-by: Jason Lowe-Power --- M MAINTAINERS 1 file changed, 1 insertion(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index c7f4923..6b9b453 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17,6 +17,7 @@ Brad Beckmann David Wood Gabe Black + Giacomo Travaglini Jason Lowe-Power (chair) Matt Sinclair Tony Gutierrez -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23723 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: I025a4bcde558187d02a7e13c6d644555f7148676 Gerrit-Change-Number: 23723 Gerrit-PatchSet: 1 Gerrit-Owner: Jason Lowe-Power Gerrit-MessageType: newchange ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: config: add --bootloader to fs.py and fs_bigLITTLE.py
Ciro Santilli has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/23670 )
Change subject: config: add --bootloader to fs.py and fs_bigLITTLE.py
..
config: add --bootloader to fs.py and fs_bigLITTLE.py
This allows explicitly selecting which bootloader to use.
Before this commit, the bootloader had a fixed basename which
had to be present inside M5_PATH.
Change-Id: I02919207d6f175854017ae7b603d811da63d618e
---
M configs/common/FSConfig.py
M configs/common/Options.py
M configs/example/arm/fs_bigLITTLE.py
M configs/example/fs.py
4 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/configs/common/FSConfig.py b/configs/common/FSConfig.py
index 55a6e91..283c6a7 100644
--- a/configs/common/FSConfig.py
+++ b/configs/common/FSConfig.py
@@ -206,7 +206,8 @@
def makeArmSystem(mem_mode, machine_type, num_cpus=1, mdesc=None,
dtb_filename=None, bare_metal=False, cmdline=None,
- external_memory="", ruby=False, security=False):
+ external_memory="", ruby=False, security=False,
+ bootloader=None):
assert machine_type
pci_devices = []
@@ -297,7 +298,7 @@
'lpj=19988480 norandmaps rw loglevel=8 ' + \
'mem=%(mem)s root=%(rootdev)s'
-self.realview.setupBootLoader(self, binary)
+self.realview.setupBootLoader(self, binary, bootloader)
if hasattr(self.realview.gic, 'cpu_addr'):
self.gic_cpu_addr = self.realview.gic.cpu_addr
diff --git a/configs/common/Options.py b/configs/common/Options.py
index c47d4f7..dd4c339 100644
--- a/configs/common/Options.py
+++ b/configs/common/Options.py
@@ -434,6 +434,8 @@
parser.add_option("--enable-context-switch-stats-dump", \
action="store_true", help="Enable stats dump at context "\
"switches and dump tasks file (required for Streamline)")
+parser.add_option("--bootloader", action='append',
+help="executable file that runs before the --kernel")
# Benchmark options
parser.add_option("--dual", action="store_true",
diff --git a/configs/example/arm/fs_bigLITTLE.py
b/configs/example/arm/fs_bigLITTLE.py
index 94e2846..6be67b0 100644
--- a/configs/example/arm/fs_bigLITTLE.py
+++ b/configs/example/arm/fs_bigLITTLE.py
@@ -115,7 +115,7 @@
cpu_voltage, *cpu_config)
def createSystem(caches, kernel, bootscript, machine_type="VExpress_GEM5",
- disks=[], mem_size=default_mem_size):
+ disks=[], mem_size=default_mem_size, bootloader=None):
platform = ObjectList.platform_list.get(machine_type)
m5.util.inform("Simulated platform: %s", platform.__name__)
@@ -142,7 +142,7 @@
for dev in sys.pci_vio_block:
sys.attach_pci(dev)
-sys.realview.setupBootLoader(sys, SysPaths.binary)
+sys.realview.setupBootLoader(sys, SysPaths.binary, bootloader)
return sys
@@ -201,6 +201,8 @@
help="System memory size")
parser.add_argument("--kernel-cmd", type=str, default=None,
help="Custom Linux kernel command")
+parser.add_argument("--bootloader", action="append",
+help="executable file that runs before the
--kernel")
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 "
@@ -235,7 +237,8 @@
options.bootscript,
options.machine_type,
disks=disks,
- mem_size=options.mem_size)
+ mem_size=options.mem_size,
+ bootloader=options.bootloader)
root.system = system
if options.kernel_cmd:
diff --git a/configs/example/fs.py b/configs/example/fs.py
index c927319..f6c8317 100644
--- a/configs/example/fs.py
+++ b/configs/example/fs.py
@@ -99,7 +99,8 @@
external_memory=
options.external_memory_system,
ruby=options.ruby,
-
security=options.enable_security_extensions)
+
security=options.enable_security_extensions,
+ bootloader=options.bootloader)
if options.enable_context_switch_stats_dump:
test_sys.enable_context_switch_stats_dump = True
else:
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23670
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id:
[gem5-dev] Change in gem5/gem5[master]: dev-arm: add boot_loader param to RealView setupBootLoader
Ciro Santilli has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/23669 )
Change subject: dev-arm: add boot_loader param to RealView setupBootLoader
..
dev-arm: add boot_loader param to RealView setupBootLoader
This serves as a basis to select different bootloaders at runtime in
future commits.
Change-Id: I2ad0006fae9ad38ec1a6b1f11063be955a4dd2ea
---
M src/dev/arm/RealView.py
1 file changed, 24 insertions(+), 23 deletions(-)
diff --git a/src/dev/arm/RealView.py b/src/dev/arm/RealView.py
index 37cf72e..b96eb8e 100644
--- a/src/dev/arm/RealView.py
+++ b/src/dev/arm/RealView.py
@@ -610,10 +610,10 @@
def attachIO(self, *args, **kwargs):
self._attach_io(self._off_chip_devices(), *args, **kwargs)
-def setupBootLoader(self, cur_sys, loc):
-cur_sys.boot_loader = loc('boot.arm')
-cur_sys.atags_addr = 0x100
-cur_sys.load_offset = 0
+def setupBootLoader(self, cur_sys, boot_loader, atags_addr,
load_offset):
+cur_sys.boot_loader = boot_loader
+cur_sys.atags_addr = atags_addr
+cur_sys.load_offset = load_offset
def generateDeviceTree(self, state):
node = FdtNode("/") # Things in this module need to end up in the
root
@@ -761,11 +761,11 @@
self.gicv2m = Gicv2m()
self.gicv2m.frames = [Gicv2mFrame(spi_base=256, spi_len=64,
addr=0x2C1C)]
-def setupBootLoader(self, cur_sys, loc):
-if not cur_sys.boot_loader:
-cur_sys.boot_loader = loc('boot_emm.arm')
-cur_sys.atags_addr = 0x800
-cur_sys.load_offset = 0x8000
+def setupBootLoader(self, cur_sys, loc, boot_loader=None):
+if boot_loader is None:
+boot_loader = loc('boot_emm.arm')
+super(VExpress_EMM, self).setupBootLoader(
+cur_sys, boot_loader, 0x800, 0x8000)
class VExpress_EMM64(VExpress_EMM):
# Three memory regions are specified totalling 512GB
@@ -776,11 +776,11 @@
conf_base=0x3000, conf_size='256MB', conf_device_bits=12,
pci_pio_base=0x2f00)
-def setupBootLoader(self, cur_sys, loc):
-if not cur_sys.boot_loader:
-cur_sys.boot_loader = loc('boot_emm.arm64')
-cur_sys.atags_addr = 0x800
-cur_sys.load_offset = 0x8000
+def setupBootLoader(self, cur_sys, loc, boot_loader=None):
+if boot_loader is None:
+boot_loader = loc('boot_emm.arm64')
+RealView.setupBootLoader(self, cur_sys, boot_loader,
+0x800, 0x8000)
class VExpress_GEM5_Base(RealView):
"""
@@ -992,11 +992,11 @@
self._attach_device(dev, bus, dma_ports)
self.smmu.connect(dev, bus)
-def setupBootLoader(self, cur_sys, loc):
-if not cur_sys.boot_loader:
-cur_sys.boot_loader = [ loc('boot_emm.arm64'),
loc('boot_emm.arm') ]
-cur_sys.atags_addr = 0x800
-cur_sys.load_offset = 0x8000
+def setupBootLoader(self, cur_sys, loc, boot_loader=None):
+if boot_loader is None:
+boot_loader = [ loc('boot_emm.arm64'), loc('boot_emm.arm') ]
+super(VExpress_GEM5_Base, self).setupBootLoader(
+cur_sys, boot_loader, 0x800, 0x8000)
# Setup m5ops. It's technically not a part of the boot
# loader, but this is the only place we can configure the
@@ -1053,10 +1053,11 @@
self.gic, self.gic.its
]
-def setupBootLoader(self, cur_sys, loc):
-cur_sys.boot_loader = [ loc('boot_emm_v2.arm64') ]
-super(VExpress_GEM5_V2_Base,self).setupBootLoader(
-cur_sys, loc)
+def setupBootLoader(self, cur_sys, loc, boot_loader=None):
+if boot_loader is None:
+boot_loader = [ loc('boot_emm_v2.arm64') ]
+super(VExpress_GEM5_V2_Base, self).setupBootLoader(
+cur_sys, boot_loader)
class VExpress_GEM5_V2(VExpress_GEM5_V2_Base):
hdlcd = HDLcd(pxl_clk=VExpress_GEM5_V2_Base.dcc.osc_pxl,
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23669
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I2ad0006fae9ad38ec1a6b1f11063be955a4dd2ea
Gerrit-Change-Number: 23669
Gerrit-PatchSet: 1
Gerrit-Owner: Ciro Santilli
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: config: allow fs.py and fs_bigLITTLE.py to work without M5_PATH
Ciro Santilli has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/23672 )
Change subject: config: allow fs.py and fs_bigLITTLE.py to work without
M5_PATH
..
config: allow fs.py and fs_bigLITTLE.py to work without M5_PATH
The requirement to have an environment variable exported to run a program
is not common, and many new users trip up on it.
Before this commit, M5_PATH was a requirement to run those scripts, or
else simulation would fail with:
IOError: Can't find a path to system files.
After this patch, as long as users indicate all required files with
command line options, M5_PATH is not needed.
This patch changes the M5_PATH semantics slightly to more closely match
PATH and so be more intuitive to users: after this commit, if the
given path contains a slash /, then the path is not searched for inside
M5_PATH, which is exactly how PATH works. Users can then select images
in the CWD with a leading ./ just as done for executables.
This is backwards incompatible if users were already specifying their paths
as ./, but this interface feels saner, because otherwise writing on the CLI
e.g.:
--disk-image path/to/my.disk
would previously fail to find the disk, even if it existed, which is very
counter-intuitive. The following will still fail however:
--disk-image my.disk
which is not ideal, but for now is a comprise between backwards
compatibility of having an M5_PATH and what users expect from CLI
interfaces.
Change-Id: Ic91e1cc20557b35b69490b6dc420e7d324fae1fc
---
M configs/common/SysPaths.py
1 file changed, 30 insertions(+), 22 deletions(-)
diff --git a/configs/common/SysPaths.py b/configs/common/SysPaths.py
index e5d9f83..0a67789 100644
--- a/configs/common/SysPaths.py
+++ b/configs/common/SysPaths.py
@@ -37,6 +37,7 @@
class PathSearchFunc(object):
_sys_paths = None
+environment_variable = 'M5_PATH'
def __init__(self, subdirs, sys_paths=None):
if isinstance(subdirs, string_types):
@@ -46,29 +47,36 @@
self._sys_paths = sys_paths
def __call__(self, filename):
-if self._sys_paths is None:
+if os.sep in filename:
+return filename
+else:
+if self._sys_paths is None:
+try:
+paths =
os.environ[self.environment_variable].split(':')
+except KeyError:
+paths =
[ '/dist/m5/system', '/n/poolfs/z/dist/m5/system' ]
+
+# expand '~' and '~user' in paths
+paths = map(os.path.expanduser, paths)
+
+# filter out non-existent directories
+paths = filter(os.path.isdir, paths)
+
+if not paths:
+raise IOError(
+"Can't find system files directory, "
+"check your {} environment variable"
+.format(self.environment_variable))
+
+self._sys_paths = list(paths)
+
+filepath = os.path.join(self._subdir, filename)
+paths = (os.path.join(p, filepath) for p in self._sys_paths)
try:
-paths = os.environ['M5_PATH'].split(':')
-except KeyError:
-paths = [ '/dist/m5/system', '/n/poolfs/z/dist/m5/system' ]
-
-# expand '~' and '~user' in paths
-paths = map(os.path.expanduser, paths)
-
-# filter out non-existent directories
-paths = filter(os.path.isdir, paths)
-
-if not paths:
-raise IOError("Can't find a path to system files.")
-
-self._sys_paths = list(paths)
-
-filepath = os.path.join(self._subdir, filename)
-paths = (os.path.join(p, filepath) for p in self._sys_paths)
-try:
-return next(p for p in paths if os.path.exists(p))
-except StopIteration:
-raise IOError("Can't find file '%s' on path." % filename)
+return next(p for p in paths if os.path.exists(p))
+except StopIteration:
+raise IOError("Can't find file '{}' on {}."
+.format(filename, self.environment_variable))
disk = PathSearchFunc('disks')
binary = PathSearchFunc('binaries')
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23672
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: Ic91e1cc20557b35b69490b6dc420e7d324fae1fc
Gerrit-Change-Number: 23672
Gerrit-PatchSet: 1
Gerrit-Owner: Ciro Santilli
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: configs: fs.py can take multiple disk images on most ISAs
Ciro Santilli has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/23671 )
Change subject: configs: fs.py can take multiple disk images on most ISAs
..
configs: fs.py can take multiple disk images on most ISAs
All ISAs except SPARC can now take multiple disk images by passing
the --disk-image option multiple times.
Before this patch, several ISAs automatically mounted a secondary disk
called "linux-bigswap2.img", which had to be in M5_PATH even if the end
user did not want more than one disk. This was the case for for example
for X86 but not ARM.
This change was done to:
* allow ARM to have a second disk image in fs.py, which was not possible,
and allow other ISAs like X86 and ARM to take any number of disk images
* provide a simpler, more intuitive CLI interface that does not require
magic disk images to be present in M5_PATH to work for ISAs such as X86.
Linux does not need that secondary image to boot correctly, so it is
more friendly to support a minimal setup that requires the least amount
of binaries to boot, and let supply the second image manually only if
they need it.
* make fs.py --disk-image work more similarly across all ISAs
SPARC was left with a single disk only because its setup was a bit more
complex and would require further testing.
Change-Id: I8b6e08ae6daf0a5b6cd1d57d285a9677f01eb7ad
---
M configs/common/Benchmarks.py
M configs/common/FSConfig.py
M configs/common/Options.py
M configs/example/fs.py
M tests/configs/pc-simple-timing-ruby.py
M tests/configs/x86_generic.py
6 files changed, 51 insertions(+), 53 deletions(-)
diff --git a/configs/common/Benchmarks.py b/configs/common/Benchmarks.py
index 3cf963b..9ed321c 100644
--- a/configs/common/Benchmarks.py
+++ b/configs/common/Benchmarks.py
@@ -34,10 +34,10 @@
from m5.defines import buildEnv
class SysConfig:
-def __init__(self, script=None, mem=None, disk=None, rootdev=None,
+def __init__(self, script=None, mem=None, disks=None, rootdev=None,
os_type='linux'):
self.scriptname = script
-self.diskname = disk
+self.disknames = disks
self.memsize = mem
self.root = rootdev
self.ostype = os_type
@@ -54,17 +54,17 @@
else:
return '128MB'
-def disk(self):
-if self.diskname:
-return disk(self.diskname)
+def disks(self):
+if self.disknames:
+return [disk(diskname) for diskname in self.disknames]
elif buildEnv['TARGET_ISA'] == 'alpha':
-return env.get('LINUX_IMAGE', disk('linux-latest.img'))
+return [env.get('LINUX_IMAGE', disk('linux-latest.img'))]
elif buildEnv['TARGET_ISA'] == 'x86':
-return env.get('LINUX_IMAGE', disk('x86root.img'))
+return [env.get('LINUX_IMAGE', disk('x86root.img'))]
elif buildEnv['TARGET_ISA'] == 'arm':
-return env.get('LINUX_IMAGE', disk('linux-aarch32-ael.img'))
+return [env.get('LINUX_IMAGE', disk('linux-aarch32-ael.img'))]
elif buildEnv['TARGET_ISA'] == 'sparc':
-return env.get('LINUX_IMAGE', disk('disk.s10hw2'))
+return [env.get('LINUX_IMAGE', disk('disk.s10hw2'))]
else:
print("Don't know what default disk image to use for %s ISA" %
buildEnv['TARGET_ISA'])
@@ -83,8 +83,8 @@
# The first defined machine is the test system, the others are driving
systems
Benchmarks = {
-'PovrayBench': [SysConfig('povray-bench.rcS', '512MB', 'povray.img')],
-'PovrayAutumn':
[SysConfig('povray-autumn.rcS', '512MB', 'povray.img')],
+'PovrayBench': [SysConfig('povray-bench.rcS', '512MB',
['povray.img'])],
+'PovrayAutumn': [SysConfig('povray-autumn.rcS', '512MB',
['povray.img'])],
'NetperfStream':[SysConfig('netperf-stream-client.rcS'),
SysConfig('netperf-server.rcS')],
@@ -129,16 +129,16 @@
'MutexTest':[SysConfig('mutex-test.rcS', '128MB')],
'ArmAndroid-GB':[SysConfig('null.rcS', '256MB',
-'ARMv7a-Gingerbread-Android.SMP.mouse.nolock.clean.img',
+
['ARMv7a-Gingerbread-Android.SMP.mouse.nolock.clean.img'],
None, 'android-gingerbread')],
-'bbench-gb':[SysConfig('bbench-gb.rcS', '256MB',
-'ARMv7a-Gingerbread-Android.SMP.mouse.nolock.img',
+'bbench-gb': [SysConfig('bbench-gb.rcS', '256MB',
+
['ARMv7a-Gingerbread-Android.SMP.mouse.nolock.img'],
None, 'android-gingerbread')],
'ArmAndroid-ICS': [SysConfig('null.rcS', '256MB',
-'ARMv7a-ICS-Android.SMP.nolock.clean.img',
+['ARMv7a-ICS-Android.SMP.nolock.clean.img'],
None, 'android-ics')],
'bbench-ics':
[gem5-dev] Change in gem5/gem5[master]: mem-cache: Forward snoops when the cache is not responding
Nikos Nikoleris has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/23668 )
Change subject: mem-cache: Forward snoops when the cache is not responding
..
mem-cache: Forward snoops when the cache is not responding
When the MSHR is handling a request that will make the block dirty the
current cache commits respond. When that's not the case the cache
should forward any snoops. This CL fixes MSHR::handleSnoop() to
implement this behavior.
Change-Id: I207e3ca4968fd9528fd4cdbfb3eb95f470b4744d
Signed-off-by: Nikos Nikoleris
---
M src/mem/cache/mshr.cc
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/src/mem/cache/mshr.cc b/src/mem/cache/mshr.cc
index 0e8d054..e487fba 100644
--- a/src/mem/cache/mshr.cc
+++ b/src/mem/cache/mshr.cc
@@ -465,6 +465,10 @@
return true;
}
+// Start by determining if we will eventually respond or not,
+// matching the conditions checked in Cache::handleSnoop
+const bool will_respond = isPendingModified() && pkt->needsResponse()
&&
+!pkt->isClean();
if (isPendingModified() || pkt->isInvalidate()) {
// We need to save and replay the packet in two cases:
// 1. We're awaiting a writable copy (Modified or Exclusive),
@@ -474,11 +478,6 @@
//to forward the snoop up the hierarchy after the current
//transaction completes.
-// Start by determining if we will eventually respond or not,
-// matching the conditions checked in Cache::handleSnoop
-bool will_respond = isPendingModified() && pkt->needsResponse() &&
- !pkt->isClean();
-
// The packet we are snooping may be deleted by the time we
// actually process the target, and we consequently need to
// save a copy here. Clear flags and also allocate new data as
@@ -535,7 +534,7 @@
pkt->setHasSharers();
}
-return true;
+return will_respond;
}
MSHR::TargetList
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23668
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I207e3ca4968fd9528fd4cdbfb3eb95f470b4744d
Gerrit-Change-Number: 23668
Gerrit-PatchSet: 1
Gerrit-Owner: Nikos Nikoleris
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: mem-cache: Avoid write merging if there are reads in between
Nikos Nikoleris has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/23666 )
Change subject: mem-cache: Avoid write merging if there are reads in between
..
mem-cache: Avoid write merging if there are reads in between
This CL reworks the logic in the MSHR to make sure we do not coalesce
requests unless there is a series of write requests for the whole
cache block without any other incompatible requests (e.g., read) in
between.
Change-Id: I0b3195858fb33ef85d7aae27376506057dd53ea7
Signed-off-by: Nikos Nikoleris
---
M src/mem/cache/mshr.cc
M src/mem/cache/mshr.hh
2 files changed, 47 insertions(+), 32 deletions(-)
diff --git a/src/mem/cache/mshr.cc b/src/mem/cache/mshr.cc
index 4241fa3..0e8d054 100644
--- a/src/mem/cache/mshr.cc
+++ b/src/mem/cache/mshr.cc
@@ -111,6 +111,52 @@
}
}
+void
+MSHR::TargetList::updateWriteFlags(PacketPtr pkt)
+{
+if (isWholeLineWrite()) {
+// if we have already seen writes for the full block
+// stop here, this might be a full line write followed
+// by other compatible requests (e.g., reads)
+return;
+}
+
+if (canMergeWrites) {
+if (!pkt->isWrite()) {
+// We won't allow further merging if this hasn't
+// been a write
+canMergeWrites = false;
+return;
+}
+
+// Avoid merging requests with special flags (e.g.,
+// strictly ordered)
+const Request::FlagsType no_merge_flags =
+Request::UNCACHEABLE | Request::STRICT_ORDER |
+Request::MMAPPED_IPR | Request::LLSC |
+Request::MEM_SWAP | Request::MEM_SWAP_COND |
+Request::SECURE;
+const auto _flags = pkt->req->getFlags();
+bool compat_write = !req_flags.isSet(no_merge_flags);
+
+// if this is the first write, it might be a whole
+// line write and even if we can't merge any
+// subsequent write requests, we still need to service
+// it as a whole line write (e.g., SECURE whole line
+// write)
+bool first_write = empty();
+if (first_write || compat_write) {
+auto offset = pkt->getOffset(blkSize);
+auto begin = writesBitmap.begin() + offset;
+std::fill(begin, begin + pkt->getSize(), true);
+}
+
+// We won't allow further merging if this has been a
+// special write
+canMergeWrites &= compat_write;
+}
+}
+
inline void
MSHR::TargetList::add(PacketPtr pkt, Tick readyTime,
Counter order, Target::Source source, bool
markPending,
diff --git a/src/mem/cache/mshr.hh b/src/mem/cache/mshr.hh
index 40eb970..685064f 100644
--- a/src/mem/cache/mshr.hh
+++ b/src/mem/cache/mshr.hh
@@ -227,38 +227,7 @@
*
* @param pkt Packet considered for adding
*/
-void
-updateWriteFlags(PacketPtr pkt)
-{
-// if we have already seen writes for the full block stop
-// here, this might be a full line write followed by
-// other compatible requests (e.g., reads)
-if (!isWholeLineWrite()) {
-// Avoid merging requests with special flags (e.g.,
-// strictly ordered)
-const Request::FlagsType no_merge_flags =
-Request::UNCACHEABLE | Request::STRICT_ORDER |
-Request::MMAPPED_IPR | Request::PRIVILEGED |
-Request::LLSC | Request::MEM_SWAP |
-Request::MEM_SWAP_COND | Request::SECURE;
-const auto _flags = pkt->req->getFlags();
-bool compat_write = pkt->isWrite() &&
-!req_flags.isSet(no_merge_flags);
-canMergeWrites &= compat_write;
-
-// if this request is the first target in this list
-// and additionally a whole-line write, we need to
-// service it as a whole-line even if we won't allow
-// any further merging (e.g., SECURE whole line
-// write).
-bool first_write = pkt->isWrite() && (size() == 0);
-if (first_write || compat_write) {
-auto offset = pkt->getOffset(blkSize);
-auto begin = writesBitmap.begin() + offset;
-std::fill(begin, begin + pkt->getSize(), true);
-}
-}
- }
+void updateWriteFlags(PacketPtr pkt);
/**
* Tests if the flags of this TargetList have their default
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23666
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I0b3195858fb33ef85d7aae27376506057dd53ea7
Gerrit-Change-Number: 23666
[gem5-dev] Change in gem5/gem5[master]: mem-cache: Ensure that responses get data from the right source
Nikos Nikoleris has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/23667 )
Change subject: mem-cache: Ensure that responses get data from the right
source
..
mem-cache: Ensure that responses get data from the right source
This CL makes sure that we use the right source for data for
responses after a response from the cache below.
Change-Id: I7329f3e6bcb7ce2054e912eb9dea48c9d169d45a
Signed-off-by: Nikos Nikoleris
---
M src/mem/cache/cache.cc
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/src/mem/cache/cache.cc b/src/mem/cache/cache.cc
index e7dd5ef..65ce9a6 100644
--- a/src/mem/cache/cache.cc
+++ b/src/mem/cache/cache.cc
@@ -756,7 +756,15 @@
assert(blk->isWritable());
}
-if (blk && blk->isValid() && !mshr->isForward) {
+// Here we decide whether we will satisfy targets using
+// data from the block or from the response. If the
+// response is forwarding data to the cache above then the
block
+// we use the block data to satisfy the request when the
+// block is present and valid and in addition the response
+// in not forwarding data to a cache above, otherwise we
+// use the packet data.
+if (blk && blk->isValid() &&
+(!mshr->isForward || !pkt->hasData())) {
satisfyRequest(tgt_pkt, blk, true,
mshr->hasPostDowngrade());
// How many bytes past the first request is this one
@@ -791,15 +799,15 @@
pkt->payloadDelay;
tgt_pkt->req->setExtraData(0);
} else {
-// We are about to send a response to a cache above
-// that asked for an invalidation; we need to
-// invalidate our copy immediately as the most
-// up-to-date copy of the block will now be in the
-// cache above. It will also prevent this cache from
-// responding (if the block was previously dirty) to
-// snoops as they should snoop the caches above where
-// they will get the response from.
if (is_invalidate && blk && blk->isValid()) {
+// We are about to send a response to a cache above
+// that asked for an invalidation; we need to
+// invalidate our copy immediately as the most
+// up-to-date copy of the block will now be in the
+// cache above. It will also prevent this cache from
+// responding (if the block was previously dirty) to
+// snoops as they should snoop the caches above where
+// they will get the response from.
invalidateBlock(blk);
}
// not a cache fill, just forwarding response
@@ -813,6 +821,14 @@
assert(pkt->getSize() >= tgt_pkt->getSize());
tgt_pkt->setData(pkt->getConstPtr());
+} else if (!is_error) {
+// MSHR targets can read data either from the
+// block or the response pkt. If we can't get data
+// from the block (i.e., invalid or has old data)
+// or the response (did not bring in any data)
+// then make sure that the target didn't expect
+// any.
+assert(!tgt_pkt->hasRespData());
}
// this response did not allocate here and therefore
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23667
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I7329f3e6bcb7ce2054e912eb9dea48c9d169d45a
Gerrit-Change-Number: 23667
Gerrit-PatchSet: 1
Gerrit-Owner: Nikos Nikoleris
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: scons: Do not use sanitizers for the build/TARGET/marshal binary
Nikos Nikoleris has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/23665 )
Change subject: scons: Do not use sanitizers for the build/TARGET/marshal
binary
..
scons: Do not use sanitizers for the build/TARGET/marshal binary
The marshal binary uses a scoped python interpreter in which the
address sanitizer finds a number of leaks. This changeset disables the
use of sanitizers for the mashal binary where any leaks are beyond the
scope of gem5.
Change-Id: I76d49820c51c1067fa4a0c4538d44f59f667cc30
Signed-off-by: Nikos Nikoleris
---
M SConstruct
M src/SConscript
2 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/SConstruct b/SConstruct
index 5a90808..5496796 100755
--- a/SConstruct
+++ b/SConstruct
@@ -470,20 +470,20 @@
if GetOption('with_asan'):
if GetOption('with_ubsan') and \
compareVersions(main['GCC_VERSION'], '4.9') >= 0:
-main.Append(CCFLAGS=['-fsanitize=address,undefined',
- '-fno-omit-frame-pointer'],
-LINKFLAGS='-fsanitize=address,undefined')
+main.Append(SAN_CCFLAGS=['-fsanitize=address,undefined',
+ '-fno-omit-frame-pointer'],
+SAN_LINKFLAGS='-fsanitize=address,undefined')
else:
-main.Append(CCFLAGS=['-fsanitize=address',
- '-fno-omit-frame-pointer'],
-LINKFLAGS='-fsanitize=address')
+main.Append(SAN_CCFLAGS=['-fsanitize=address',
+ '-fno-omit-frame-pointer'],
+SAN_LINKFLAGS='-fsanitize=address')
# Only gcc >= 4.9 supports UBSan, so check both the version
# and the command-line option before adding the compiler and
# linker flags.
elif GetOption('with_ubsan') and \
compareVersions(main['GCC_VERSION'], '4.9') >= 0:
-main.Append(CCFLAGS='-fsanitize=undefined')
-main.Append(LINKFLAGS='-fsanitize=undefined')
+main.Append(SAN_CCFLAGS='-fsanitize=undefined')
+main.Append(SAN_LINKFLAGS='-fsanitize=undefined')
elif main['CLANG']:
# Check for a supported version of clang, >= 3.1 is needed to
@@ -527,17 +527,17 @@
# versions here.
if GetOption('with_ubsan'):
if GetOption('with_asan'):
-main.Append(CCFLAGS=['-fsanitize=address,undefined',
- '-fno-omit-frame-pointer'],
- LINKFLAGS='-fsanitize=address,undefined')
+main.Append(SAN_CCFLAGS=['-fsanitize=address,undefined',
+ '-fno-omit-frame-pointer'],
+ SAN_LINKFLAGS='-fsanitize=address,undefined')
else:
-main.Append(CCFLAGS='-fsanitize=undefined',
-LINKFLAGS='-fsanitize=undefined')
+main.Append(SAN_CCFLAGS='-fsanitize=undefined',
+SAN_LINKFLAGS='-fsanitize=undefined')
elif GetOption('with_asan'):
-main.Append(CCFLAGS=['-fsanitize=address',
- '-fno-omit-frame-pointer'],
- LINKFLAGS='-fsanitize=address')
+main.Append(SAN_CCFLAGS=['-fsanitize=address',
+ '-fno-omit-frame-pointer'],
+ SAN_LINKFLAGS='-fsanitize=address')
# Set up common yacc/bison flags (needed for Ruby)
main['YACCFLAGS'] = '-d'
diff --git a/src/SConscript b/src/SConscript
index 76bbb9e..c136116 100644
--- a/src/SConscript
+++ b/src/SConscript
@@ -464,6 +464,11 @@
else:
return env.Program(self.path(env), objs)
+# Add sanitizers compilate and link flags
+env['CCFLAGS'] += env.get('SAN_CCFLAGS', [])
+env['LINKFLAGS'] += env.get('SAN_LINKFLAGS', [])
+
+
class UnitTest(Executable):
'''Create a UnitTest'''
def __init__(self, target, *srcs_and_filts, **kwargs):
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/23665
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I76d49820c51c1067fa4a0c4538d44f59f667cc30
Gerrit-Change-Number: 23665
Gerrit-PatchSet: 1
Gerrit-Owner: Nikos Nikoleris
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: sim: kernelExtras if no kernel provided
Giacomo Travaglini has submitted this change. ( https://gem5-review.googlesource.com/c/public/gem5/+/22850 ) Change subject: sim: kernelExtras if no kernel provided .. sim: kernelExtras if no kernel provided kernelExtras facilitates a way for users to provide additional blobs to load into memory. As of now, the creation of the extra images is done independently of the kernel being provided, but the loading is only done if the kernel is present. This patch refactors the loading of extra images to be committed if no kernel is present. Change-Id: I900542e1034ade8d757d01823cfd4a30f0b36734 Reviewed-by: Giacomo Travaglini Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22850 Tested-by: kokoro Reviewed-by: Gabe Black Reviewed-by: Jason Lowe-Power Maintainer: Jason Lowe-Power --- M src/sim/system.cc 1 file changed, 3 insertions(+), 3 deletions(-) Approvals: Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved Gabe Black: Looks good to me, but someone else must approve kokoro: Regressions pass diff --git a/src/sim/system.cc b/src/sim/system.cc index 0e7db59..8c43808 100644 --- a/src/sim/system.cc +++ b/src/sim/system.cc @@ -1,5 +1,5 @@ /* - * Copyright (c) 2011-2014,2017-2018 ARM Limited + * Copyright (c) 2011-2014,2017-2019 ARM Limited * All rights reserved * * The license below extends only to copyright in the software and shall @@ -354,14 +354,14 @@ } // Load program sections into memory kernelImage.write(physProxy); -for (const auto _kernel : kernelExtras) -extra_kernel->buildImage().move(mapper).write(physProxy); DPRINTF(Loader, "Kernel start = %#x\n", kernelStart); DPRINTF(Loader, "Kernel end = %#x\n", kernelEnd); DPRINTF(Loader, "Kernel entry = %#x\n", kernelEntry); DPRINTF(Loader, "Kernel loaded...\n"); } +for (const auto _kernel : kernelExtras) +extra_kernel->buildImage().move(mapper).write(physProxy); } } -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/22850 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: I900542e1034ade8d757d01823cfd4a30f0b36734 Gerrit-Change-Number: 22850 Gerrit-PatchSet: 3 Gerrit-Owner: Giacomo Travaglini Gerrit-Reviewer: Bobby R. Bruce Gerrit-Reviewer: Gabe Black Gerrit-Reviewer: Giacomo Travaglini Gerrit-Reviewer: Jason Lowe-Power Gerrit-Reviewer: kokoro Gerrit-CC: Adrián Herrera Arcila Gerrit-MessageType: merged ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Use of protobuf backend with ARMv8 appears to be badly broken
Hi Robert, Apologies for the late reply. This is probably something easy to fix. If you have a look at src/proto/inst.proto, it defines an enum of instruction types. If you see the enum list, it is missing number 47. What is probably happening is that a new instruction type had been added to gem5 but it hadn't been included in the proto files. Let me know if it is easy for you to fix this and contribute to master. If not, I can open a JIRA ticket and handle it myself as soon as I have more time. We should also find a way to prevent this syncing issues to happen again. This could be achieved by having a shared InstType enumeration or, if this is not possible in protobuf, to add a minimal protobuf test in the regression system. Giacomo From: gem5-dev on behalf of Robert Henry Sent: 26 November 2019 01:14 To: gem5-dev@gem5.org Subject: [gem5-dev] Use of protobuf backend with ARMv8 appears to be badly broken gem5'ers There is an attractive instruction tracer "InstPBTrace" in gem5, but no documentation on how to use it. I'm using gem5 for ARMv8. Taking a guess by analogy with documentation on how to enable other instr tracers, I hack into fs.py cpu.tracer = InstPBTrace() cpu.tracer.file_name = "/tmp/foo" And that starts up the InstPBTracer, albeit briefly. The tracer soon derails when it attempts to protobuf serialize an enumeration value which is not valid for protobuf encodings. See the stack trace below. Given the age of InstPBTrace, the lack of documentation, and the apparent misfit between the internals of gem5 and the protobuf specification, I would seem InstPBTrace is broken. Here's the stack trace; frame1 argument 'value' with value of 47 is rejected by Inst_InstType_IsValid. 0 ProtoMessage::Inst_InstType_IsValid (value=21845) at build/ARM/proto/inst.pb.cc:224 #1 0x592d3849 in ProtoMessage::Inst::set_type (this=0x5c9b5aa0, value=47) at build/ARM/proto/inst.pb.h:1143 #2 0x59523c58 in Trace::InstPBTrace::traceInst (this=0x5c8d9450, tc=0x5c3db0d0, si=..., pc=...) at build/ARM/cpu/inst_pb_trace.cc:162 #3 0x595232d9 in Trace::InstPBTraceRecord::dump (this=0x5bbe9960) at build/ARM/cpu/inst_pb_trace.cc:63 #4 0x592e6e79 in BaseSimpleCPU::postExecute (this=0x5e0e8000) at build/ARM/cpu/simple/base.cc:657 #5 0x592dcb5e in AtomicSimpleCPU::tick (this=0x5e0e8000) at build/ARM/cpu/simple/atomic.cc:733 #6 0x592d8f7d in AtomicSimpleCPUoperator()(void) const (__closure=0x5e0e8458) at build/ARM/cpu/simple/atomic.cc:81 #7 0x592dd164 in std::_Function_handler >::_M_invoke(const std::_Any_data &) (__functor=...) at /usr/include/c++/9/bits/std_function.h:300 #8 0x5721781e in std::function::operator()() const (this=0x5e0e8458) at /usr/include/c++/9/bits/std_function.h:690 #9 0x57216a14 in EventFunctionWrapper::process (this=0x5e0e8420) at build/ARM/sim/eventq.hh:836 #10 0x57519095 in EventQueue::serviceOne (this=0x5bf9bf20) at build/ARM/sim/eventq.cc:228 #11 0x57523b1c in doSimLoop (eventq=0x5bf9bf20) at build/ARM/sim/simulate.cc:219 #12 0x5752372e in simulate (num_cycles=18446744073709551615) at build/ARM/sim/simulate.cc:132 #13 0x57356652 in pybind11::detail::argument_loader::call_impl (this=0x7fffd288, f=@0x5bc295b8: 0x575233f4 ) at ext/pybind11/include/pybind11/cast.h:1935 ___ 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
