[gem5-dev] Re: Build failed in Jenkins: Nightly #27

[Gabe Black via gem5-dev]

Sorry for the breakage, thanks for the fix!

Gabe

On Fri, Aug 7, 2020 at 8:03 AM Jason Lowe-Power via gem5-dev <
gem5-dev@gem5.org> wrote:

> Feel free to post a fix if you have one!
>
> Cheers,
> Jason
>
> On Fri, Aug 7, 2020 at 7:58 AM Poremba, Matthew 
> wrote:
>
>> [AMD Public Use]
>>
>>
>>
>> The line that has the error should be deleted to fix the MIPS build.  I
>> missed that in the review.  I can post a fix if you want but I thought I’d
>> give Gabe a chance to take a look.
>>
>>
>>
>>
>>
>> -Matt
>>
>>
>>
>> *From:* Jason Lowe-Power via gem5-dev 
>> *Sent:* Thursday, August 6, 2020 7:36 AM
>> *To:* gem5 Developer List ; Bobby Bruce <
>> bbr...@ucdavis.edu>
>> *Cc:* Jason Lowe-Power 
>> *Subject:* [gem5-dev] Re: Build failed in Jenkins: Nightly #27
>>
>>
>>
>> [CAUTION: External Email]
>>
>> Cool! The nightly builds are "working"! (At least in the sense that they
>> let us know when something failed :D)
>>
>>
>>
>> It looks like the change that caused this issue is
>> https://gem5-review.googlesource.com/c/public/gem5/+/29403
>> 
>> .
>>
>>
>>
>> @Bobby Bruce , it might be nice if this message
>> could give us links to the commits. If we can't get links to the gerrit
>> easily, at least links to gem5.googlesource.com
>> 
>> would be useful.
>>
>>
>>
>> Cheers,
>>
>> Jason
>>
>>
>>
>> On Thu, Aug 6, 2020 at 1:51 AM jenkins-no-reply--- via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>> See <
>> https://jenkins.gem5.org/job/Nightly/27/display/redirect?page=changes
>> 
>> >
>>
>> Changes:
>>
>> [gabeblack] scons: Remove the plumbing for running regression tests from
>> scons.
>>
>> [gabeblack] tests: Get rid of the tests/tests.py script.
>>
>> [gabeblack] tests: Get rid of the tests/testing python package.
>>
>> [gabeblack] tests: Get rid of the now unused diff-out script.
>>
>> [gabeblack] util: Delete the util/regress script.
>>
>> [Bobby R. Bruce] utils,tests: Enable passing of build args to
>> compiler-tests.sh
>>
>> [gabeblack] scons: Remove explicitly set defaults in calls to AddOption.
>>
>> [gabeblack] scons: Delete the now unused --update-ref option.
>>
>> [gabeblack] sim: Convert stat functions to use VPtr.
>>
>> [gabeblack] arch: Use VPtr for uname.
>>
>> [gabeblack] scons: Make src/systemc/tests/SConscript python 3 compatible.
>>
>> [gabeblack] scons,fastmodel: Limit how many instances of simgen can run
>> at once.
>>
>> [gabeblack] systemc: Filter a pydot warning message out when checking
>> test output.
>>
>> [gabeblack] systemc: Adjust some type names in a couple tests.
>>
>> [gabeblack] cpu: Remove the "profile" parameter and plumbing.
>>
>>
>> --
>> [...truncated 40.75 KB...]
>>  [VER TAGS]  -> MIPS/sim/tags.cc
>>  [ CXX] MIPS/sim/debug.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/MachineType.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Wakeup.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/Directory_Transitions.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/Directory_Wakeup.cc -> .o
>>  [LINK]  -> MIPS/cpu/simple/probes/lib.o.partial
>>  [ CXX] MIPS/mem/ruby/protocol/DMA_Controller.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/DMA_Transitions.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/DMA_Wakeup.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Controller.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Transitions.cc -> .o
>>  [ CXX] MIPS/mem/ruby/protocol/Directory_Controller.cc -> .o
>>  [ CXX] MIPS/sim/kernel_workload.cc -> .o
>>  [ CXX] MIPS/sim/stat_control.cc -> .o
>>  [ CXX] MIPS/sim/system.cc -> .o
>>  [ CXX] MIPS/sim/faults.cc -> .o
>>  [LINK]  -> MIPS/mem/ruby/protocol/lib.o.partial
>>  [ CXX] MIPS/sim/process.cc -> .o
>>  [ CXX] MIPS/sim/mem_state.cc -> .o
>>  [SO PARAM] BaseCPU -> MIPS/params/BaseCPU.hh
>>  [ CXX] MIPS/sim/pseudo_inst.cc -> .o
>>  [ CXX] MIPS/sim/syscall_emul.cc -> .o
>>  [ CXX] MIPS/sim/syscall_desc.cc -> .o
>>  [ CXX] MIPS/cpu/testers/directedtest/DirectedGenerator.cc -> .o
>>  [ CXX] 

