[gem5-dev] Build failed in Jenkins: Compiler-Checks #20

2020-08-29 Thread jenkins-no-reply--- via gem5-dev 
See 


Changes:

[ciro.santilli] tests: ignore 32-bit arm dual linux boot tests

[giacomo.travaglini] arch-arm: Refactor Address Translation (AT) code

[giacomo.travaglini] arch-arm: Remove deadcode from AArch64 address translation

[giacomo.travaglini] arch-arm: Rewrite addressTranslation to use BitUnions

[Jason Lowe-Power] python: Add DeprecatedParam type

[shparekh] mem: Deprecate SlavePort and MasterPort classes

[shparekh] misc: Updated port classes & refs to remove slaveBind()/UnBind()

[shparekh] learning-gem5: update port terminology

[shparekh] arch: update port terminology

[shparekh] cpu: update port terminology

[shparekh] gpu-compute: update port terminology

[shparekh] mem: Update port terminology

[shparekh] dev: Update port terminology

[shparekh] systemc,sim: Update port terminology

[gabeblack] sim: Fix up the selectFunc syscall to work with g++ 10.2.

[yuhsingw] systemc: Send response to TLM side if a packet does not need response

[anthony.gutierrez] gpu-compute: Create CU's ports in the standard way

[gabeblack] util: Explicitly decode/encode in utf-8.

[kyleroarty1716] arch-gcn3: Update LmReqsInPipe in atomic flats when execMask=0

[gabeblack] power: Tidy up isa_traits.hh and delete the VAddr class.

[gabeblack] riscv: Remove unnecessary includes from arch/riscv/isa_traits.hh.

[ianjiang.ict] arch-riscv: Fix disassembling of jalr

[gabeblack] sparc: Minor cleanup in isa_traits.hh.

[gabeblack] misc: Clean up usage of arch/isa_traits.hh.

[gabeblack] cpu: Factor the page size out of the decode cache.

[gabeblack] tests: Use a docker image to build gem5.

[Andreas.Sandberg] python: Add support for introspecting scalar stats

[giacomo.travaglini] arch-arm: Introduce HavePACExt helper

[giacomo.travaglini] arch-arm: Check if PAC is implemented before executing 
insts

[giacomo.travaglini] arch-arm: Fix coding style in addressTranslation methods

[richard.cooper] configs: Update starter_fs.py for latest Arm FS binaries.

[Bobby R. Bruce] util: Added GCN-GPU to cloudbuild_create_images

[Bobby R. Bruce] util: Updated Dockfiles with the libelf-dev dep


--
Started by user Bobby R. Bruce
Running as SYSTEM
Building in workspace 
The recommended git tool is: NONE
No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://gem5.googlesource.com/public/gem5 # 
 > timeout=10
