By separating out this utility class, we make it possible to build
embedded python modules into other binarys without dragging along lots
of other, unrelated gem5 dependencies.
Also, move the class from sim/init.hh (which is a largely unrelated
name) to python/embedded.hh which much more directly describes what that
file contains.
Change-Id: Ia83439144893ad8401a5d51003e2686d9c9b2d7b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49418
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Put that code into a singleton class in src/proto, so that it gets
called during initialization and teardown of gem5 without cluttering up
gem5Main. This also removes the need to use #ifdefs to guard for
actualling having protobuf support.
Change-Id: I93b5d994eee478a9c159a3f3d02b3e996af02a3e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49416
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Use pybind11 to avoid having to use the python C API directly, which is
simpler, easier to read, and less error prone. Also, use its
PYBIND11_EMBEDDED_MODULE macro to set up the _m5 module instead of a
callback which has to be proactively called from main().
Change-Id: I9c8bcebea934844d16a1fdd88f66a5e66ef0486f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49413
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
m5MainCommands had been a way to override the python code which would
get the python side of gem5 started, used by some "unit" tests which
were really tests of all of gem5 but focus on a particular area. Those
tests have either been converted into real unit tests or eliminated,
and so that mechanism is no longer needed.
This change eliminates that mechanism, and also uses pybind11 to
significantly simplify the code that calls m5.main().
Change-Id: I553ae17074cd5389708f1b7313630a13a6946d76
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49412
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously, the importer module was built into gem5 as a compressed
bytecode blob like all the other code, and it had to be singled out and
installed manually so that it could help bring in all the other modules.
That adds some amount of complexity since it has to be identified and
treated as a special case.
Instead, this change builds it into gem5 using pybind11's
PYBIND11_EMBEDDED_MODULE macro, and a string that gets evaluated into
the new module's __dict__. This means the importer module is
automatically available just by building in that .cc, and it can just be
imported to start using it.
Theoretically all the embedded python could be handled this way, but
that would mean building it into gem5 as raw strings which wouldn't even
be compiled into byte code until run time. That would take more space in
the binary, and also delay catching simple errors.
Change-Id: Ic600bf6bce41a53289a2833484a655dd5a226e03
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49410
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When the "path" argument is empty, use the file name of the node
referred to by the fd file descriptor. This matches the behavior of
"at" system calls when the TGT_AT_EMPTY_PATH flag is set. The system
calls themselves are responsible for checking for that flag, and
returning an error if an empty "path" is not allowed.
Change-Id: Ib48d91ff983b3edb6f65e83686b90d79d74f3471
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53683
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Instead, get the byte order from the workload. The workload has a better
idea what the byte order should be, for instance based on what software
it's loaded or how the hardware was configured, and this gets rid of a
use of TARGET_ISA which was setting a default endianness.
Change-Id: Ic5d8a6f69a664957c4f837e3799ff93397ccfc64
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52106
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
The workload would have a better idea of what it's endianness is than
the system object that holds it. This is the first step towards getting
rid of the getByteOrder method on the system object, which currently
checks TARGET_ISA to determine what the default endianness should be.
If it makes sense for a Workload, it could determine the endianness
dynamically by, for instance, reading it out of a binary image before
putting it into memory.
This does assume that the workload has a consistent endianness
throughout which may not be true, but this is not a new assumption.
Also, mark the SEWorkload SimObject class as "abstract", since it isn't
useful until they get subclassed by some arch specific version.
Change-Id: I8d4ba8382f22236a81f9738cc3506cdb97bdbfb2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52104
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This way there will always be a workload object, even if nothing needs
to be set up. This default can also be used in low_power_sweep.py,
where the workload object was just a placeholder.
This will allow required functionality like determining endianness of a
system into the workload, rather than (for instance) in the more generic
System object. This also makes accessing less essential functionality
simpler, because we don't have to detect whether the workload is there,
and can just return default, placeholder values from the StubWorkload.
Change-Id: Idfc3e75c65318d75a3eae6a19944ae1f79a2d111
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52103
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When calling a method in a superclass, you can/should use the super()
method to get a reference to that class. The python 2 version of that
method takes two parameters, the current class name, and the "self"
instance. The python 3 version takes no arguments. This is better for a
at least three reasons.
First, this version is less verbose because you don't have to specify
any arguments.
Second, you don't have to remember which argument goes where (I always
have to look it up), and you can't accidentally use the wrong class
name, or forget to update it if you copy code from a different class.
Third, this version will work correctly if you use a class decorator.
I don't know exactly how the mechanics of this work, but it is referred
to in a comment on this stackoverflow question:
https://stackoverflow.com/questions/681953/how-to-decorate-a-class
Change-Id: I427737c8f767e80da86cd245642e3b057121bc3b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52224
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
All syscalls with the "at" suffix rely on a directory file descriptor
(dirfd) and a pathname, provided as arguments to the syscall
If the pathname is relative, then it is interpreted relative to the
directory referred to by the file descriptor dirfd (rather than relative
to the current working directory of the calling process)
Prior to this patch, only the openat syscall was properly implemented.
Other syscalls were discarding the dirfd argument and producing
a warning instead
JIRA: https://gem5.atlassian.net/browse/GEM5-1098
Change-Id: I0cc20c6ef79fca8c8d1c2c9a52eb54ede3d51312
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51048
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Align allocation requests in Process::allocateMem to page boundaries,
rather than assume that they already are. This frees the caller from
having to know what boundary to align things to. The older version would
make the caller more aware of the extent of the allocation in theory,
but in reality the caller would just blindly perform the alignment like
this function is anyway.
Change-Id: I897714d4481d961255a9e44ae080135e507be199
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50757
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This made it skip over 70 pages to be "what it was before" my page table
changes. I'm not sure what changes this is referring to, and the class
which manages page tables in the guest memory uses the allocPhysPages
method to allocate its memory and would cooperate with anything else
using this mechanism without having to have special accomodation.
I removed this hack and hello world seems to work fine, but there may be
some other test case which exposes some problems.
Change-Id: I16e0d8835452df9c3e79738a1eed05b4cc9372b7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50349
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
In the MemPool object, the idea of a limit of the pool (largest page)
and the total number of pages were conflated, as was the page number of
the next "free" page and the total number of pages allocated. Both of
those would only be equivalent if the memory pool starts at address
zero, which is not generally true and could be true for at most one pool
at a time even when it is occasionally true.
Instead, this change fixes up MemPool to keep tree values, a starting
page number, the page number of the next free page, and the total number
of pages in the pool, both allocated and unallocated.
With those three values, we can accurately report the number of
allocated pages (not just the number of pages of any kind below the next
free one), the total number of free pages, and the total number of pages
in general (not the largest numbered page in the pool).
The value serialized by the System class was adjusted so that it will
stay compatible with previous checkpoints. The value unserialized by the
system class is passed to the MemPool as a limit, which has not changed
and so doesn't need to be updated. It gets translated into the total
number of pages in the MemPool constructor.
Change-Id: I8268ef410b41bf757df9ee5585ec2f6b0d8499e1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50687
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Turn the functions within it into virtual methods on the ISA classes.
Eliminate the implementation in MIPS, which was just copy pasted from
Alpha long ago. Fix some minor style issues in ARM. Remove templating.
Switch from using an "XC" type parameter to using the ThreadContext *
installed in all ISA classes.
The ARM version of these functions actually depend on the ExecContext
delaying writes to MiscRegs to work correctly. More insiduously than
that, they also depend on the conicidental ThreadContext like
availability of certain functions like contextId and getCpuPtr which
come from the class which happened to implement the type passed into XC.
To accomodate that, those functions need both a real ThreadContext, and
another object which is either an ExecContext or a ThreadContext
depending on how the method is called.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1053
Change-Id: I68f95f7283f831776ba76bc5481bfffd18211bc4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50087
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add a unit test for sim/serialize.hh.
==Bugs==
arrayParamIn cannot parse strings with spaces. Since spaces
are used as delimiters, strings containing spaces are parsed
as multiple entries of the array. The test that checks for
this has been disabled.
==Unexpected Behavior==
Serialization has an unexpected behavior when returning to
previous scopes. For example,
...
SCS scs(cpt, "S1")
paramOut(cpt, "param1", integer1)
{
SCS scs_2(cpt, "S2")
paramOut(cpt, "param2", integer2)
}
paramOut(cpt, "param3", integer3)
will generate the output:
...
[S1]
param1=1
[S2]
param2=2
param3=3
But the user might expect:
...
[S1]
param1=1
[S2]
param2=2
[S1]
param3=3
==Incovenient Behavior==
arrayParamIn with a std::array parameter is slightly
incovenient, since the raw data pointer must be extracted.
It may be worth it to add a template specialization.
==Not Tested==
paramInImpl is not being directly tested because it should
not be used as an external API - paramIn and optParamIn
should be used instead.
arrayParamIn with an InsertIterator parameter is not being
directly tested because the other versions should be used
instead.
Change-Id: If0c8f045aa317790d5fcb32e48629b113b62efc5
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41337
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
