[gem5-dev] support for multiple threads over one remote GDB connection

2020-06-10 Thread Gabe Black via gem5-dev
Hey folks. I filed a bug in Jira a couple days ago about adding support for
multiple threads within a single remote GDB session over here:

https://gem5.atlassian.net/browse/GEM5-626?atlOrigin=eyJpIjoiNjE5ZDZlYzZkZTA2NDE3NGE3MGYyZTE3NWQ1YTk3NTQiLCJwIjoiaiJ9

It's fine (and welcome) for conversation about it to be over on the bug,
but I want to make sure people are aware it's over there and that it's
something I'm spending some time on.

Gabe
___
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]: sim: Delete an unused member in the System class.

2020-06-10 Thread Gabe Black (Gerrit) via gem5-dev
Gabe Black has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/30194 )


Change subject: sim: Delete an unused member in the System class.
..

sim: Delete an unused member in the System class.

This was supposed to be deleted as part of the change titled:
arch,cpu,dev,sim,mem: Collect System thread elements into a subclass.

but it was left out of the checked in version somehow.

Change-Id: I0dbb0b4fa6ae29649a80d1cb883e48ad50116c31
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30194
Maintainer: Gabe Black 
Reviewed-by: Jason Lowe-Power 
Tested-by: kokoro 
---
M src/sim/system.hh
1 file changed, 0 insertions(+), 1 deletion(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved
  Gabe Black: Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/sim/system.hh b/src/sim/system.hh
index 530c5ea..192f9f4 100644
--- a/src/sim/system.hh
+++ b/src/sim/system.hh
@@ -532,7 +532,6 @@
 void workItemEnd(uint32_t tid, uint32_t workid);

   public:
-std::vector remoteGDB;
 bool breakpoint();

   public:

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/30194
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: I0dbb0b4fa6ae29649a80d1cb883e48ad50116c31
Gerrit-Change-Number: 30194
Gerrit-PatchSet: 2
Gerrit-Owner: Gabe Black 
Gerrit-Reviewer: Bobby R. Bruce 
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
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]: sim: Delete an unused member in the System class.

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



Change subject: sim: Delete an unused member in the System class.
..

sim: Delete an unused member in the System class.

This was supposed to be deleted as part of the change titled:
arch,cpu,dev,sim,mem: Collect System thread elements into a subclass.

but it was left out of the checked in version somehow.

Change-Id: I0dbb0b4fa6ae29649a80d1cb883e48ad50116c31
---
M src/sim/system.hh
1 file changed, 0 insertions(+), 1 deletion(-)



diff --git a/src/sim/system.hh b/src/sim/system.hh
index 530c5ea..192f9f4 100644
--- a/src/sim/system.hh
+++ b/src/sim/system.hh
@@ -532,7 +532,6 @@
 void workItemEnd(uint32_t tid, uint32_t workid);

   public:
-std::vector remoteGDB;
 bool breakpoint();

   public:

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/30194
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: I0dbb0b4fa6ae29649a80d1cb883e48ad50116c31
Gerrit-Change-Number: 30194
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


[gem5-dev] Change in gem5/gem5[develop]: mem-ruby: add cache hit/miss statistics for TCP and TCC

2020-06-10 Thread Kyle Roarty (Gerrit) via gem5-dev
Kyle Roarty has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/30174 )



Change subject: mem-ruby: add cache hit/miss statistics for TCP and TCC
..

mem-ruby: add cache hit/miss statistics for TCP and TCC

Change-Id: Ifa6fdbb9dd062a3684b9620eac6683c57e651a72
---
M src/mem/ruby/protocol/GPU_VIPER-TCC.sm
M src/mem/ruby/protocol/GPU_VIPER-TCP.sm
2 files changed, 44 insertions(+), 1 deletion(-)



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

index 5f05a60..c4c4c3e 100644
--- a/src/mem/ruby/protocol/GPU_VIPER-TCC.sm
+++ b/src/mem/ruby/protocol/GPU_VIPER-TCC.sm
@@ -438,6 +438,14 @@
 }
   }