Fetching upstream changes from https://gem5.googlesource.com/public/gem5
 > git --version # timeout=10
 > git --version # 'git version 2.25.1'
 > git fetch --tags --force --progress -- 
 > https://gem5.googlesource.com/public/gem5 
 > +refs/heads/*:refs/remotes/origin/* # timeout=10
 > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/develop^{commit} # timeout=10
Checking out Revision 0cf67fb36281b17956d4dc10f05054bf711b4ba3 
(refs/remotes/origin/develop)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 0cf67fb36281b17956d4dc10f05054bf711b4ba3 # timeout=10
Commit message: "util: Updated Dockfiles with the libelf-dev dep"
 > git rev-list --no-walk 5d420afaa037e41dd0480218db28f08e65279d93 # timeout=10
[Compiler-Checks] $ /bin/sh -xe /tmp/jenkins6609813153786127086.sh
+ ./util/compiler-tests.sh -j 4
Starting build tests with 'gcc-version-10'...
'gcc-version-10' was found in the comprehensive tests. All ISAs will be built.
  * Building target 'X86_MOESI_AMD_Base.opt' with 'gcc-version-10'...
Done.
  * Building target 'X86_MOESI_AMD_Base.fast' with 'gcc-version-10'...
Done.
  * Building target 'POWER.opt' with 'gcc-version-10'...
Done.
  * Building target 'POWER.fast' with 'gcc-version-10'...
Done.
  * Building target 'RISCV.opt' with 'gcc-version-10'...
Done.
  * Building target 'RISCV.fast' with 'gcc-version-10'...
Done.
  * Building target 'NULL_MOESI_CMP_token.opt' with 'gcc-version-10'...
Done.
  * Building target 'NULL_MOESI_CMP_token.fast' with 'gcc-version-10'...
Done.
  * Building target 'NULL_MOESI_CMP_directory.opt' with 'gcc-version-10'...
Done.
  * Building target 'NULL_MOESI_CMP_directory.fast' with 'gcc-version-10'...
Done.
  * Building target 'GCN3_X86.opt' with 'gcc-version-10'...
  ! Failed with exit code 2.
  * Building target 'GCN3_X86.fast' with 'gcc-version-10'...
  ! Failed with exit code 2.
  * Building target 'ARM.opt' with 'gcc-version-10'...
Done.
  * Building target 'ARM.fast' with 'gcc-version-10'...
Done.
  * Building target 'NULL_MOESI_hammer.opt' with 'gcc-version-10'...
Done.
  * Building target 'NULL_MOESI_hammer.fast' with 'gcc-version-10'...
Done.
  * Building target 'Garnet_standalone.opt' with 'gcc-version-10'...
Done.
  * Building target 'Garnet_standalone.fast' with 'gcc-version-10'...

[gem5-dev] Arch and operating system detection in SE mode

2020-08-29 Thread Gabe Black via gem5-dev 
Hi folks. Right now, when you want to run a particular binary in SE mode,
you assign it to the "workload" parameter of a CPU. When gem5 goes to load
it, it passes it around to different loaders and sees which one knows how
to load it. Then it passes it around a second time to see which process
type it should be, ie 64 bit x86, 32 bit ARM, etc.

binary -> {binary format loader} -> ObjectFile -> {arch and op sys process
loader} -> Process

I'm working on introducing a Workload type which encapsulates SE mode, and
which will have a type for each type of operating system being emulated. So
for instance, if you want your system to pretend to run x86 linux, you
would construct a object of type EmuX86Linux and set the system's workload
parameter to it. Then you would tell that object what you wanted to load
and how you wanted it to run (CPU assignments, etc.)

The minor mismatch here is that many scripts, for instance
configs/example/se.py, don't care what type of binary you've given it, what
operating system it's for, or what the architecture is. They just pass it
through, and let gem5 figure out what it can/should do with it.

To address this, I'm planning to expose the ObjectFile class to python, and
to add two methods to the SEWorkload SimObject type, find_compatible and
init_compatible.

Both methods will take a path to a binary. find_compatible will then return
a list of all SEWorkload subclasses which claim to be able to run that
binary. This will usually, but not necessarily, be one or zero classes. The
init_compatible method calls find_compatible expecting exactly one result,
and then instantiates an instance of that type using the rest of its
arguments.

So, if you want to run binary foo.bin, you would set your system's workload
parameter like this:

System(workload = SEWorkload.init_compatible("foo.bin", val1, param2=val2,
etc...))

If you know which fake operating system you want and want to take advantage
of non-generic features it might have, then you can just instantiate it
directly like normal.

System(workload = EmuArmFreeBSD(val1, freebsd_param2=val2, etc...))

An SEWorkload can claim compatibility with a binary by implementing an
_is_compatible_with class method which accepts an object file as a
parameter. For x86 linux that might look like this:

@classmethod
def _is_compatible_with(cls, obj):
return obj.get_arch() in ('x86_64', 'i386') and obj.get_op_sys() ==
'linux'
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: configs: Add parameter for GPU scalar cache mandatory queue size

2020-08-29 Thread Kyle Roarty (Gerrit) via gem5-dev 
Kyle Roarty has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/32676 )


Change subject: configs: Add parameter for GPU scalar cache mandatory queue  
size

..

configs: Add parameter for GPU scalar cache mandatory queue size

There was a missing option (--buffers-size) used to set the mandatory
queue size for the scalar controllers. This patch renames the option to
be more clear, and adds it to the argument parser.

Default of 128 taken from the implementation on the GCN staging branch

Change-Id: I58b6b57be07498cdf6e39c0bb85982674ec4caa6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32676
Reviewed-by: Matt Sinclair 
Maintainer: Anthony Gutierrez 
Tested-by: kokoro 
---
M configs/ruby/GPU_VIPER.py
1 file changed, 4 insertions(+), 1 deletion(-)

Approvals:
  Matt Sinclair: Looks good to me, approved
  Anthony Gutierrez: Looks good to me, approved
  kokoro: Regressions pass



diff --git a/configs/ruby/GPU_VIPER.py b/configs/ruby/GPU_VIPER.py
index 50ccd2b..6a6dec5 100644
--- a/configs/ruby/GPU_VIPER.py
+++ b/configs/ruby/GPU_VIPER.py
@@ -399,6 +399,9 @@

 parser.add_option("--noL1", action = "store_true", default = False,
   help = "bypassL1")
+parser.add_option("--scalar-buffer-size", type = 'int', default = 128,
+  help="Size of the mandatory queue in the GPU scalar "
+  "cache controller")

 def create_system(options, full_system, system, dma_devices, bootmem,
   ruby_system):
@@ -676,7 +679,7 @@
 scalar_cntrl.responseToSQC.slave = ruby_system.network.master

 scalar_cntrl.mandatoryQueue = \
-MessageBuffer(buffer_size=options.buffers_size)
+MessageBuffer(buffer_size=options.scalar_buffer_size)

 gpuCluster.add(scalar_cntrl)


--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/32676
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I58b6b57be07498cdf6e39c0bb85982674ec4caa6
Gerrit-Change-Number: 32676
Gerrit-PatchSet: 6
Gerrit-Owner: Kyle Roarty 
Gerrit-Reviewer: Anthony Gutierrez 
Gerrit-Reviewer: Bradford Beckmann 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Kyle Roarty 
Gerrit-Reviewer: Matt Sinclair 
Gerrit-Reviewer: kokoro 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: mem-ruby: Make DMASequencer aware of Atomics

2020-08-29 Thread Matthew Poremba (Gerrit) via gem5-dev 
Matthew Poremba has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/33716 )



Change subject: mem-ruby: Make DMASequencer aware of Atomics
..

mem-ruby: Make DMASequencer aware of Atomics

Add handling for issuing atomic packet types, setting the WriteMask and
AtomicOpFunctor in makeRequest. Add an atomicCallback to handle atomic
packet type responses.

Change-Id: I9775fc110bb99a1740089746f0d1b3deb124b9f5
---
M src/mem/ruby/protocol/RubySlicc_Exports.sm
M src/mem/ruby/protocol/RubySlicc_Types.sm
M src/mem/ruby/system/DMASequencer.cc
M src/mem/ruby/system/DMASequencer.hh
4 files changed, 51 insertions(+), 1 deletion(-)



diff --git a/src/mem/ruby/protocol/RubySlicc_Exports.sm  
b/src/mem/ruby/protocol/RubySlicc_Exports.sm

index f1d17c8..ef5aca4 100644
--- a/src/mem/ruby/protocol/RubySlicc_Exports.sm
+++ b/src/mem/ruby/protocol/RubySlicc_Exports.sm
@@ -277,6 +277,7 @@
   SequencerRequestType Type, desc="Type of request (LD, ST, etc)";
   Addr ProgramCounter,desc="Program counter of the instruction that  
caused the miss";

   RubyAccessMode AccessMode, desc="user/supervisor access type";
+  WriteMask writeMask,   desc="WriteMask for atomics";
   DataBlock DataBlk, desc="Data";
   int Len,   desc="size in bytes of access";
   PrefetchBit Prefetch,  desc="Is this a prefetch request";
diff --git a/src/mem/ruby/protocol/RubySlicc_Types.sm  
b/src/mem/ruby/protocol/RubySlicc_Types.sm

index 71716f9..f86ca44 100644
--- a/src/mem/ruby/protocol/RubySlicc_Types.sm
+++ b/src/mem/ruby/protocol/RubySlicc_Types.sm
@@ -200,6 +200,7 @@
 structure (DMASequencer, external = "yes") {
   void ackCallback(Addr);
   void dataCallback(DataBlock,Addr);
+  void atomicCallback(DataBlock,Addr);
   void recordRequestType(CacheRequestType);
 }

diff --git a/src/mem/ruby/system/DMASequencer.cc  
b/src/mem/ruby/system/DMASequencer.cc

index bad49c9..eb6b1c9 100644
--- a/src/mem/ruby/system/DMASequencer.cc
+++ b/src/mem/ruby/system/DMASequencer.cc
@@ -96,7 +96,35 @@
 std::make_shared(clockEdge());
 msg->getPhysicalAddress() = paddr;
 msg->getLineAddress() = line_addr;
-msg->getType() = write ? SequencerRequestType_ST :  
SequencerRequestType_LD;

+
+if (pkt->req->isAtomic()) {
+msg->setType(SequencerRequestType_ATOMIC);
+
+// While regular LD/ST can support DMAs spanning multiple cache  
lines,
+// atomic requests are only supported within a single cache line.  
The
+// atomic request will end upon atomicCallback and not call  
issueNext.

+int block_size = m_ruby_system->getBlockSizeBytes();
+int atomic_offset = pkt->getAddr() - line_addr;
+std::vector access_mask(block_size, false);
+assert(atomic_offset + pkt->getSize() <= block_size);
+
+for (int idx = 0; idx < pkt->getSize(); ++idx) {
+access_mask[atomic_offset + idx] = true;
+}
+
+std::vector> atomic_ops;
+std::pair
+atomic_op(atomic_offset, pkt->getAtomicOp());
+
+atomic_ops.emplace_back(atomic_op);
+msg->getwriteMask().setAtomicOps(atomic_ops);
+} else if (write) {
+msg->setType(SequencerRequestType_ST);
+} else {
+assert(pkt->isRead());
+msg->setType(SequencerRequestType_LD);
+}
+
 int offset = paddr & m_data_block_mask;

 msg->getLen() = (offset + len) <= RubySystem::getBlockSizeBytes() ?
@@ -197,6 +225,25 @@
 }

 void
+DMASequencer::atomicCallback(const DataBlock& dblk, const Addr& address)
+{
+RequestTable::iterator i = m_RequestTable.find(address);
+assert(i != m_RequestTable.end());
+
+DMARequest &active_request = i->second;
+PacketPtr pkt = active_request.pkt;
+
+int offset = active_request.start_paddr & m_data_block_mask;
+memcpy(pkt->getPtr(), dblk.getData(offset, pkt->getSize()),
+   pkt->getSize());
+
+ruby_hit_callback(pkt);
+
+m_outstanding_count--;
+m_RequestTable.erase(i);
+}
+
+void
 DMASequencer::recordRequestType(DMASequencerRequestType requestType)
 {
 DPRINTF(RubyStats, "Recorded statistic: %s\n",
diff --git a/src/mem/ruby/system/DMASequencer.hh  
b/src/mem/ruby/system/DMASequencer.hh

index a3ee8af..c47e45f 100644
--- a/src/mem/ruby/system/DMASequencer.hh
+++ b/src/mem/ruby/system/DMASequencer.hh
@@ -70,6 +70,7 @@
 /* SLICC callback */
 void dataCallback(const DataBlock &dblk, const Addr &addr);
 void ackCallback(const Addr &addr);
