Since this class has a custom destructor ~ProbeListener(), it should
also generally have the 4 other methods defined, otherwise calling
those methods lead to subtle failures.
In this specific case, the ProbeManager *const manager; field stores a
pointer back to the ProbeListener object at:
ProbeListener::ProbeListener {
manager->addListener(name, *this);
which gets unregistered by the destructor:
ProbeListener::~ProbeListener()
manager->removeListener(name, *this);
and because the default copy does not re-register anything, it leads to
unregistration.
Therefore, a copy constructor would need the manager to support multiple
identical listeners, or at least refcount them, which would be overkill.
The two move operations would be more feasible, as we could make them
unregister the old ProbeListener address and then re-register the new one,
but that is not very efficient, so we just delete them as well.
A consequence of not implementing the move methods is that it is
impossible to store ProbeListener inside an std::vector. since objects
inside std::vector may need to be moved in memory when the vector resizes,
and therefore need to be movable. The alternative is to use an std::vector
of std::unique_ptr instead.
Change-Id: I8dc0157665391f86e2ca81d144bc6a42e9312d6c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37977
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This register is used since the Linux kernel 5.6 aarch64 boot.
This register indicates CPU capabilities in aarch32 mode, and it has the
same value as the aarch32 ID_ISAR6 miscregister, which is also added.
The capability values of those registers are analogous to those present in
aarch64 accessible ID_AA64ISAR0_EL1 and ID_AA64ISAR1_EL1, which refer to
aarch64 capabilities however, and were already implemented before this
commit.
The arm architecture document clarifies that reads to this system register
location before it had been defined should return 0, but we were faulting
instead:
> Prior to the introduction of the features described by this register,
this register was unnamed and reserved, RES0 from EL1, EL2, and EL3.
Change-Id: I70e99536dc98925e88233fd4c6887bbcdd5d87dc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30935
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In clang, the following error was given:
```
In file included from build/X86/sim/eventq.hh:51:
build/X86/sim/serialize.hh:533:19: error: 'ScopedCheckpointSection' is a protected member of 'Serializable'
Serializable::ScopedCheckpointSection sec(os, sectionName);
^
build/X86/sim/serialize.hh:175:11: note: declared protected here
class ScopedCheckpointSection {
^
```
The use, at line 533, was introduced in this commit:
https://gem5-review.googlesource.com/c/public/gem5/+/36135
This can be fixed by making ScopedCheckpointSection public.
Change-Id: Ib6ffba18d5e8c37980d4febb548f2405cb45ce8c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37915
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Once all ISAs are converted, the base StaticInst class will be able to
drop its local arrays, and will no longer need to know what the global
maximum number of source or destination registers is for a given
instruction.
Most of the convertion was very simple and just involved adding tags to
declare and install the register arrays in all the class definitions.
Since SPARC has a relatively simple ISA definition, there weren't many
places that needed to be updated.
The exception was the BlockMem template, which was declaring the microop
classes within the body of the macroop. That was ok when those
declarations didn't need anything other than the name of their parent,
but now they also need to know how big to declare their arrays based on
their actual implementation.
To facilitate that, and to significantly streamline the definition of
the macroop class, the microop class definitions were moved to their own
template, and only the declaration was left in the parent class.
Change-Id: I09e6b1d1041c6a0aeaee63ce5f9a18cf482b6203
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36879
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This will prevent checkpoints from breaking on every miscreg addition.
Before this commit, miscregs were stored as an array:
[system.cpu.isa]
miscRegs=965 0 0 0 0 0 0 0 0 0 0 0 17895697 ...
and after this commit they are stored as a map:
[system.cpu.isa]
[system.cpu.isa.miscRegs]
cpsr=965
spsr=0
spsr_fiq=0
spsr_irq=0
spsr_svc=0
spsr_mon=0
spsr_abt=0
spsr_hyp=0
spsr_und=0
elr_hyp=0
fpsid=0
fpscr=0
mvfr1=17895697
JIRA: https://gem5.atlassian.net/browse/GEM5-661
Change-Id: I49999c7206bd9ac1cfb81297d45c8117ff8ae675
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36116
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The SmartDict, used by buildEnv, has been added long time ago for
the following reasons: (checking its documentation)
---
The SmartDict class fixes a couple of issues with using the content
of os.environ or similar dicts of strings as Python variables:
1) Undefined variables should return False rather than raising KeyError.
2) String values of 'False', '0', etc., should evaluate to False
(not just the empty string).
---
These are valid reasons, but I believe they should be addressed in
a more standardized way by using a common dictionary.
1) We should simply rely on dict.get
if buildEnv.get('KEY', False/None):
2) We should discourage the use of stringified False or 0.
If we are using a dictionary, can't we just pass those values as
booleans?
The SmartDict is basically converting every value into a
string ("Variable") at every access (__getitem__)
The Variable is a string + some "basic" conversion methods
What is the problem of passing every dict value as a string?
The problem is the ambiguity on the boolean conversion.
If a variable is modelling a boolean, we can return true if
the value is 'yes', 'true'... and false if the value is
'no', 'false' etc. We should raise an exception if it is
something different, like a typo (e.g.) 'Fasle'.
But if the variable is not modelling a boolean, we don't know
how to handle that. How should we convert 'mystring' ?
If we decide to treat 'mystring' as True (which is basically
what a str.__bool__ would return) we will break typoes detection,
as 'Fasle' will now be converted to True, rather than raising
an exception.
Change-Id: I960fbfb1ec0f703e1e372dd752ee75f00632acac
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37775
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There is a mismatch between the tags in MAINTAINERS.yaml and the
valid_tags in the git hook. This means if a user consults the
MAINTAINERS.yaml file to find the appropriate tag, there is a chance of
the commit being rejected due to this mismatch. Now that the maintainers
file is in yaml format, use the util/maint library to parse the valid
tag options. Additional meta tags are added (WIP, RFC) and tags that
were previously valid but not in the MAINTAINERS.yaml file.
Change-Id: I3de8f0b6f8507aa1afd2118bc4373ac0610cce40
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37220
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We used to have a hard-coded packet2payload and payload2packet in the
tlm_bridge implementation. However, as the conversion is operated on
generic tlm payload, we're not able to handle information stored in any
user defined SystemC extensions.
In this CL, we add a pair of function to register extra conversion steps
between tlm payload and gem5 packet. This decouples the exact conversion
logic and enables SystemC users to register any necessary steps for
their extensions.
Change-Id: I70b3405395fed0f757f0fb7e19136f47d84ac115
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37075
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There are two new strings, reg_idx_arr_decl which declares the source
and dest register index arrays, and set_reg_idx_arr which installs them
in the base class.
The set_reg_idx_arr code needs to implicitly figure out what type to use
based on the type of the "this" pointer. The name of the containing
class is not *necessarily* the same as class_name, since the generated
code can use that name, something based on that name, or whatever else
it wants. No other format string (other than class_name itself) uses the
class name internally, so we can't count on that working in existing ISA
definitions.
Change-Id: Id995a46896e71a2fcf3103c34a1e1e67e24f88f4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36878
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Inside the code of cloneFunc(…) //syscall_emul.hh
cp->initState(); //line 1483
p->clone(tc, ctc, cp, flags); //line 1484
…
ctc->clearArchRegs(); //line 1503
OS::archClone(flags, p, cp, tc, ctc, newStack, tlsPtr); //line 1505
…
At line 1483, initState() is called and the activateContext() of the
corresponding MinorCPU is eventually called. The actual architecture
clone happens at line 1505 where PC of the new thread could have a
correct value.
In the existing implementation of MinorCPU::activateContext(ThreadID
thread_id), the below line 275 is called
pipeline->wakeupFetch(thread_id);
to start fetching instruction with current value of PC, which is 0x0,
leading to panic “Page table fault when accessing virtual address 0”.
This is because the OS::archClone() is not yet called. So, the below bug
fix handles the wakeup fetch for a thread for two scenarios:
...
if (!threads[thread_id]->getUseForClone())
{ //the thread is not cloned
pipeline->wakeupFetch(thread_id);
} else {//the thread from clone
if (fetchEventWrapper != NULL)
delete fetchEventWrapper;
fetchEventWrapper = new EventFunctionWrapper([this, thread_id]
{pipeline->wakeupFetch(thread_id);}, "wakeupFetch");
schedule(*fetchEventWrapper, clockEdge(Cycles(0)));
}
...
If a thread is not cloned, pipeline->wakeupFetch() is called
immediately.
For the cloned thread, the above bug fix delays the execution of
pipeline->wakeupFetch()
after the OS::archClone is done. ThreadContext::getUseForClone() return
true if a thread is cloned.
A member variable fetchEventWrapper is added to MinorCPU class for
delayed fetch event.
A member variable useForClone and its corresponding get/set methods are
added to ThreadContext class. This approach allows future reuse of this
useForClone variable by other CPU models if needed and also avoid lots
of changes resulted by modifying parameters of activateContext () and
activate() which are defined as override.
Inside the syscall cloneFunc, the useForClone member of a ThreadContext
object is set via its set method right before Process's initState() is
called, shown as below.
ctc->setUseForClone(true);
cp->initState();
p->clone(tc, ctc, cp, flags);
A few previously failed RISC-V ASM tests have been open in tests.py file
after the bug fix works.
JIRA issue: https://gem5.atlassian.net/browse/GEM5-374
Change-Id: Ibffe46522e2617443d29f49df180692c54830f14
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37315
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This will eventually let subclasses provide their own appropriately
sized storage for these indexes. By using a pointer to member instead of
a regular pointer, we ensure that even if the StaticInst is copied/moved
somewhere, it will still find its indexes correctly, without any
additional performance overhead or maintenance.
Unfortunately C++ has decided that arrays with known bounds are not
convertible/compatible with arrays with unknown bounds. I've found at
least two standards proposals in various stages of acceptance which say
that that's dumb and they should change that (because it's dumb and they
should change that), but in the mean time we can get everything to
compile by using the reinterpret_cast hammer. While this is
*technically* undefined behavior, it's basically not and should be
pretty safe.
Change-Id: Id747b0cf68d1a0b4809ebb66a32472187110d7d8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36876
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