+  action(p_profileMiss, "pm", desc="Profile cache miss") {
+  ++L2cache.demand_misses;
+  }
+
+  action(p_profileHit, "ph", desc="Profile cache hit") {
+  ++L2cache.demand_hits;
+  }
+
   action(t_allocateTBE, "t", desc="allocate TBE Entry") {
 if (is_invalid(tbe)) {
   check_allocate(TBEs);
@@ -596,28 +604,42 @@
   z_stall;
   }
   transition({M, V}, RdBlk) {TagArrayRead, DataArrayRead} {
+p_profileHit;
 sd_sendData;
 ut_updateTag;
 p_popRequestQueue;
   }
   transition(W, RdBlk, WI) {TagArrayRead, DataArrayRead} {
+p_profileHit;
 t_allocateTBE;
 wb_writeBack;
   }

   transition(I, RdBlk, IV) {TagArrayRead} {
+p_profileMiss;
 t_allocateTBE;
 rd_requestData;
 p_popRequestQueue;
   }

   transition(IV, RdBlk) {
+p_profileMiss;
 t_allocateTBE;
 rd_requestData;
 p_popRequestQueue;
   }

-  transition({V, I},Atomic, A) {TagArrayRead} {
+  transition(V, Atomic, A) {TagArrayRead} {
+p_profileHit;
+i_invL2;
+t_allocateTBE;
+at_atomicThrough;
+ina_incrementNumAtomics;
+p_popRequestQueue;
+  }
+
+transition(I, Atomic, A) {TagArrayRead} {
+p_profileMiss;
 i_invL2;
 t_allocateTBE;
 at_atomicThrough;
@@ -626,22 +648,26 @@
   }

   transition(A, Atomic) {
+p_profileMiss;
 at_atomicThrough;
 ina_incrementNumAtomics;
 p_popRequestQueue;
   }

   transition({M, W}, Atomic, WI) {TagArrayRead} {
+p_profileHit;
 t_allocateTBE;
 wb_writeBack;
   }

   transition(I, WrVicBlk) {TagArrayRead} {
+p_profileMiss;
 wt_writeThrough;
 p_popRequestQueue;
   }

   transition(V, WrVicBlk) {TagArrayRead, DataArrayWrite} {
+p_profileHit;
 ut_updateTag;
 wdb_writeDirtyBytes;
 wt_writeThrough;
@@ -649,6 +675,7 @@
   }

   transition({V, M}, WrVicBlkBack, M) {TagArrayRead, TagArrayWrite,  
DataArrayWrite} {

+p_profileHit;
 ut_updateTag;
 swb_sendWBAck;
 wdb_writeDirtyBytes;
@@ -656,6 +683,7 @@
   }

   transition(W, WrVicBlkBack) {TagArrayRead, TagArrayWrite,  
DataArrayWrite} {

+p_profileHit;
 ut_updateTag;
 swb_sendWBAck;
 wdb_writeDirtyBytes;
@@ -663,6 +691,7 @@
   }

   transition(I, WrVicBlkBack, W) {TagArrayRead, TagArrayWrite,  
DataArrayWrite} {

+p_profileMiss;
 a_allocateBlock;
 ut_updateTag;
 swb_sendWBAck;
diff --git a/src/mem/ruby/protocol/GPU_VIPER-TCP.sm  
b/src/mem/ruby/protocol/GPU_VIPER-TCP.sm

index 3f61791..e09dc2e 100644
--- a/src/mem/ruby/protocol/GPU_VIPER-TCP.sm
+++ b/src/mem/ruby/protocol/GPU_VIPER-TCP.sm
@@ -527,6 +527,16 @@
   // built-int action
   }

+// added for profiling
+  action(uu_profileDataMiss, "\udm", desc="Profile the demand miss"){
+  ++L1cache.demand_misses;
+  }
+
+  action(uu_profileDataHit, "\udh", desc="Profile the demand hit"){
+  ++L1cache.demand_hits;
+  }
+
+
   // Transitions
   // ArrayRead/Write assumptions:
   // All requests read Tag Array
@@ -544,12 +554,14 @@

   transition(I, Load) {TagArrayRead} {
 n_issueRdBlk;
+uu_profileDataMiss;
 p_popMandatoryQueue;
   }

   transition(V, Load) {TagArrayRead, DataArrayRead} {
 l_loadDone;
 mru_updateMRU;
+uu_profileDataHit;
 p_popMandatoryQueue;
   }

@@ -564,6 +576,7 @@
 a_allocate;
 dw_dirtyWrite;
 s_storeDone;
+uu_profileDataMiss;
 wt_writeThrough;
 ic_invCache;
 p_popMandatoryQueue;
@@ -572,6 +585,7 @@
   transition(V, StoreThrough, I) {TagArrayRead, TagArrayWrite,  
DataArrayWrite} {

 dw_dirtyWrite;
 s_storeDone;
+uu_profileDataHit;
 wt_writeThrough;
 ic_invCache;
 p_popMandatoryQueue;

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/30174
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: Ifa6fdbb9dd062a3684b9620eac6683c57e651a72
Gerrit-Change-Number: 30174
Gerrit-PatchSet: 1
Gerrit-Owner: Kyle Roarty 
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]: sim-se: Ignore unimplemented system call

2020-06-10 Thread Kyle Roarty (Gerrit) via gem5-dev
Kyle Roarty has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/30154 )



Change subject: sim-se: Ignore unimplemented system call
..

sim-se: Ignore unimplemented system call

System call sched_setaffinity causes crashes when running programs
that use ROCm. Ignoring the system call allows for the programs
to run to completion.

Change-Id: I27c767ef81091789e228d47f2bb5f6fa18f11539
---
M src/arch/x86/linux/process.cc
1 file changed, 2 insertions(+), 2 deletions(-)



diff --git a/src/arch/x86/linux/process.cc b/src/arch/x86/linux/process.cc
index 2c594e7..3a86b76 100644
--- a/src/arch/x86/linux/process.cc
+++ b/src/arch/x86/linux/process.cc
@@ -460,7 +460,7 @@
 { 200, "tkill" },
 { 201, "time", timeFunc },
 { 202, "futex", futexFunc },
-{ 203, "sched_setaffinity" },
+{ 203, "sched_setaffinity", ignoreFunc },
 { 204, "sched_getaffinity", ignoreFunc },
 { 205, "set_thread_area" },
 { 206, "io_setup" },
@@ -837,7 +837,7 @@
 { 238, "tkill" },
 { 239, "sendfile64" },
 { 240, "futex" },
-{ 241, "sched_setaffinity" },
+{ 241, "sched_setaffinity", ignoreFunc },
 { 242, "sched_getaffinity", ignoreFunc },
 { 243, "set_thread_area", setThreadArea32Func },
 { 244, "get_thread_area" },

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/30154
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: I27c767ef81091789e228d47f2bb5f6fa18f11539
Gerrit-Change-Number: 30154
Gerrit-PatchSet: 1
Gerrit-Owner: Kyle Roarty 
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]: misc: Reverted version information to "develop"