+void atomicCallback(const DataBlock &dblk, const Addr &addr);

 void recordRequestType(DMASequencerRequestType requestType);


--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/33716
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I9775fc110bb99a1740089746f0d1b3deb124b9

[gem5-dev] Re: For gem5 20.1: Remove "master" and replace with new "stable" default branch (?)

2020-08-29 Thread Daniel Carvalho via gem5-dev 
 +1
Seems like an excellent rename choice!
Em sábado, 29 de agosto de 2020 02:58:57 GMT+2, Jason Lowe-Power via 
gem5-dev  escreveu:  
 
 +1
Thanks for getting the ball rolling on this, Bobby!

On Fri, Aug 28, 2020 at 5:26 PM Bobby Bruce via gem5-dev  
wrote:

Dear all,
Back when we moved from the master branch being under constant development to a 
dual "master-as-stable" and "develop" branch setup, there was talk of renaming 
the master branch. Though, at this time, it seemed unconventional so avoided 
doing so. In the past few months there has been greater momentum in the 
direction of allowing git repositories to call their default branch whatever 
they wish. For example, Github is reworking things in this regard 
(https://github.com/github/renaming/) and defaulting new repos to have "main" 
as the default branch.
Our GoogleSource/Gerrit setup allows us to set HEAD to point towards whatever 
branch we wish. We therefore think v20.1 would be a good time to rename 
"master" to "stable". This afternoon I created a "stable" branch, identical to 
"master", here: https://gem5.googlesource.com/public/gem5/+/refs/heads/stable. 
The next step would be to redirect HEAD to this branch, then delete the master 
branch. Coinciding this with the release of v20.1 (in roughly 2 weeks time) 
seems like an ideal timing.

I'm writing this email to ask if the community agrees with this, and if there 
is anything I'm not taking into account. I believe this should be a fairly 
seamless transition, and will give our two branches more descriptive names  --- 
stable and develop.

Kind regards,Bobby
--
Dr. Bobby R. Bruce
Room 2235,
Kemper Hall, UC Davis
Davis,
CA, 95616
web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s  ___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Jenkins build is back to normal : gem5_develop #156

2020-08-29 Thread jenkins-no-reply--- via gem5-dev 
See 

___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Namespace creation on develop branch

2020-08-29 Thread Gabe Black via gem5-dev 
PTAL

https://gem5-review.googlesource.com/c/public/gem5/+/33695
https://gem5.atlassian.net/browse/GEM5-753

Gabe

On Thu, Aug 27, 2020 at 4:24 AM Daniel Carvalho via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hello,
>
>
> This message only concerns those who use the *develop* branch.
>
>
> We have recently merged another patch creating a namespace (
> https://gem5-review.googlesource.com/c/public/gem5/+/33294). Due to a
> small issue with the SCons configuration, it does not trigger automatic
> recompilation of the params file of the BaseCache class, so recompilation
> must be forced manually; otherwise, the old name without the namespace will
> be used, and a compilation error will pop up.
>
>
> More details can be found in this thread:
> https://www.mail-archive.com/gem5-dev@gem5.org/msg35502.html .
>
>
> If more patches creating namespaces are merged in the future, similar
> situations may happen; nonetheless, the solution is analogous.
>
>
> Regards,
>
> Daniel
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: ext: Force testlib to only create one Log object

2020-08-29 Thread Hoa Nguyen (Gerrit) via gem5-dev 
Hoa Nguyen has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/33715 )



Change subject: ext: Force testlib to only create one Log object
..

ext: Force testlib to only create one Log object

Log object should remain being a singleton throughout the program.
The current code creates multiple Log objects, which at least
causes the issues of missing outputs in stdout.

E.g., "Logging call to command", which logs which command is
being called in a subprocess, is missing from stdout.

Change-Id: I96c5dd79c4f14e0a013c15d42d202397488d56b6
Signed-off-by: Hoa Nguyen 
---
M ext/testlib/runner.py
1 file changed, 3 insertions(+), 1 deletion(-)



diff --git a/ext/testlib/runner.py b/ext/testlib/runner.py
index 7425e79..6efab80 100644
--- a/ext/testlib/runner.py
+++ b/ext/testlib/runner.py
@@ -77,7 +77,9 @@
 def __init__(self, test, suite):
 self.test = test
 self.suite = suite
-self.log = log.Log(test)
+#self.log = log.Log(test)
+self.log = log.test_log
+self.log.test = test

 @helper.cacheresult
 def _fixtures(self):

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/33715
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I96c5dd79c4f14e0a013c15d42d202397488d56b6
Gerrit-Change-Number: 33715
Gerrit-PatchSet: 1
Gerrit-Owner: Hoa Nguyen 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: scons: Make scons aware of changes to cxx_type in param types.

2020-08-29 Thread Gabe Black (Gerrit) via gem5-dev 
Gabe Black has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/33695 )