[gem5-dev] Change in gem5/gem5[develop]: arch-mips: Remove old TypeBufferArg call

[Matthew Poremba (Gerrit) via gem5-dev]

Matthew Poremba has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/32414 )



Change subject: arch-mips: Remove old TypeBufferArg call
..

arch-mips: Remove old TypeBufferArg call

TypeBufferArg was replaced by VPtr so this call is no longer needed.
This fixes the MIPS build / nightly build.

Change-Id: I3880229fa0ad87fad1ca35c136e12efc6c36ceda
---
M src/arch/mips/linux/process.cc
1 file changed, 0 insertions(+), 1 deletion(-)



diff --git a/src/arch/mips/linux/process.cc b/src/arch/mips/linux/process.cc
index 8f1ec16..600d053 100644
--- a/src/arch/mips/linux/process.cc
+++ b/src/arch/mips/linux/process.cc
@@ -127,7 +127,6 @@
 // SSI_IEEE_FP_CONTROL
 ConstVPtr fpcr(bufPtr, tc);
 // I don't think this exactly matches the HW FPCR
-fpcr.copyIn(tc->getVirtProxy());
  
DPRINTFR(SyscallVerbose, "sys_setsysinfo(SSI_IEEE_FP_CONTROL): "

" setting FPCR to 0x%x\n", letoh(*fpcr));
 return 0;

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/32414
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: I3880229fa0ad87fad1ca35c136e12efc6c36ceda
Gerrit-Change-Number: 32414
Gerrit-PatchSet: 1
Gerrit-Owner: Matthew Poremba 
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] Re: Build failed in Jenkins: Nightly #27

[Jason Lowe-Power via gem5-dev]

Feel free to post a fix if you have one!

Cheers,
Jason

On Fri, Aug 7, 2020 at 7:58 AM Poremba, Matthew 
wrote:

> [AMD Public Use]
>
>
>
> The line that has the error should be deleted to fix the MIPS build.  I
> missed that in the review.  I can post a fix if you want but I thought I’d
> give Gabe a chance to take a look.
>
>
>
>
>
> -Matt
>
>
>
> *From:* Jason Lowe-Power via gem5-dev 
> *Sent:* Thursday, August 6, 2020 7:36 AM
> *To:* gem5 Developer List ; Bobby Bruce <
> bbr...@ucdavis.edu>
> *Cc:* Jason Lowe-Power 
> *Subject:* [gem5-dev] Re: Build failed in Jenkins: Nightly #27
>
>
>
> [CAUTION: External Email]
>
> Cool! The nightly builds are "working"! (At least in the sense that they
> let us know when something failed :D)
>
>
>
> It looks like the change that caused this issue is
> https://gem5-review.googlesource.com/c/public/gem5/+/29403
> 
> .
>
>
>
> @Bobby Bruce , it might be nice if this message could
> give us links to the commits. If we can't get links to the gerrit easily,
> at least links to gem5.googlesource.com
> 
> would be useful.
>
>
>
> Cheers,
>
> Jason
>
>
>
> On Thu, Aug 6, 2020 at 1:51 AM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
> See  
> >
>
> Changes:
>
> [gabeblack] scons: Remove the plumbing for running regression tests from
> scons.
>
> [gabeblack] tests: Get rid of the tests/tests.py script.
>
> [gabeblack] tests: Get rid of the tests/testing python package.
>
> [gabeblack] tests: Get rid of the now unused diff-out script.
>
> [gabeblack] util: Delete the util/regress script.
>
> [Bobby R. Bruce] utils,tests: Enable passing of build args to
> compiler-tests.sh
>
> [gabeblack] scons: Remove explicitly set defaults in calls to AddOption.
>
> [gabeblack] scons: Delete the now unused --update-ref option.
>
> [gabeblack] sim: Convert stat functions to use VPtr.
>
> [gabeblack] arch: Use VPtr for uname.
>
> [gabeblack] scons: Make src/systemc/tests/SConscript python 3 compatible.
>
> [gabeblack] scons,fastmodel: Limit how many instances of simgen can run at
> once.
>
> [gabeblack] systemc: Filter a pydot warning message out when checking test
> output.
>
> [gabeblack] systemc: Adjust some type names in a couple tests.
>
> [gabeblack] cpu: Remove the "profile" parameter and plumbing.
>
>
> --
> [...truncated 40.75 KB...]
>  [VER TAGS]  -> MIPS/sim/tags.cc
>  [ CXX] MIPS/sim/debug.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MachineType.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Wakeup.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Wakeup.cc -> .o
>  [LINK]  -> MIPS/cpu/simple/probes/lib.o.partial
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Controller.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Wakeup.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Controller.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Controller.cc -> .o
>  [ CXX] MIPS/sim/kernel_workload.cc -> .o
>  [ CXX] MIPS/sim/stat_control.cc -> .o
>  [ CXX] MIPS/sim/system.cc -> .o
>  [ CXX] MIPS/sim/faults.cc -> .o
>  [LINK]  -> MIPS/mem/ruby/protocol/lib.o.partial
>  [ CXX] MIPS/sim/process.cc -> .o
>  [ CXX] MIPS/sim/mem_state.cc -> .o
>  [SO PARAM] BaseCPU -> MIPS/params/BaseCPU.hh
>  [ CXX] MIPS/sim/pseudo_inst.cc -> .o
>  [ CXX] MIPS/sim/syscall_emul.cc -> .o
>  [ CXX] MIPS/sim/syscall_desc.cc -> .o
>  [ CXX] MIPS/cpu/testers/directedtest/DirectedGenerator.cc -> .o
>  [ CXX] MIPS/cpu/o3/probe/simple_trace.cc -> .o
>  [ CXX] MIPS/cpu/o3/probe/elastic_trace.cc -> .o
>  [ CXX] MIPS/cpu/testers/traffic_gen/base.cc -> .o
>  [LINK]  -> MIPS/sim/lib.o.partial
>  [ CXX] MIPS/cpu/testers/traffic_gen/base_gen.cc -> .o
>  [ CXX] 

[gem5-dev] Re: Build failed in Jenkins: Nightly #27

[Poremba, Matthew via gem5-dev]

[AMD Public Use]

The line that has the error should be deleted to fix the MIPS build.  I missed 
that in the review.  I can post a fix if you want but I thought I'd give Gabe a 
chance to take a look.


-Matt

From: Jason Lowe-Power via gem5-dev 
Sent: Thursday, August 6, 2020 7:36 AM
To: gem5 Developer List ; Bobby Bruce 
Cc: Jason Lowe-Power 
Subject: [gem5-dev] Re: Build failed in Jenkins: Nightly #27

[CAUTION: External Email]
Cool! The nightly builds are "working"! (At least in the sense that they let us 
know when something failed :D)

It looks like the change that caused this issue is 
https://gem5-review.googlesource.com/c/public/gem5/+/29403.

@Bobby Bruce, it might be nice if this message could 
give us links to the commits. If we can't get links to the gerrit easily, at 
least links to 
gem5.googlesource.com
 would be useful.

Cheers,
Jason

On Thu, Aug 6, 2020 at 1:51 AM jenkins-no-reply--- via gem5-dev 
mailto:gem5-dev@gem5.org>> wrote:
See 
>

Changes:

[gabeblack] scons: Remove the plumbing for running regression tests from scons.

[gabeblack] tests: Get rid of the tests/tests.py script.

[gabeblack] tests: Get rid of the tests/testing python package.

[gabeblack] tests: Get rid of the now unused diff-out script.

[gabeblack] util: Delete the util/regress script.

[Bobby R. Bruce] utils,tests: Enable passing of build args to compiler-tests.sh

[gabeblack] scons: Remove explicitly set defaults in calls to AddOption.

[gabeblack] scons: Delete the now unused --update-ref option.