2020-06-10 Thread Bobby R. Bruce (Gerrit) via gem5-dev
Bobby R. Bruce has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/29833 )


Change subject: misc: Reverted version information to "develop"
..

misc: Reverted version information to "develop"

Change-Id: I6ee1bae48f2dd0d868dfbb428e93deeb9ee93083
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/29833
Reviewed-by: Bobby R. Bruce 
Maintainer: Bobby R. Bruce 
Tested-by: kokoro 
---
M ext/testlib/configuration.py
M src/Doxyfile
M src/base/version.cc
3 files changed, 3 insertions(+), 3 deletions(-)

Approvals:
  Bobby R. Bruce: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/ext/testlib/configuration.py b/ext/testlib/configuration.py
index 04744e1..b7c4697 100644
--- a/ext/testlib/configuration.py
+++ b/ext/testlib/configuration.py
@@ -221,7 +221,7 @@
   os.pardir))
 defaults.result_path = os.path.join(os.getcwd(), '.testing-results')
 defaults.list_only_failed = False
-defaults.resource_url = 'http://dist.gem5.org/dist/v20'
+defaults.resource_url = 'http://dist.gem5.org/dist/develop'

 def define_constants(constants):
 '''
diff --git a/src/Doxyfile b/src/Doxyfile
index cd1a947..c92a787 100644
--- a/src/Doxyfile
+++ b/src/Doxyfile
@@ -31,7 +31,7 @@
 # This could be handy for archiving the generated documentation or
 # if some version control system is used.

-PROJECT_NUMBER = v20.0.0.2
+PROJECT_NUMBER = DEVELOP-FOR-V20.1

 # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
 # base path where the generated documentation will be put.
diff --git a/src/base/version.cc b/src/base/version.cc
index 7e89b99..4419aa5 100644
--- a/src/base/version.cc
+++ b/src/base/version.cc
@@ -26,4 +26,4 @@
  * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */

-const char *gem5Version = "20.0.0.2";
+const char *gem5Version = "[DEVELOP-FOR-V20.1]";

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/29833
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: I6ee1bae48f2dd0d868dfbb428e93deeb9ee93083
Gerrit-Change-Number: 29833
Gerrit-PatchSet: 4
Gerrit-Owner: Bobby R. Bruce 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Daniel Carvalho 
Gerrit-Reviewer: Hoa Nguyen 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Jason Lowe-Power 
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] Re: [Suggestion] Replace gem5-users mailing-list with Discourse

2020-06-10 Thread Daniel Gerzhoy via gem5-dev
I think this is a great idea! Emails threads aren't a great way to do this
just because there's no mechanism for well formatted responses to
particular points in someone's questions, posting code, or things like
"upvoting" responses.

I see Daniel's point about less engagement if we move it to a forum, but I
think that could be alleviated by encouraging people to keep email
notifications up.

Cheers,

Dan

On Wed, Jun 10, 2020 at 5:23 AM Giacomo Travaglini via gem5-dev <
gem5-dev@gem5.org> wrote:

> I agree with Daniel and Ciro; it's difficult/annoying to navigate through
> old unanswered emails and I presume nobody does that at the moment.
> Most of the time if your email doesn't get a quick response as soon as it
> gets posted, you can forget about getting some help as time passes; there
> is a short window and you really have to hope someone flagged your email or
> got some time to address your problem.
>
> I wouldn't use JIRA to be honest for asking questions; that's beyond the
> scope of JIRA and it would be chaotic to mix Bug Reports, Improvement tasks
> with normal questions (like: I cannot build gem5 on my machine, or does
> anyone know how this works)
>
> Giacomo
>
>
> -Original Message-
> From: Ciro Santilli via gem5-dev 
> Sent: 10 June 2020 09:21
> To: gem5 Developer List 
> Cc: Ciro Santilli 
> Subject: [gem5-dev] Re: [Suggestion] Replace gem5-users mailing-list with
> Discourse
>
> I would just use JIRA. But after that, Discourse is the second best. And
> anything is better than a mailing list :-) 
> From: Jason Lowe-Power via gem5-dev 
> Sent: Tuesday, June 9, 2020 11:40 PM
> To: gem5 Developer List 
> Cc: gem5 users mailing list ; Jason Lowe-Power <
> ja...@lowepower.com>
> Subject: [gem5-dev] Re: [Suggestion] Replace gem5-users mailing-list with
> Discourse
>
> +1 for Discourse :).
>
> Just to give a bit more context: I'm also trying to find a good forum for
> community engagement during my online Learning gem5 class this summer. I
> would like to find a platform that could be used generally for my class
> this summer, future iterations of the class, and general gem5 questions, as
> I believe there will be significant overlap between these groups.
>
> Other potential options that IMO have more cons than pros when compared to
> Discourse:
> - Slack/Teams/etc.
> - gitter.im
> - stackoverflow
>
> That said, we're open to suggestions :). Our goal is to create the most
> welcoming and inclusive environment possible. We'll go where our users are!
>
> Cheers,
> Jason
>
> On Tue, Jun 9, 2020 at 2:45 PM Bobby Bruce via gem5-dev  >
> wrote:
>
> > Dear all,
> >
> > In an effort to better support the gem5 community, there has been a
> > suggestion that we drop the gem5-users mailing list and replace it
> > with Discourse, https://www.discourse.org/about, a web-based
> > discussion platform. I'm writing this email to propose this to the
> > community and ask for feedback on the matter.
> >
> > We have noticed that using mailing lists as our primary communication
> > platform is problematic. Sending an email to a list can be daunting
> > experience, requiring an etiquette many are not accustom to. I'm sure
> > I'm not the only one who feels like they are unduly bothering a large
> > number of people when posting to a list (like I'm doing right now :)
> > ). This is, of course, an unfortunate hurdle for many to get over when
> > they encounter problems using gem5, particularly those new to the
> > project. I've come to believe mailing lists are simply not a very good
> > technology for fostering community engagement and helping those who are
> running into difficulties.
> > Mailing lists are also difficult to search, and lack proper formatting
> > mechanisms to neatly display attributes such as code and output logs.
> >
> > Looking around at alternative technologies available, Discourse
> > appears to be a suitable replacement. For those unaware, Discourse is
> > (essentially) a revamp of messaging forums. It is an increasingly
> > popular platform for users and developers in open source projects to
> > communicate with one another (see LLVM's discourse as an example:
> > https://llvm.discourse.group ).
> > All-in-all, I think it's a well-designed product and contains all the
> > features we'd expect and need to get our work done. I can see no
> > immediate downsides to using it, though feedback from the community on
> > the matter would be greatly appreciated, particularly from those who
> > have used Discourse before. Dissenting opinions on the whole idea of
> > moving away from the gem5-user's mailing list are also welcome.
> >
> > So, let me know what you think! :)
> >
> > Please note, regardless as to any decision made, we will continue the
> > use of the gem5-dev mailing list for technical discussions for the
> > foreseeable future.
> >
> > Kind regards,
> > Bobby
> > --
> > Dr. Bobby R. Bruce
> > Room 2235,
> > Kemper Hall, UC Davis
> > Davis,
> > CA, 95616

[gem5-dev] Change in gem5/gem5[develop]: cpu, sim: Add faulting flag to instruction tracing interface

2020-06-10 Thread Giacomo Travaglini (Gerrit) via gem5-dev
Giacomo Travaglini has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/30134 )



Change subject: cpu, sim: Add faulting flag to instruction tracing interface
..

cpu, sim: Add faulting flag to instruction tracing interface

This patch adds a faulting flag to InstRecord and populates it
accordingly in atomic, timing, minor and o3 CPU models. This
allows tracers to identify that the traced instruction has
faulted, when ExecFaulting is enabled. It can be set with
InstRecord::setFaulting() and read with Instrecord::getFaulting().

This patch also fixes the minor CPU model which was not respecting
the ExecFaulting flag, which is now checked before calling dump() on
the tracing object, to bring it in line with the other CPU models.

Change-Id: I390392d59de930533eab101e96dc4d3c76500748
---
M src/sim/insttracer.hh
1 file changed, 13 insertions(+), 2 deletions(-)



diff --git a/src/sim/insttracer.hh b/src/sim/insttracer.hh
index 2e9806d..1cca3e1 100644
--- a/src/sim/insttracer.hh
+++ b/src/sim/insttracer.hh
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2014, 2017 ARM Limited
+ * Copyright (c) 2014, 2017, 2020 ARM Limited
  * All rights reserved
  *
  * The license below extends only to copyright in the software and shall
@@ -143,6 +143,12 @@
  */
 bool predicate;

+/**
+ * Did the execution of this instruction fault? (requires ExecFaulting
+ * to be enabled)
+ */
+bool faulting;
+
   public:
 InstRecord(Tick _when, ThreadContext *_thread,
const StaticInstPtr _staticInst,
@@ -151,7 +157,8 @@
 : when(_when), thread(_thread), staticInst(_staticInst), pc(_pc),
 macroStaticInst(_macroStaticInst), addr(0), size(0), flags(0),
 fetch_seq(0), cp_seq(0), data_status(DataInvalid),  
mem_valid(false),

-fetch_seq_valid(false), cp_seq_valid(false), predicate(true)
+fetch_seq_valid(false), cp_seq_valid(false), predicate(true),
+faulting(false)
 { }

 virtual ~InstRecord()
@@ -218,6 +225,8 @@

 void setPredicate(bool val) { predicate = val; }

+void setFaulting(bool val) { faulting = val; }
+
 virtual void dump() = 0;

   public:
@@ -241,6 +250,8 @@

 InstSeqNum getCpSeq() const { return cp_seq; }
 bool getCpSeqValid() const { return cp_seq_valid; }
+
+bool getFaulting(void) { return faulting; };
 };

 class InstTracer : public SimObject

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/30134
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: I390392d59de930533eab101e96dc4d3c76500748
Gerrit-Change-Number: 30134
Gerrit-PatchSet: 1
Gerrit-Owner: Giacomo Travaglini 
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]: cpu: Use new InstRecord faulting flag in cpu models

2020-06-10 Thread Giacomo Travaglini (Gerrit) via gem5-dev
Giacomo Travaglini has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/30135 )



Change subject: cpu: Use new InstRecord faulting flag in cpu models
..

cpu: Use new InstRecord faulting flag in cpu models

This patch sets the faulting flag in atomic, timing, minor and o3 CPU
models.

It also fixes the minor/timing CPU models which were not respecting the
ExecFaulting flag. This is now checked before calling dump() on the
tracing object, to bring it in line with the other CPU models.

Change-Id: I9c7b64cc5605596eb7fcf25fdecaeac5c4b5e3d7
---
M src/cpu/minor/execute.cc
M src/cpu/o3/commit_impl.hh
M src/cpu/simple/atomic.cc
M src/cpu/simple/base.cc
M src/cpu/simple/base.hh
M src/cpu/simple/timing.cc
6 files changed, 44 insertions(+), 23 deletions(-)



diff --git a/src/cpu/minor/execute.cc b/src/cpu/minor/execute.cc
index ddb8db3..9577549 100644
--- a/src/cpu/minor/execute.cc
+++ b/src/cpu/minor/execute.cc
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2013-2014,2018-2019 ARM Limited
+ * Copyright (c) 2013-2014,2018-2020 ARM Limited
  * All rights reserved
  *
  * The license below extends only to copyright in the software and shall
@@ -48,6 +48,7 @@
 #include "debug/Activity.hh"
 #include "debug/Branch.hh"
 #include "debug/Drain.hh"
+#include "debug/ExecFaulting.hh"
 #include "debug/MinorExecute.hh"
 #include "debug/MinorInterrupt.hh"
 #include "debug/MinorMem.hh"
@@ -980,6 +981,15 @@
 committed = true;

 if (fault != NoFault) {
+if (inst->traceData) {
+if (DTRACE(ExecFaulting)) {
+inst->traceData->setFaulting(true);
+} else {
+delete inst->traceData;
+inst->traceData = NULL;
+}
+}
+
 DPRINTF(MinorExecute, "Fault in execute of inst: %s  
fault: %s\n",

 *inst, fault->name());
 fault->invoke(thread, inst->staticInst);
diff --git a/src/cpu/o3/commit_impl.hh b/src/cpu/o3/commit_impl.hh
index 0f65e71..8e8ff6e 100644
--- a/src/cpu/o3/commit_impl.hh
+++ b/src/cpu/o3/commit_impl.hh
@@ -1,6 +1,6 @@
 /*
  * Copyright 2014 Google, Inc.
- * Copyright (c) 2010-2014, 2017 ARM Limited
+ * Copyright (c) 2010-2014, 2017, 2020 ARM Limited
  * All rights reserved
  *
  * The license below extends only to copyright in the software and shall
@@ -1260,6 +1260,7 @@
 tid, head_inst->seqNum);
 if (head_inst->traceData) {
 if (DTRACE(ExecFaulting)) {
+head_inst->traceData->setFaulting(true);
 head_inst->traceData->setFetchSeq(head_inst->seqNum);
 head_inst->traceData->setCPSeq(thread[tid]->numOp);
 head_inst->traceData->dump();
diff --git a/src/cpu/simple/atomic.cc b/src/cpu/simple/atomic.cc
index 4671402..c57fe14 100644
--- a/src/cpu/simple/atomic.cc
+++ b/src/cpu/simple/atomic.cc
@@ -1,6 +1,6 @@
 /*
  * Copyright 2014 Google, Inc.
- * Copyright (c) 2012-2013,2015,2017-2019 ARM Limited
+ * Copyright (c) 2012-2013,2015,2017-2020 ARM Limited
  * All rights reserved.
  *
  * The license below extends only to copyright in the software and shall
@@ -713,10 +713,8 @@
 if (fault == NoFault) {
 countInst();
 ppCommit->notify(std::make_pair(thread,  
curStaticInst));

-}
-else if (traceData && !DTRACE(ExecFaulting)) {
-delete traceData;
-traceData = NULL;
+} else if (traceData) {
+traceFault();
 }

 if (fault != NoFault &&
diff --git a/src/cpu/simple/base.cc b/src/cpu/simple/base.cc
index 8f23bab..d03ae86 100644
--- a/src/cpu/simple/base.cc
+++ b/src/cpu/simple/base.cc
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2010-2012, 2015, 2017, 2018 ARM Limited
+ * Copyright (c) 2010-2012, 2015, 2017, 2018, 2020 ARM Limited
  * Copyright (c) 2013 Advanced Micro Devices, Inc.
  * All rights reserved
  *
@@ -433,6 +433,17 @@
 }

 void
+BaseSimpleCPU::traceFault()
+{
+if (DTRACE(ExecFaulting)) {
+traceData->setFaulting(true);
+} else {
+delete traceData;
+traceData = NULL;
+}
+}
+
+void
 BaseSimpleCPU::checkForInterrupts()
 {
 SimpleExecContext_info = *threadInfo[curThread];
diff --git a/src/cpu/simple/base.hh b/src/cpu/simple/base.hh
index df17c26..a544211 100644
--- a/src/cpu/simple/base.hh
+++ b/src/cpu/simple/base.hh
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2011-2012,2015,2018 ARM Limited
+ * Copyright (c) 2011-2012,2015,2018,2020 ARM Limited
  * Copyright (c) 2013 Advanced Micro Devices, Inc.
  * All rights reserved
  *
@@ -120,6 +120,14 @@

 Status _status;

+/**
+ * Handler used when encountering a fault; its purpose is to
+ * tear down the InstRecord. If a fault is meant to be traced,
+ * the handler won't delete the record 

[gem5-dev] Re: [Suggestion] Replace gem5-users mailing-list with Discourse

2020-06-10 Thread Giacomo Travaglini via gem5-dev
I agree with Daniel and Ciro; it's difficult/annoying to navigate through old 
unanswered emails and I presume nobody does that at the moment.
Most of the time if your email doesn't get a quick response as soon as it gets 
posted, you can forget about getting some help as time passes; there is a short 
window and you really have to hope someone flagged your email or got some time 
to address your problem.

I wouldn't use JIRA to be honest for asking questions; that's beyond the scope 
of JIRA and it would be chaotic to mix Bug Reports, Improvement tasks with 
normal questions (like: I cannot build gem5 on my machine, or does anyone know 
how this works)

Giacomo


-Original Message-
From: Ciro Santilli via gem5-dev 
Sent: 10 June 2020 09:21
To: gem5 Developer List 
Cc: Ciro Santilli 
Subject: [gem5-dev] Re: [Suggestion] Replace gem5-users mailing-list with 
Discourse

I would just use JIRA. But after that, Discourse is the second best. And 
anything is better than a mailing list :-) 
From: Jason Lowe-Power via gem5-dev 
Sent: Tuesday, June 9, 2020 11:40 PM
To: gem5 Developer List 
Cc: gem5 users mailing list ; Jason Lowe-Power 

Subject: [gem5-dev] Re: [Suggestion] Replace gem5-users mailing-list with 
Discourse

+1 for Discourse :).

Just to give a bit more context: I'm also trying to find a good forum for 
community engagement during my online Learning gem5 class this summer. I would 
like to find a platform that could be used generally for my class this summer, 
future iterations of the class, and general gem5 questions, as I believe there 
will be significant overlap between these groups.

Other potential options that IMO have more cons than pros when compared to
Discourse:
- Slack/Teams/etc.
- gitter.im
- stackoverflow

That said, we're open to suggestions :). Our goal is to create the most 
welcoming and inclusive environment possible. We'll go where our users are!

Cheers,
Jason

On Tue, Jun 9, 2020 at 2:45 PM Bobby Bruce via gem5-dev 
wrote:

> Dear all,
>
> In an effort to better support the gem5 community, there has been a
> suggestion that we drop the gem5-users mailing list and replace it
> with Discourse, https://www.discourse.org/about, a web-based
> discussion platform. I'm writing this email to propose this to the
> community and ask for feedback on the matter.
>
> We have noticed that using mailing lists as our primary communication
> platform is problematic. Sending an email to a list can be daunting
> experience, requiring an etiquette many are not accustom to. I'm sure
> I'm not the only one who feels like they are unduly bothering a large
> number of people when posting to a list (like I'm doing right now :)
> ). This is, of course, an unfortunate hurdle for many to get over when
> they encounter problems using gem5, particularly those new to the
> project. I've come to believe mailing lists are simply not a very good
> technology for fostering community engagement and helping those who are 
> running into difficulties.
> Mailing lists are also difficult to search, and lack proper formatting
> mechanisms to neatly display attributes such as code and output logs.
>
> Looking around at alternative technologies available, Discourse
> appears to be a suitable replacement. For those unaware, Discourse is
> (essentially) a revamp of messaging forums. It is an increasingly
> popular platform for users and developers in open source projects to
> communicate with one another (see LLVM's discourse as an example:
> https://llvm.discourse.group ).
> All-in-all, I think it's a well-designed product and contains all the
> features we'd expect and need to get our work done. I can see no
> immediate downsides to using it, though feedback from the community on
> the matter would be greatly appreciated, particularly from those who
> have used Discourse before. Dissenting opinions on the whole idea of
> moving away from the gem5-user's mailing list are also welcome.
>
> So, let me know what you think! :)
>
> Please note, regardless as to any decision made, we will continue the
> use of the gem5-dev mailing list for technical discussions for the
> foreseeable future.
>
> 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
IMPORTANT NOTICE: The contents of this email and any 

[gem5-dev] Re: [Suggestion] Replace gem5-users mailing-list with Discourse

2020-06-10 Thread Ciro Santilli via gem5-dev
I would just use JIRA. But after that, Discourse is the second best. And 
anything is better than a mailing list :-)

From: Jason Lowe-Power via gem5-dev 
Sent: Tuesday, June 9, 2020 11:40 PM
To: gem5 Developer List 
Cc: gem5 users mailing list ; Jason Lowe-Power 

Subject: [gem5-dev] Re: [Suggestion] Replace gem5-users mailing-list with 
Discourse

+1 for Discourse :).

Just to give a bit more context: I'm also trying to find a good forum for
community engagement during my online Learning gem5 class this summer. I
would like to find a platform that could be used generally for my class
this summer, future iterations of the class, and general gem5 questions, as
I believe there will be significant overlap between these groups.

Other potential options that IMO have more cons than pros when compared to
Discourse:
- Slack/Teams/etc.
- gitter.im
- stackoverflow

That said, we're open to suggestions :). Our goal is to create the most
welcoming and inclusive environment possible. We'll go where our users are!

Cheers,
Jason

On Tue, Jun 9, 2020 at 2:45 PM Bobby Bruce via gem5-dev 
wrote:

> Dear all,
>
> In an effort to better support the gem5 community, there has been a
> suggestion that we drop the gem5-users mailing list and replace it with
> Discourse, https://www.discourse.org/about, a web-based discussion
> platform. I'm writing this email to propose this to the community and ask
> for feedback on the matter.
>
> We have noticed that using mailing lists as our primary communication
> platform is problematic. Sending an email to a list can be daunting
> experience, requiring an etiquette many are not accustom to. I'm sure I'm
> not the only one who feels like they are unduly bothering a large number of
> people when posting to a list (like I'm doing right now :) ). This is, of
> course, an unfortunate hurdle for many to get over when they encounter
> problems using gem5, particularly those new to the project. I've come to
> believe mailing lists are simply not a very good technology for fostering
> community engagement and helping those who are running into difficulties.
> Mailing lists are also difficult to search, and lack proper formatting
> mechanisms to neatly display attributes such as code and output logs.
>
> Looking around at alternative technologies available, Discourse appears to
> be a suitable replacement. For those unaware, Discourse is (essentially) a
> revamp of messaging forums. It is an increasingly popular platform for
> users and developers in open source projects to communicate with one
> another (see LLVM's discourse as an example: https://llvm.discourse.group
> ).
> All-in-all, I think it's a well-designed product and contains all the
> features we'd expect and need to get our work done. I can see no immediate
> downsides to using it, though feedback from the community on the matter
> would be greatly appreciated, particularly from those who have used
> Discourse before. Dissenting opinions on the whole idea of moving away from
> the gem5-user's mailing list are also welcome.
>
> So, let me know what you think! :)
>
> Please note, regardless as to any decision made, we will continue the use
> of the gem5-dev mailing list for technical discussions for the foreseeable
> future.
>
> 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] Re: [Suggestion] Replace gem5-users mailing-list with Discourse

2020-06-10 Thread Daniel Carvalho via gem5-dev
First of all, I don't know how Discourse works, but from what I saw on the 
online demo it looked like a forum. Therefore, our main use case would be as a 
place to ask/deposit questions.
I believe that having a mailing list pushing mails down our throats compels 
people to answer: "Oh, I know the answer for that one". I don't imagine people 
going out of their ways to go to a website/forum and search for questions they 
can answer. I have been actively checking StackOverflow's gem5 questions for 
the past year or so, and I can tell you there is close to null community 
engagement - it is basically Ciro - on the answering department.
That being said, the mailing list is indeed harder to work with, and 
StackOverflow is not a forum, so we could have a try at a forum-like approach 
and see how things go.

Regards,Daniel
   Em quarta-feira, 10 de junho de 2020 00:41:20 GMT+2, Jason Lowe-Power via 
gem5-dev  escreveu:  
 
 +1 for Discourse :).

Just to give a bit more context: I'm also trying to find a good forum for
community engagement during my online Learning gem5 class this summer. I
would like to find a platform that could be used generally for my class
this summer, future iterations of the class, and general gem5 questions, as
I believe there will be significant overlap between these groups.

Other potential options that IMO have more cons than pros when compared to
Discourse:
- Slack/Teams/etc.
- gitter.im
- stackoverflow

That said, we're open to suggestions :). Our goal is to create the most
welcoming and inclusive environment possible. We'll go where our users are!

Cheers,
Jason

On Tue, Jun 9, 2020 at 2:45 PM Bobby Bruce via gem5-dev 
wrote:

> Dear all,
>
> In an effort to better support the gem5 community, there has been a
> suggestion that we drop the gem5-users mailing list and replace it with
> Discourse, https://www.discourse.org/about, a web-based discussion
> platform. I'm writing this email to propose this to the community and ask
> for feedback on the matter.
>
> We have noticed that using mailing lists as our primary communication
> platform is problematic. Sending an email to a list can be daunting
> experience, requiring an etiquette many are not accustom to. I'm sure I'm
> not the only one who feels like they are unduly bothering a large number of
> people when posting to a list (like I'm doing right now :) ). This is, of
> course, an unfortunate hurdle for many to get over when they encounter
> problems using gem5, particularly those new to the project. I've come to
> believe mailing lists are simply not a very good technology for fostering
> community engagement and helping those who are running into difficulties.
> Mailing lists are also difficult to search, and lack proper formatting
> mechanisms to neatly display attributes such as code and output logs.
>
> Looking around at alternative technologies available, Discourse appears to
> be a suitable replacement. For those unaware, Discourse is (essentially) a
> revamp of messaging forums. It is an increasingly popular platform for
> users and developers in open source projects to communicate with one
> another (see LLVM's discourse as an example: https://llvm.discourse.group
> ).
> All-in-all, I think it's a well-designed product and contains all the
> features we'd expect and need to get our work done. I can see no immediate
> downsides to using it, though feedback from the community on the matter
> would be greatly appreciated, particularly from those who have used
> Discourse before. Dissenting opinions on the whole idea of moving away from
> the gem5-user's mailing list are also welcome.
>
> So, let me know what you think! :)
>
> Please note, regardless as to any decision made, we will continue the use
> of the gem5-dev mailing list for technical discussions for the foreseeable
> future.
>
> 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