Change subject: scons: Make scons aware of changes to cxx_type in param  
types.

..

scons: Make scons aware of changes to cxx_type in param types.

If the cxx_type value changes, then the way the parameter is declared
in the param struct will also change, and the header needs to be
updated. scons would miss this sort of change before because it was only
checking the module the SimObject's source came from. The python names
and types of the parameters could stay the same, but the C++
representation might have changed because of edits somewhere else.

This CL assumes that cxx_type is the only thing that will change and
transparently affect the params struct. I tried making scons sensitive
to the entire ptype which would capture other parameters, but that
didn't work for some reason. This should be pretty safe in general, but
not 100% safe

Issue-on: https://gem5.atlassian.net/browse/GEM5-753
Change-Id: I06774889e60b987f727799f55d7ea2a775b6a319
---
M src/SConscript
1 file changed, 8 insertions(+), 0 deletions(-)



diff --git a/src/SConscript b/src/SConscript
index 66db2f7..d9cde28 100644
--- a/src/SConscript
+++ b/src/SConscript
@@ -922,9 +922,17 @@
 # Generate all of the SimObject param C++ struct header files
 params_hh_files = []
 for name,simobj in sorted(sim_objects.items()):
+# If this simobject's source changes, we need to regenerate the header.
 py_source = PySource.modules[simobj.__module__]
 extra_deps = [ py_source.tnode ]

+# Get the params for just this SimObject, excluding base classes.
+params = simobj._params.local.values()
+# Extract the parameters' c++ types.
+types = sorted(map(lambda p: p.ptype.cxx_type, params))
+# If any of these types have changed, we need to regenerate the header.
+extra_deps.append(Value(types))
+
 hh_file = File('params/%s.hh' % name)
 params_hh_files.append(hh_file)
 env.Command(hh_file, Value(name),

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/33695
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I06774889e60b987f727799f55d7ea2a775b6a319
Gerrit-Change-Number: 33695
Gerrit-PatchSet: 1
Gerrit-Owner: Gabe Black 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s