[gabeblack] sim: Convert stat functions to use VPtr.

[gabeblack] arch: Use VPtr for uname.

[gabeblack] scons: Make src/systemc/tests/SConscript python 3 compatible.

[gabeblack] scons,fastmodel: Limit how many instances of simgen can run at once.

[gabeblack] systemc: Filter a pydot warning message out when checking test 
output.

[gabeblack] systemc: Adjust some type names in a couple tests.

[gabeblack] cpu: Remove the "profile" parameter and plumbing.


--
[...truncated 40.75 KB...]
 [VER TAGS]  -> MIPS/sim/tags.cc
 [ CXX] MIPS/sim/debug.cc -> .o
 [ CXX] MIPS/mem/ruby/protocol/MachineType.cc -> .o
 [ CXX] MIPS/mem/ruby/protocol/L1Cache_Wakeup.cc -> .o
 [ CXX] MIPS/mem/ruby/protocol/Directory_Transitions.cc -> .o
 [ CXX] MIPS/mem/ruby/protocol/Directory_Wakeup.cc -> .o
 [LINK]  -> MIPS/cpu/simple/probes/lib.o.partial
 [ CXX] MIPS/mem/ruby/protocol/DMA_Controller.cc -> .o
 [ CXX] MIPS/mem/ruby/protocol/DMA_Transitions.cc -> .o
 [ CXX] MIPS/mem/ruby/protocol/DMA_Wakeup.cc -> .o
 [ CXX] MIPS/mem/ruby/protocol/L1Cache_Controller.cc -> .o
 [ CXX] MIPS/mem/ruby/protocol/L1Cache_Transitions.cc -> .o
 [ CXX] MIPS/mem/ruby/protocol/Directory_Controller.cc -> .o
 [ CXX] MIPS/sim/kernel_workload.cc -> .o
 [ CXX] MIPS/sim/stat_control.cc -> .o
 [ CXX] MIPS/sim/system.cc -> .o
 [ CXX] MIPS/sim/faults.cc -> .o
 [LINK]  -> MIPS/mem/ruby/protocol/lib.o.partial
 [ CXX] MIPS/sim/process.cc -> .o
 [ CXX] MIPS/sim/mem_state.cc -> .o
 [SO PARAM] BaseCPU -> MIPS/params/BaseCPU.hh
 [ CXX] MIPS/sim/pseudo_inst.cc -> .o
 [ CXX] MIPS/sim/syscall_emul.cc -> .o
 [ CXX] MIPS/sim/syscall_desc.cc -> .o
 [ CXX] MIPS/cpu/testers/directedtest/DirectedGenerator.cc -> .o
 [ CXX] MIPS/cpu/o3/probe/simple_trace.cc -> .o
 [ CXX] MIPS/cpu/o3/probe/elastic_trace.cc -> .o
 [ CXX] MIPS/cpu/testers/traffic_gen/base.cc -> .o
 [LINK]  -> MIPS/sim/lib.o.partial
 [ CXX] MIPS/cpu/testers/traffic_gen/base_gen.cc -> .o
 [ CXX] MIPS/cpu/testers/traffic_gen/traffic_gen.cc -> .o
 [ CXX] MIPS/python/_m5/param_AtomicSimpleCPU.cc -> .o
 [SO PyBind] BaseCPU -> MIPS/python/_m5/param_BaseCPU.cc
 [ CXX] MIPS/python/_m5/param_BaseCPU.cc -> .o
 [LINK]  -> MIPS/cpu/o3/probe/lib.o.partial
 [ CXX] MIPS/python/_m5/param_BaseCache.cc -> .o
 [LINK]  -> MIPS/cpu/testers/traffic_gen/lib.o.partial
 [  

[gem5-dev] Re: Possible race condition (Remote GDB)

[Boris Shingarov via gem5-dev]

> I don't see any race condition here. If gem5 has been told to wait, it  
> waits. If gdb has connected to it and hasn't told it to keep running, it  
> blocks.

But it doesn't work.  Try the following experiment: in the gdb source introduce 
a time-delay somewhere after connecting to the TCP port but before sending the 
very first bytes; for example like this:

diff --git a/gdb/remote.c b/gdb/remote.c
index 59075cb09f..60a5e80481 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -4562,6 +4562,8 @@ remote_target::start_remote (int from_tty, int extended_p)
   struct packet_config *noack_config;
   char *wait_status = NULL;
 
+usleep(300);
+
   /* Signal other parts that we're going through the initial setup,
  and so things may not be stable yet.  E.g., we don't try to
  install tracepoints until we've relocated symbols.  Also, a
...

Without the usleep, gem5 blocks.  With the usleep, gem5 doesn't block.
Just for fun I tried with GNU gdbserver and with Xilinx XMD just now, and both 
block in both cases.


-"Gabe Black via gem5-dev"  wrote: -
To: "gem5 Developer List" 
From: "Gabe Black via gem5-dev" 
Date: 08/07/2020 04:34AM
Cc: "Boris Shingarov" , "Gabe Black" 

Subject: [gem5-dev] Re: Possible race condition (Remote GDB)

I think this code was originally written by Nate who is no longer with us. 
Looking at it, what I *think* it's doing starts in listen(). That sets up a 
poll queue event which listens for connection from gdb. When that gets 
triggered, that (slightly indirectly) calls connect which will check if 
somebody is already attached, and if not call the attach function. That will 
set up a poll queue event which waits for data to show up on the new 
connection. Once that happens, the incomingData method is called, and that sets 
up an event which will trigger at the next instruction boundary so that the 
remote GDB stub is operating synchronously with the rest of gem5 I think, and 
also so that it's not trying to look at state half way through an instruction. 
When that trap event fires, it calls the trap() method.

So at this point we know that there was a connect, we got sent data through it, 
and we're at an instruction boundary, if we're entering the debug loop because 
gdb connected to us.

If we're entering the gdb loop for some other reason (in the comment there it 
mentions the kernel's debug stub running in the guest triggering a breakpoint) 
then that's what I think that "if" is for. If we aren't active (because we 
didn't call attach() yet, ie no gdb has connected to us), then record that we 
are in fact active. If we were already active, ie gdb was already talking to 
us, tell it we got a trap and it can send us commands.

Regardless, then we try to read commands from gdb and execute them one by one. 
Getting commands is started by the recv(data) call in that function which 
eventually trickles down to a call to read() on the socket to retrieve a byte. 
If that blocks, then gdb hasn't told us what to do yet.

In the case where the CPU has been told to wait for GDB, gem5 just blocks after 
the GDB stub has been created until something connects to it.

I don't see any race condition here. If gem5 has been told to wait, it waits. 
If gdb has connected to it and hasn't told it to keep running, it blocks.

If, on the other hand, somebody throws a BadClient exception, for instance 
because the data from gdb is malformed, then gdb will be disconnected and the 
command loop will exit. This prevents a rogue connection or a misbehaving 
client from jamming up the gdb server and locking the simulation from 
progressing. The client can attempt to reattach to continue debugging which 
would act like a connection reboot, flushing away the broken connection and 
starting over. Also commands which return false tell the command loop to exit. 
This is how the continue command breaks out of the loop so the simulation can 
progress.

Gabe
On Thu, Aug 6, 2020 at 5:25 PM Boris Shingarov via gem5-dev  
wrote:
It gets worse: I am beginning to suspect that this race is what ultimately 
causes the "xml for the wrong xlen" mystery (if the timing is unlucky, the CSPR 
isn't set yet).
 
 -"Boris Shingarov via gem5-dev"  wrote: -
 To: gem5-dev@gem5.org
 From: "Boris Shingarov via gem5-dev" 
 Date: 08/06/2020 08:14PM
 Cc: "Boris Shingarov" 
 Subject: [gem5-dev] Possible race condition (Remote GDB)
 
 It looks to me that there is a race condition inherent in the design of 
DataEvent.
 The effect is that, even when CPU.wait_for_gdb attr is set and after the the 
RSP socket has connected, the relative timing of gdb's vs gem5's execution may 
or may not lead to gdb's presence being ignored.  It's like "hey gdb,I know you 
already connected, but if you aren't quick enough that the qSupported reaches 
the queue within N ms after connecting, I am going ahead without you; (and no I 
am not telling you what N is)".
 
 It looks like one fundamental issue here is the historical packet-oriented 

[gem5-dev] Change in gem5/gem5[develop]: mem-cache,python: Allow custom TLB and events in each prefetcher.

[Gerrit]

Isaac Sánchez Barrera has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/32394 )



Change subject: mem-cache,python: Allow custom TLB and events in each  
prefetcher.

..

mem-cache,python: Allow custom TLB and events in each prefetcher.

The `BasePrefetcher` python class had members `_events` and `_tlbs`
defined as lists, meaning that any call to `list.append` on them would
affect `_events` and `_tlbs` for all prefetchers, not just the calling
object.  This change redefines them as `None` by default and sets the
value to a per-object empty list before inserting the first element.

Change-Id: I68feb1d6d78e2fa5e8775afba8c81c6dd0de6c60
Signed-off by: Isaac Sánchez Barrera 
---
M src/mem/cache/prefetch/Prefetcher.py
1 file changed, 13 insertions(+), 6 deletions(-)



diff --git a/src/mem/cache/prefetch/Prefetcher.py  
b/src/mem/cache/prefetch/Prefetcher.py

index f131ccf..d6a01b9 100644
--- a/src/mem/cache/prefetch/Prefetcher.py
+++ b/src/mem/cache/prefetch/Prefetcher.py
@@ -80,17 +80,21 @@
 use_virtual_addresses = Param.Bool(False,
 "Use virtual addresses for prefetching")

-_events = []
+_events = None
 def addEvent(self, newObject):
+if not self._events:
+self._events = []
 self._events.append(newObject)

 # Override the normal SimObject::regProbeListeners method and
 # register deferred event handlers.
 def regProbeListeners(self):
-for tlb in self._tlbs:
-self.getCCObject().addTLB(tlb.getCCObject())
-for event in self._events:
-   event.register()
+if self._tlbs:
+for tlb in self._tlbs:
+self.getCCObject().addTLB(tlb.getCCObject())
+if self._events:
+for event in self._events:
+event.register()
 self.getCCObject().regProbeListeners()

 def listenFromProbe(self, simObj, *probeNames):
@@ -99,10 +103,13 @@
 if len(probeNames) <= 0:
 raise TypeError("probeNames must have at least one element")
 self.addEvent(HWPProbeEvent(self, simObj, *probeNames))
-_tlbs = []
+
+_tlbs = None
 def registerTLB(self, simObj):
 if not isinstance(simObj, SimObject):
 raise TypeError("argument must be a SimObject type")
+if not self._tlbs:
+self._tlbs = []
 self._tlbs.append(simObj)

 class MultiPrefetcher(BasePrefetcher):

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/32394
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: I68feb1d6d78e2fa5e8775afba8c81c6dd0de6c60
Gerrit-Change-Number: 32394
Gerrit-PatchSet: 1
Gerrit-Owner: Isaac Sánchez Barrera 
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] Re: Possible race condition (Remote GDB)

[Gabe Black via gem5-dev]

I think this code was originally written by Nate who is no longer with us.
Looking at it, what I *think* it's doing starts in listen(). That sets up a
poll queue event which listens for connection from gdb. When that gets
triggered, that (slightly indirectly) calls connect which will check if
somebody is already attached, and if not call the attach function. That
will set up a poll queue event which waits for data to show up on the new
connection. Once that happens, the incomingData method is called, and that
sets up an event which will trigger at the next instruction boundary so
that the remote GDB stub is operating synchronously with the rest of gem5 I
think, and also so that it's not trying to look at state half way through
an instruction. When that trap event fires, it calls the trap() method.

So at this point we know that there was a connect, we got sent data through
it, and we're at an instruction boundary, if we're entering the debug loop
because gdb connected to us.

If we're entering the gdb loop for some other reason (in the comment there
it mentions the kernel's debug stub running in the guest triggering a
breakpoint) then that's what I think that "if" is for. If we aren't active
(because we didn't call attach() yet, ie no gdb has connected to us), then
record that we are in fact active. If we were already active, ie gdb was
already talking to us, tell it we got a trap and it can send us commands.

Regardless, then we try to read commands from gdb and execute them one by
one. Getting commands is started by the recv(data) call in that function
which eventually trickles down to a call to read() on the socket to
retrieve a byte. If that blocks, then gdb hasn't told us what to do yet.

In the case where the CPU has been told to wait for GDB, gem5 just blocks
after the GDB stub has been created until something connects to it.

I don't see any race condition here. If gem5 has been told to wait, it
waits. If gdb has connected to it and hasn't told it to keep running, it
blocks.

If, on the other hand, somebody throws a BadClient exception, for instance
because the data from gdb is malformed, then gdb will be disconnected and
the command loop will exit. This prevents a rogue connection or a
misbehaving client from jamming up the gdb server and locking the
simulation from progressing. The client can attempt to reattach to continue
debugging which would act like a connection reboot, flushing away the
broken connection and starting over. Also commands which return false tell
the command loop to exit. This is how the continue command breaks out of
the loop so the simulation can progress.

Gabe

On Thu, Aug 6, 2020 at 5:25 PM Boris Shingarov via gem5-dev <
gem5-dev@gem5.org> wrote:

> It gets worse: I am beginning to suspect that this race is what ultimately
> causes the "xml for the wrong xlen" mystery (if the timing is unlucky, the
> CSPR isn't set yet).
>
> -"Boris Shingarov via gem5-dev"  wrote: -
> To: gem5-dev@gem5.org
> From: "Boris Shingarov via gem5-dev" 
> Date: 08/06/2020 08:14PM
> Cc: "Boris Shingarov" 
> Subject: [gem5-dev] Possible race condition (Remote GDB)
>
> It looks to me that there is a race condition inherent in the design of
> DataEvent.
> The effect is that, even when CPU.wait_for_gdb attr is set and after the
> the RSP socket has connected, the relative timing of gdb's vs gem5's
> execution may or may not lead to gdb's presence being ignored.  It's like
> "hey gdb,I know you already connected, but if you aren't quick enough that
> the qSupported reaches the queue within N ms after connecting, I am going
> ahead without you; (and no I am not telling you what N is)".
>
> It looks like one fundamental issue here is the historical packet-oriented
> nature of RSP.  But it also looks like remote_gdb.cc:434,
>
> if (!active) {
> active = true;
> } else {
> // Tell remote host that an exception has occurred.
> send(csprintf("S%02x", type).c_str());
> }
>
> plays a central role.
> Can someone comment on how this is intended to work?  I must admit the
> comment above that code doesn't make sense to me.
>
> ___
> 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] Build failed in Jenkins: Nightly #28

[jenkins-no-reply--- via gem5-dev]

See 

Changes:

[shingarov] arch-power: Implement GDB XML target description for PowerPC

[ianjiang.ict] sim: Add checkpoint parameters for VMA list


--
[...truncated 8.74 KB...]
 [ CXX] ARM/sim/pseudo_inst.cc -> .o
 [LINK]  -> ARM/sim/power/lib.o.partial
 [ CXX] ARM/sim/syscall_emul.cc -> .o
 [ CXX] ARM/sim/syscall_desc.cc -> .o
 [ CXX] ARM/cpu/o3/base_dyn_inst.cc -> .o
 [ CXX] ARM/cpu/o3/commit.cc -> .o
 [LINK]  -> ARM/sim/lib.o.partial
 [ CXX] ARM/cpu/o3/cpu.cc -> .o
 [ CXX] ARM/cpu/o3/deriv.cc -> .o
 [ CXX] ARM/cpu/o3/decode.cc -> .o
 [ CXX] ARM/cpu/o3/dyn_inst.cc -> .o
 [ CXX] ARM/cpu/o3/fetch.cc -> .o
 [ CXX] ARM/cpu/o3/iew.cc -> .o
 [ CXX] ARM/cpu/o3/inst_queue.cc -> .o
 [ CXX] ARM/cpu/o3/lsq.cc -> .o
 [ CXX] ARM/cpu/o3/lsq_unit.cc -> .o
 [ CXX] ARM/cpu/o3/mem_dep_unit.cc -> .o
 [ CXX] ARM/cpu/o3/rename.cc -> .o
 [ CXX] ARM/cpu/o3/rob.cc -> .o
 [ CXX] ARM/cpu/o3/thread_context.cc -> .o
 [ CXX] ARM/cpu/o3/checker.cc -> .o
 [ CXX] ARM/cpu/simple/atomic.cc -> .o
 [ CXX] ARM/cpu/simple/noncaching.cc -> .o
 [ CXX] ARM/cpu/simple/timing.cc -> .o
 [ CXX] ARM/cpu/simple/base.cc -> .o
 [LINK]  -> ARM/cpu/o3/lib.o.partial
 [ CXX] ARM/cpu/simple/probes/simpoint.cc -> .o
 [ CXX] ARM/cpu/o3/probe/simple_trace.cc -> .o
 [LINK]  -> ARM/cpu/simple/probes/lib.o.partial
 [ CXX] ARM/cpu/o3/probe/elastic_trace.cc -> .o
 [ CXX] ARM/kern/linux/linux.cc -> .o
 [LINK]  -> ARM/cpu/simple/lib.o.partial
 [ CXX] ARM/cpu/minor/cpu.cc -> .o
 [LINK]  -> ARM/kern/lib.o.partial
 [ CXX] ARM/cpu/minor/decode.cc -> .o
 [ CXX] ARM/cpu/minor/execute.cc -> .o
 [ CXX] ARM/cpu/minor/fetch1.cc -> .o
 [ CXX] ARM/cpu/minor/fetch2.cc -> .o
 [ CXX] ARM/cpu/minor/lsq.cc -> .o
 [ CXX] ARM/cpu/minor/pipeline.cc -> .o
 [ CXX] ARM/cpu/minor/scoreboard.cc -> .o
 [ CXX] ARM/mem/se_translating_port_proxy.cc -> .o
 [LINK]  -> ARM/cpu/minor/lib.o.partial
 [ CXX] ARM/base/date.cc -> .o
 [LINK]  -> ARM/gem5.opt
/usr/bin/ld: build/ARM/arch/arm/lib.o.partial: in function 
`ArmSemihosting::callTmpNam(ThreadContext*, unsigned long, unsigned long, 
unsigned long)':
:453:
 warning: the use of `tmpnam' is dangerous, better use `mkstemp'
scons: done building targets.
*** Summary of Warnings ***
Warning: Your compiler doesn't support incremental linking and lto at the same
 time, so lto is being disabled. To force lto on anyway, use the
 --force-lto option. That will disable partial linking.
Warning: Header file  not found.
 This host has no libpng library.
 Disabling support for PNG framebuffers.
[Nightly] $ /bin/sh -xe /tmp/jenkins4728433364804578645.sh
+ scons build/MIPS/gem5.opt -j4
scons: Reading SConscript files ...
Warning: Your compiler doesn't support incremental linking and lto at the same
 time, so lto is being disabled. To force lto on anyway, use the
 --force-lto option. That will disable partial linking.
Info: Using Python config: python2.7-config
Checking for C header file Python.h... (cached) yes
Checking for C library python2.7... (cached) yes
Checking for C library pthread... (cached) yes
Checking for C library dl... (cached) yes
Checking for C library util... (cached) yes
Checking for C library m... (cached) yes
Checking for accept(0,0,0) in C++ library None... (cached) yes
Checking for zlibVersion() in C++ library z... (cached) yes
Checking for GOOGLE_PROTOBUF_VERIFY_VERSION in C++ library protobuf... (cached) 
yes
Checking for C header file valgrind/valgrind.h... (cached) no
Checking for clock_nanosleep(0,0,NULL,NULL) in C library None... (cached) yes
Checking for timer_create(CLOCK_MONOTONIC, NULL, NULL) in C library None... 
(cached) no
Checking for timer_create(CLOCK_MONOTONIC, NULL, NULL) in C library rt... 
(cached) yes
Checking for C library tcmalloc... (cached) yes
Checking for char temp; backtrace_symbols_fd((void*), 0, 0) in C library 
None... (cached) yes
Checking for C header file fenv.h... (cached) yes
Checking for C header file png.h... (cached) no
Warning: Header file  not found.
 This host has no libpng library.
 Disabling support for PNG framebuffers.
Checking for C header file linux/kvm.h... (cached) yes
Checking for C header file linux/if_tun.h... (cached) yes
Checking size of struct kvm_xsave ... (cached) yes
Checking for member exclude_host in struct perf_event_attr...(cached) yes
Checking for hdf5-serial using pkg-config... pkg-config not found
Checking for hdf5 using pkg-config... pkg-config not found
Checking for H5Fcreate("", 0, 0, 0) in C library hdf5... (cached) no
Warning: Couldn't find any HDF5 C++ libraries. Disabling
 HDF5 support.
Checking whether __i386__ is declared... (cached) no