Re: [gem5-dev] change to review email settings
Sounds great to me! Cheers, Jason On Thu, Oct 10, 2019 at 5:41 PM Gabe Black wrote: > Hi gem5-dev members. To help control the volume of email that goes to this > list, we're considering changing the settings in gerrit so that this list > will be emailed when a new review is uploaded, when a review is submitted, > but *not* each time it's updated in the mean time. People involved in the > review (the author, reviewers, etc.) would still get update emails > directly. The hope is that these settings will strike a balance between > keeping people informed about what changes are being made to gem5 and > keeping the volume from being overwhelming. > > Gabe > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: tests: Added GTests for base/bitfield.hh
Hello Andreas Sandberg, Steve Reinhardt, Giacomo Travaglini, I'd like you to reexamine a change. Please visit https://gem5-review.googlesource.com/c/public/gem5/+/21700 to look at the new patch set (#2). Change subject: tests: Added GTests for base/bitfield.hh .. tests: Added GTests for base/bitfield.hh In addition to the tests, a more detailed explanation of how "insertBits(..)" functions has been included in its doxygen documentation. The previous explanation was ambigious and led to confusion. Change-Id: I2ae8608733ebaa8f8f726cbb3a2cd8639b69c6b7 --- M src/base/SConscript M src/base/bitfield.hh A src/base/bitfield.test.cc 3 files changed, 276 insertions(+), 1 deletion(-) -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/21700 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: I2ae8608733ebaa8f8f726cbb3a2cd8639b69c6b7 Gerrit-Change-Number: 21700 Gerrit-PatchSet: 2 Gerrit-Owner: Bobby R. Bruce Gerrit-Reviewer: Andreas Sandberg Gerrit-Reviewer: Giacomo Travaglini Gerrit-Reviewer: Steve Reinhardt Gerrit-CC: Gabe Black Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] change to review email settings
Is receiving e-mails like that a setup for maintainers only, or was I supposed to receive e-mails when any patch is sent too? Currently I only receive mails from the devs themselves (except Gabe, idk why), and when a patch is updated and I am a reviewer or in the CC. I have "Mail Delivery" Enabled and "Digest" off. In any case, I'd find it very annoying to receive an e-mail on every change of every patch, so it sounds like a good idea. Regards,Daniel Em sexta-feira, 11 de outubro de 2019 20:35:17 GMT+2, Jason Lowe-Power escreveu: Sounds great to me! Cheers, Jason On Thu, Oct 10, 2019 at 5:41 PM Gabe Black wrote: > Hi gem5-dev members. To help control the volume of email that goes to this > list, we're considering changing the settings in gerrit so that this list > will be emailed when a new review is uploaded, when a review is submitted, > but *not* each time it's updated in the mean time. People involved in the > review (the author, reviewers, etc.) would still get update emails > directly. The hope is that these settings will strike a balance between > keeping people informed about what changes are being made to gem5 and > keeping the volume from being overwhelming. > > Gabe > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] change to review email settings
Hi Daniel. Yes, this is supposed to be for everyone on gem5-dev. My guess is your spam filter is putting them somewhere without you realizing. Mine was doing that for a while, and now I go to my spam folder which is 95% gem5 review emails, smack the filter on the nose with a newspaper, and put them back where they actually go. I doesn't sound like anyone objects to the change in settings, so I'll probably go ahead and make this change in the near future. Gabe On Fri, Oct 11, 2019 at 11:49 AM Daniel Carvalho wrote: > Is receiving e-mails like that a setup for maintainers only, or was I > supposed to receive e-mails when any patch is sent too? Currently I only > receive mails from the devs themselves (except Gabe, idk why), and when a > patch is updated and I am a reviewer or in the CC. I have "Mail Delivery" > Enabled and "Digest" off. > In any case, I'd find it very annoying to receive an e-mail on every > change of every patch, so it sounds like a good idea. > > Regards,Daniel > Em sexta-feira, 11 de outubro de 2019 20:35:17 GMT+2, Jason Lowe-Power > escreveu: > > Sounds great to me! > > Cheers, > Jason > > On Thu, Oct 10, 2019 at 5:41 PM Gabe Black wrote: > > > Hi gem5-dev members. To help control the volume of email that goes to > this > > list, we're considering changing the settings in gerrit so that this list > > will be emailed when a new review is uploaded, when a review is > submitted, > > but *not* each time it's updated in the mean time. People involved in the > > review (the author, reviewers, etc.) would still get update emails > > directly. The hope is that these settings will strike a balance between > > keeping people informed about what changes are being made to gem5 and > > keeping the volume from being overwhelming. > > > > Gabe > > ___ > > gem5-dev mailing list > > gem5-dev@gem5.org > > http://m5sim.org/mailman/listinfo/gem5-dev > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: arch, base: Separate the idea of a memory image and object file.
Gabe Black has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/21466 )
Change subject: arch,base: Separate the idea of a memory image and object
file.
..
arch,base: Separate the idea of a memory image and object file.
A memory image can be described by an object file, but an object file
is more than a memory image. Also, it makes sense to manipulate a
memory image to, for instance, change how it's loaded into memory. That
takes on larger implications (relocations, the entry point, symbols,
etc.) when talking about the whole object file, and also modifies
aspects which may not need to change. For instance if an image needs
to be loaded into memory at addresses different from what's in the
object file, but other things like symbols need to stay unmodified.
Change-Id: Ia360405ffb2c1c48e0cc201ac0a0764357996a54
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21466
Tested-by: kokoro
Reviewed-by: Brandon Potter
Maintainer: Gabe Black
---
M src/arch/alpha/process.cc
M src/arch/alpha/system.cc
M src/arch/arm/freebsd/system.cc
M src/arch/arm/linux/system.cc
M src/arch/arm/process.cc
M src/arch/arm/system.cc
M src/arch/mips/process.cc
M src/arch/power/process.cc
M src/arch/riscv/bare_metal/system.cc
M src/arch/riscv/process.cc
M src/arch/sparc/process.cc
M src/arch/sparc/process.hh
M src/arch/sparc/system.cc
M src/arch/x86/process.cc
M src/base/SConscript
M src/base/loader/aout_object.cc
M src/base/loader/aout_object.hh
M src/base/loader/dtb_object.cc
M src/base/loader/dtb_object.hh
M src/base/loader/ecoff_object.cc
M src/base/loader/ecoff_object.hh
M src/base/loader/elf_object.cc
M src/base/loader/elf_object.hh
A src/base/loader/memory_image.cc
A src/base/loader/memory_image.hh
M src/base/loader/object_file.cc
M src/base/loader/object_file.hh
M src/base/loader/raw_object.cc
M src/base/loader/raw_object.hh
M src/sim/process.cc
M src/sim/process.hh
M src/sim/syscall_emul.hh
M src/sim/system.cc
M src/sim/system.hh
34 files changed, 424 insertions(+), 338 deletions(-)
Approvals:
Brandon Potter: Looks good to me, approved
Gabe Black: Looks good to me, approved
kokoro: Regressions pass
diff --git a/src/arch/alpha/process.cc b/src/arch/alpha/process.cc
index e266b92..9311a64 100644
--- a/src/arch/alpha/process.cc
+++ b/src/arch/alpha/process.cc
@@ -54,10 +54,10 @@
objFile)
{
fatal_if(params->useArchPT, "Arch page tables not implemented.");
-Addr brk_point = roundUp(objFile->maxSegmentAddr(), PageBytes);
+Addr brk_point = roundUp(image.maxAddr(), PageBytes);
// Set up stack. On Alpha, stack goes below the image.
-Addr stack_base = objFile->minSegmentAddr() - (409600 + 4096);
+Addr stack_base = image.minAddr() - (409600 + 4096);
// Set up region for mmaps.
Addr mmap_end = 0x1;
@@ -74,13 +74,6 @@
void
AlphaProcess::argsInit(int intSize, int pageSize)
{
-// Patch the ld_bias for dynamic executables.
-updateBias();
-
-objFile->loadSegments(initVirtMem);
-if (objFile->getInterpreter())
-objFile->getInterpreter()->loadSegments(initVirtMem);
-
std::vector> auxv;
ElfObject * elfObject = dynamic_cast(objFile);
diff --git a/src/arch/alpha/system.cc b/src/arch/alpha/system.cc
index 31e7aa0..a7a4703 100644
--- a/src/arch/alpha/system.cc
+++ b/src/arch/alpha/system.cc
@@ -57,13 +57,11 @@
*/
// Load Console Code
console = createObjectFile(params()->console);
-console->setLoadMask(loadAddrMask);
if (console == NULL)
fatal("Could not load console file %s", params()->console);
// Load pal file
pal = createObjectFile(params()->pal);
-pal->setLoadMask(loadAddrMask);
if (pal == NULL)
fatal("Could not load PALcode file %s", params()->pal);
@@ -111,8 +109,8 @@
System::initState();
// Load program sections into memory
-pal->loadSegments(physProxy);
-console->loadSegments(physProxy);
+pal->buildImage().mask(loadAddrMask).write(physProxy);
+console->buildImage().mask(loadAddrMask).write(physProxy);
/**
* Copy the osflags (kernel arguments) into the consoles
diff --git a/src/arch/arm/freebsd/system.cc b/src/arch/arm/freebsd/system.cc
index 764f036..106c8e4 100644
--- a/src/arch/arm/freebsd/system.cc
+++ b/src/arch/arm/freebsd/system.cc
@@ -132,8 +132,8 @@
if (ra)
bootReleaseAddr = ra & ~ULL(0x7F);
-dtb_file->setLoadOffset(params()->atags_addr + loadAddrOffset);
-dtb_file->loadSegments(physProxy);
+dtb_file->buildImage().
+offset(params()->atags_addr + loadAddrOffset).write(physProxy);
delete dtb_file;
// Kernel boot requirements to set up r0, r1 and r2 in ARMv7
diff --git a/src/arch/arm/linux/system.cc b/src/arch/arm/linux/system.cc
index a0869b4..740d2e0 100644
--- a/src/arch/arm/linux/system.cc
+++ b/src/arch/arm/linux/system.cc
@@ -151,8 +151,8 @@
"to DTB
[gem5-dev] Change in gem5/gem5[master]: x86: Stop using and delete the x86 IntDevice class.
Gabe Black has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/20825 )
Change subject: x86: Stop using and delete the x86 IntDevice class.
..
x86: Stop using and delete the x86 IntDevice class.
Most of its functionality has been exported already. This change makes
the two classes which were inheriting IntDevice create an IntMasterPort
themselves.
Change-Id: I73d17cd79cf8252b0e26dd2576f552bf9054adf4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20825
Reviewed-by: Gabe Black
Maintainer: Gabe Black
Tested-by: kokoro
---
M src/arch/x86/interrupts.cc
M src/arch/x86/interrupts.hh
M src/dev/x86/SConscript
M src/dev/x86/i82094aa.cc
M src/dev/x86/i82094aa.hh
D src/dev/x86/intdev.cc
M src/dev/x86/intdev.hh
7 files changed, 25 insertions(+), 99 deletions(-)
Approvals:
Gabe Black: Looks good to me, approved; Looks good to me, approved
kokoro: Regressions pass
diff --git a/src/arch/x86/interrupts.cc b/src/arch/x86/interrupts.cc
index 392135d..d4ee9f6 100644
--- a/src/arch/x86/interrupts.cc
+++ b/src/arch/x86/interrupts.cc
@@ -290,16 +290,15 @@
X86ISA::Interrupts::init()
{
//
-// The local apic must register its address ranges on both its pio
-// port via the basicpiodevice(piodevice) init() function and its
-// int port that it inherited from IntDevice. Note IntDevice is
-// not a SimObject itself.
-//
+// The local apic must register its address ranges on its pio
+// port via the basicpiodevice(piodevice) init() function.
PioDevice::init();
-IntDevice::init();
-// the slave port has a range so inform the connected master
+// The slave port has a range, so inform the connected master.
intSlavePort.sendRangeChange();
+// If the master port isn't connected, we can't send interrupts
anywhere.
+panic_if(!intMasterPort.isConnected(),
+"Int port not connected to anything!");
}
@@ -597,7 +596,7 @@
X86ISA::Interrupts::Interrupts(Params * p)
-: PioDevice(p), IntDevice(this, p->int_latency),
+: PioDevice(p),
apicTimerEvent([this]{ processApicTimerEvent(); }, name()),
pendingSmi(false), smiVector(0),
pendingNmi(false), nmiVector(0),
@@ -607,6 +606,7 @@
startedUp(false), pendingUnmaskableInt(false),
pendingIPIs(0), cpu(NULL),
intSlavePort(name() + ".int_slave", this, this),
+ intMasterPort(name() + ".int_master", this, this, p->int_latency),
pioDelay(p->pio_latency)
{
memset(regs, 0, sizeof(regs));
diff --git a/src/arch/x86/interrupts.hh b/src/arch/x86/interrupts.hh
index e48fd4b..a6364c8 100644
--- a/src/arch/x86/interrupts.hh
+++ b/src/arch/x86/interrupts.hh
@@ -72,7 +72,7 @@
ApicRegIndex decodeAddr(Addr paddr);
-class Interrupts : public PioDevice, IntDevice
+class Interrupts : public PioDevice
{
protected:
// Storage for the APIC registers
@@ -171,8 +171,9 @@
int initialApicId;
-// Port for receiving interrupts
+// Ports for interrupts.
IntSlavePort intSlavePort;
+IntMasterPort intMasterPort;
Tick pioDelay;
Addr pioAddr = MaxAddr;
@@ -205,7 +206,7 @@
Tick read(PacketPtr pkt) override;
Tick write(PacketPtr pkt) override;
Tick recvMessage(PacketPtr pkt);
-bool recvResponse(PacketPtr pkt) override;
+bool recvResponse(PacketPtr pkt);
bool
triggerTimerInterrupt()
diff --git a/src/dev/x86/SConscript b/src/dev/x86/SConscript
index 4071cc8..81a9441 100644
--- a/src/dev/x86/SConscript
+++ b/src/dev/x86/SConscript
@@ -64,6 +64,3 @@
SimObject('I82094AA.py')
Source('i82094aa.cc')
DebugFlag('I82094AA')
-
-Source('intdev.cc')
-DebugFlag('IntDevice')
diff --git a/src/dev/x86/i82094aa.cc b/src/dev/x86/i82094aa.cc
index dfadbd9..5daebe7 100644
--- a/src/dev/x86/i82094aa.cc
+++ b/src/dev/x86/i82094aa.cc
@@ -40,8 +40,9 @@
#include "sim/system.hh"
X86ISA::I82094AA::I82094AA(Params *p)
-: BasicPioDevice(p, 20), IntDevice(this, p->int_latency),
- extIntPic(p->external_int_pic), lowestPriorityOffset(0)
+: BasicPioDevice(p, 20), extIntPic(p->external_int_pic),
+ lowestPriorityOffset(0),
+ intMasterPort(name() + ".int_master", this, this, p->int_latency)
{
// This assumes there's only one I/O APIC in the system and since the
apic
// id is stored in a 8-bit field with 0xff meaning broadcast, the id
must
@@ -66,12 +67,13 @@
void
X86ISA::I82094AA::init()
{
-// The io apic must register its address ranges on both its pio port
-// via the piodevice init() function and its int port that it inherited
-// from IntDevice. Note IntDevice is not a SimObject itself.
-
+// The io apic must register its address range with its pio port via
+// the piodevice init() function.
BasicPioDevice::init();
-IntDevice::init();
+
+// If the master port isn't connected, we can't send interrupts
anywhere.
+
[gem5-dev] Change in gem5/gem5[master]: arch, base, sim: Move Process loader hooks into the Process class.
Hello Andreas Sandberg, Brandon Potter, Jason Lowe-Power, I'd like you to reexamine a change. Please visit https://gem5-review.googlesource.com/c/public/gem5/+/21468 to look at the new patch set (#4). Change subject: arch,base,sim: Move Process loader hooks into the Process class. .. arch,base,sim: Move Process loader hooks into the Process class. This code was originally in the ObjectFile class, but not all object files will become Processes. All Processes will ultimately come from ObjectFiles though, so it makes more sense to put that class there. Change-Id: Ie73e4cdecbb51ce53d24cf68911a6cfc0685d771 --- M src/arch/alpha/linux/process.cc M src/arch/arm/freebsd/process.cc M src/arch/arm/linux/process.cc M src/arch/mips/linux/process.cc M src/arch/power/linux/process.cc M src/arch/riscv/linux/process.cc M src/arch/sparc/linux/process.cc M src/arch/sparc/solaris/process.cc M src/arch/x86/linux/process.cc M src/base/loader/object_file.cc M src/base/loader/object_file.hh M src/sim/process.cc M src/sim/process.hh 13 files changed, 73 insertions(+), 75 deletions(-) -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/21468 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: Ie73e4cdecbb51ce53d24cf68911a6cfc0685d771 Gerrit-Change-Number: 21468 Gerrit-PatchSet: 4 Gerrit-Owner: Gabe Black Gerrit-Reviewer: Andreas Sandberg Gerrit-Reviewer: Brandon Potter Gerrit-Reviewer: Jason Lowe-Power Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: arch, base: Restructure the object file loaders.
Hello Andreas Sandberg, Brandon Potter, Jason Lowe-Power, I'd like you to reexamine a change. Please visit https://gem5-review.googlesource.com/c/public/gem5/+/21467 to look at the new patch set (#4). Change subject: arch,base: Restructure the object file loaders. .. arch,base: Restructure the object file loaders. This change creates a distinction between object files which hold executable code, and flat files which don't. The first type of files have entry points, symbols, etc., while the others are just blobs which can be shoved into memory. Rather than have those aspects but stub them out, this change creates a new base class which simply doesn't have them. This change also restructures the ELF loader since it's main function was quite long and doing multiple jobs. It stops passing the architecture and operating system to the ObjectFile constructor, since those might not be known at the very top of the constructor. Instead, those default to Uknown*, and then are filled in in the constructor body if appropriate. This removes a lot of plumbing that was hard to actually use in practice. It also introduces a mechanism to collect generic object file formats so that they can be tried one by one by the general createObjectFile function, rather than listing them all there one by one. It's unlikely that new types of object files will need to be added in a modular way without being able to modify the core loader code, but it's cleaner to have that abstraction and modularization like is already there for process loaders. Finally, to make it possible to share the code which handles zipped files for both true object files and also files which will be loaded into memory but are just blobs, that mechanism is pulled out into a new class called ImageFileData. It holds a collection of segments which are set up by the object file and may refer to regions of the original file, buffers maintained elsewhere, or even nothing to support bss-es. shared_ptr is used to make it easier to keep track of that information without having to do so explicitly or worry about deleting a buffer before everyone was done using it. Change-Id: I92890266f2ba0a703803cccad675a3ab41f2c4af --- M src/arch/arm/freebsd/system.cc M src/arch/arm/linux/system.cc M src/base/SConscript M src/base/loader/aout_object.cc M src/base/loader/aout_object.hh R src/base/loader/dtb_file.cc R src/base/loader/dtb_file.hh M src/base/loader/ecoff_object.cc M src/base/loader/ecoff_object.hh M src/base/loader/elf_object.cc M src/base/loader/elf_object.hh C src/base/loader/image_file.hh A src/base/loader/image_file_data.cc C src/base/loader/image_file_data.hh M src/base/loader/memory_image.hh M src/base/loader/object_file.cc M src/base/loader/object_file.hh R src/base/loader/raw_image.hh D src/base/loader/raw_object.cc 19 files changed, 676 insertions(+), 831 deletions(-) -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/21467 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: I92890266f2ba0a703803cccad675a3ab41f2c4af Gerrit-Change-Number: 21467 Gerrit-PatchSet: 4 Gerrit-Owner: Gabe Black Gerrit-Reviewer: Andreas Sandberg Gerrit-Reviewer: Brandon Potter Gerrit-Reviewer: Jason Lowe-Power Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: fastmodel: Add string constructors which delegate to const char * ones.
Hello Andreas Sandberg, Giacomo Travaglini, Jason Lowe-Power, Chun-Chen TK Hsu, I'd like you to reexamine a change. Please visit https://gem5-review.googlesource.com/c/public/gem5/+/21502 to look at the new patch set (#3). Change subject: fastmodel: Add string constructors which delegate to const char * ones. .. fastmodel: Add string constructors which delegate to const char * ones. Change-Id: I22d88111409fc477c135b15c8f898adad4f6d4ab --- M src/arch/arm/fastmodel/common/signal_receiver.hh 1 file changed, 4 insertions(+), 2 deletions(-) -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/21502 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: I22d88111409fc477c135b15c8f898adad4f6d4ab Gerrit-Change-Number: 21502 Gerrit-PatchSet: 3 Gerrit-Owner: Gabe Black Gerrit-Reviewer: Andreas Sandberg Gerrit-Reviewer: Chun-Chen TK Hsu Gerrit-Reviewer: Giacomo Travaglini Gerrit-Reviewer: Jason Lowe-Power Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: fastmodel: Expose all CPU communication ports from the GIC.
Hello Andreas Sandberg, Giacomo Travaglini, Jason Lowe-Power, Chun-Chen TK Hsu, I'd like you to reexamine a change. Please visit https://gem5-review.googlesource.com/c/public/gem5/+/21500 to look at the new patch set (#3). Change subject: fastmodel: Expose all CPU communication ports from the GIC. .. fastmodel: Expose all CPU communication ports from the GIC. The unconnected CPU ports/sockets still need to be connected for TLM to be happy, so this change also adds a terminator module which finds all unbound sockets, creates pair sockets for them to connect to, binds everything together, and implements the target interface with a dummy stub that will complain and crash gem5 if it ever gets called. This will allow us to use the same GIC model to connect an arbitrary number of cores, up to the architected limit of 256. Change-Id: Iaa83fe4f023217dc91a3734b31f764fc4176130e --- M src/arch/arm/fastmodel/GIC/FastModelGIC.py M src/arch/arm/fastmodel/GIC/GIC.lisa M src/arch/arm/fastmodel/GIC/gic.cc M src/arch/arm/fastmodel/GIC/gic.hh M src/arch/arm/fastmodel/common/signal_receiver.hh 5 files changed, 96 insertions(+), 12 deletions(-) -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/21500 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: Iaa83fe4f023217dc91a3734b31f764fc4176130e Gerrit-Change-Number: 21500 Gerrit-PatchSet: 3 Gerrit-Owner: Gabe Black Gerrit-Reviewer: Andreas Sandberg Gerrit-Reviewer: Chun-Chen TK Hsu Gerrit-Reviewer: Giacomo Travaglini Gerrit-Reviewer: Jason Lowe-Power Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Cron /z/m5/regression/do-regression quick
scons: *** [build/HSAIL_X86/arch/hsail/gpu_decoder.do] Error 1 scons: *** [build/ALPHA/base/loader/hex_file.fo] Error 4 scons: *** [build/MIPS/base/loader/hex_file.fo] Error 4 scons: *** [build/NULL/base/loader/hex_file.fo] Error 4 scons: *** [build/NULL_MOESI_hammer/base/loader/hex_file.fo] Error 4 scons: *** [build/NULL_MESI_Two_Level/base/loader/hex_file.fo] Error 4 scons: *** [build/NULL_MOESI_CMP_directory/base/loader/hex_file.fo] Error 4 scons: *** [build/NULL_MOESI_CMP_token/base/loader/hex_file.fo] Error 4 scons: *** [build/POWER/base/loader/hex_file.fo] Error 4 scons: *** [build/SPARC/base/loader/hex_file.fo] Error 4 scons: *** [build/X86/base/loader/hex_file.fo] Error 4 scons: *** [build/X86_MESI_Two_Level/base/loader/hex_file.fo] Error 4 scons: *** [build/ARM/base/loader/hex_file.fo] Error 4 scons: *** [build/RISCV/base/loader/aout_object.fo] Error 1 scons: *** [build/RISCV/base/loader/hex_file.fo] Error 4 scons: *** [build/RISCV/base/loader/ecoff_object.fo] Error 1 scons: *** [build/RISCV/base/loader/elf_object.fo] Error 1 scons: *** [build/HSAIL_X86/base/loader/aout_object.fo] Error 1 scons: *** [build/HSAIL_X86/base/loader/hex_file.fo] Error 4 scons: *** [build/HSAIL_X86/base/loader/ecoff_object.fo] Error 1 scons: *** [build/HSAIL_X86/base/loader/elf_object.fo] Error 1 scons: *** [build/HSAIL_X86/arch/hsail/gpu_decoder.fo] Error 1 scons: *** [build/ALPHA/base/loader/hex_file.o] Error 4 scons: *** [build/MIPS/base/loader/hex_file.o] Error 4 scons: `build/MIPS/tests/opt/quick/fs' is up to date. scons: *** [build/NULL/base/loader/hex_file.o] Error 4 scons: `build/NULL/tests/opt/quick/fs' is up to date. scons: *** [build/NULL_MOESI_hammer/base/loader/hex_file.o] Error 4 scons: `build/NULL_MOESI_hammer/tests/opt/quick/fs' is up to date. scons: *** [build/NULL_MESI_Two_Level/base/loader/hex_file.o] Error 4 scons: `build/NULL_MESI_Two_Level/tests/opt/quick/fs' is up to date. scons: *** [build/NULL_MOESI_CMP_directory/base/loader/hex_file.o] Error 4 scons: `build/NULL_MOESI_CMP_directory/tests/opt/quick/fs' is up to date. scons: *** [build/NULL_MOESI_CMP_token/base/loader/hex_file.o] Error 4 scons: `build/NULL_MOESI_CMP_token/tests/opt/quick/fs' is up to date. scons: *** [build/POWER/python/_m5/param_LRUReplacementPolicy.o] Error 1 scons: *** [build/POWER/python/_m5/param_PseudoLRUReplacementPolicy.o] Error 1 scons: *** [build/POWER/python/_m5/param_ReplacementPolicy.o] Error 1 scons: *** [build/POWER/python/_m5/param_RubyCache.o] Error 1 scons: *** [build/POWER/python/_m5/param_WeightedLRUReplacementPolicy.o] Error 1 scons: *** [build/POWER/base/loader/hex_file.o] Error 4 scons: `build/POWER/tests/opt/quick/fs' is up to date. scons: *** [build/SPARC/mem/ruby/structures/AbstractReplacementPolicy.o] Error 4 scons: *** [build/SPARC/mem/ruby/structures/LRUPolicy.o] Error 4 scons: *** [build/SPARC/mem/ruby/structures/PseudoLRUPolicy.o] Error 4 scons: *** [build/SPARC/mem/ruby/structures/CacheMemory.o] Error 1 scons: *** [build/SPARC/mem/ruby/system/WeightedLRUPolicy.o] Error 1 scons: *** [build/SPARC/mem/ruby/slicc_interface/AbstractEntry.o] Error 4 scons: *** [build/SPARC/python/_m5/param_LRUReplacementPolicy.o] Error 1 scons: *** [build/SPARC/python/_m5/param_PseudoLRUReplacementPolicy.o] Error 1 scons: *** [build/SPARC/python/_m5/param_ReplacementPolicy.o] Error 1 scons: *** [build/SPARC/python/_m5/param_RubyCache.o] Error 1 scons: *** [build/SPARC/python/_m5/param_WeightedLRUReplacementPolicy.o] Error 1 scons: *** [build/SPARC/base/loader/hex_file.o] Error 4 scons: *** [build/X86/mem/ruby/slicc_interface/AbstractEntry.o] Error 4 scons: *** [build/X86/mem/ruby/structures/AbstractReplacementPolicy.o] Error 4 scons: *** [build/X86/mem/ruby/structures/LRUPolicy.o] Error 4 scons: *** [build/X86/mem/ruby/structures/PseudoLRUPolicy.o] Error 4 scons: *** [build/X86/mem/ruby/structures/CacheMemory.o] Error 1 scons: *** [build/X86/python/_m5/param_LRUReplacementPolicy.o] Error 1 scons: *** [build/X86/python/_m5/param_PseudoLRUReplacementPolicy.o] Error 1 scons: *** [build/X86/python/_m5/param_ReplacementPolicy.o] Error 1 scons: *** [build/X86/python/_m5/param_RubyCache.o] Error 1 scons: *** [build/X86/python/_m5/param_WeightedLRUReplacementPolicy.o] Error 1 scons: *** [build/X86/mem/ruby/system/WeightedLRUPolicy.o] Error 1 scons: *** [build/X86/base/loader/hex_file.o] Error 4 scons: `build/X86_MESI_Two_Level/tests/opt/quick/se' is up to date. scons: `build/X86_MESI_Two_Level/tests/opt/quick/fs' is up to date. scons: *** [build/ARM/mem/ruby/system/WeightedLRUPolicy.o] Error 1 scons: *** [build/ARM/base/loader/hex_file.o] Error 4 scons: *** [build/ARM/python/_m5/param_LRUReplacementPolicy.o] Error 1 scons: *** [build/ARM/python/_m5/param_PseudoLRUReplacementPolicy.o] Error 1 scons: *** [build/ARM/python/_m5/param_ReplacementPolicy.o] Error 1 scons: *** [build/ARM/python/_m5/param_RubyCache.o] Error 1 scons: *** [build/ARM/python/_m5/param_WeightedLRUReplacementPolicy.o] Error 1 scons: ***
Re: [gem5-dev] remote GDB broken on ARM
Hi Gabe, GDB was broken, then I fixed, then it broke, then I fixed it again at: 36a575071cd460255ca67ec5bdd6862d9c164919 arch-arm: fix GDB stub after SVE, do you have that commit? I've just tested on master and it worked on my simple test. From: gem5-dev on behalf of Gabe Black Sent: Friday, October 11, 2019 1:09 AM To: gem5 Developer List Subject: [gem5-dev] remote GDB broken on ARM Hi ARM folks. I'm trying to work on remote GDB support, and the default version of it seems to be broken. When trying to connect locally, I get this error: Remote 'g' packet reply is too long (expected 788 bytes, got 8468 bytes) I remember seeing some things go by talking about a gdb remote protocol mechanism where you could pass around XML files to tell GDB about new registers, and apparently this is either not working or not complete. Can someone confirm, and/or fix this? I'm working with a slightly older version of gem5 for this, but it's not that old (a few months). Gabe ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] remote GDB broken on ARM
Great, that seems to fix it for me. Thanks! Gabe On Fri, Oct 11, 2019 at 3:00 AM Ciro Santilli wrote: > Hi Gabe, > > GDB was broken, then I fixed, then it broke, then I fixed it again > at: 36a575071cd460255ca67ec5bdd6862d9c164919 arch-arm: fix GDB stub after > SVE, do you have that commit? > > I've just tested on master and it worked on my simple test. > -- > *From:* gem5-dev on behalf of Gabe Black < > gabebl...@google.com> > *Sent:* Friday, October 11, 2019 1:09 AM > *To:* gem5 Developer List > *Subject:* [gem5-dev] remote GDB broken on ARM > > Hi ARM folks. I'm trying to work on remote GDB support, and the default > version of it seems to be broken. When trying to connect locally, I get > this error: > > Remote 'g' packet reply is too long (expected 788 bytes, got 8468 bytes) > > I remember seeing some things go by talking about a gdb remote protocol > mechanism where you could pass around XML files to tell GDB about new > registers, and apparently this is either not working or not complete. > > Can someone confirm, and/or fix this? I'm working with a slightly older > version of gem5 for this, but it's not that old (a few months). > > Gabe > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
