Re: [gem5-dev] ARM: rfe instruction broken on O3 CPU
I would also recommend opening a bug report for this at: https://gem5.atlassian.net/projects/GEM5/issues with the arch-arm component to make it easier to keep track of. On Tue, Jan 28, 2020 at 4:24 PM Nils Asmussen wrote: > > Hi all, > > I've stumbled upon an issue with ARM's return from exception (rfe) > instruction in combination with the O3 CPU. > > With the TimingSimpleCPU everything works fine. But with the DerivO3CPU it > seems that the restoration of the userspace > SP register does not happen immediately. For example, look at the following > instruction trace: > > 204598: ldmstm > 204598: addi_uop r35, sp, #0 : IntAlu : D=0x00119160 > 1 --> 204598: ldr2_uop r701,r702, [r35, #0] : MemRead : > D=0x006000211e50 A=0x119160 > 204598: add sp, sp, #12: IntAlu : D=0x0011916c > 204598: ldmstm > 204598: ldr2_uop r0,r1, [sp, #0] : MemRead : D=0x > A=0x11916c > 204598: ldr2_uop r2,r3, [sp, #8] : MemRead : D=0x0001 > A=0x119174 > 204598: ldr2_uop r4,r5, [sp, #16] : MemRead : D=0xf020002f2020 > A=0x11917c > 204598: ldr2_uop r6,r7, [sp, #24] : MemRead : D=0x0006 > A=0x119184 > 2045981000: ldr2_uop r8,r9, [sp, #32] : MemRead : D=0x002f228000211f40 > A=0x11918c > 2045981000: ldr2_uop r10,fp, [sp, #40] : MemRead : D=0x00211e6c00211f50 > A=0x119194 > 2045981000: ldr2_uop r12,lr, [sp, #48] : MemRead : D=0x002d4056 > A=0x11919c > 2045981000: addi_uop sp, sp, #56 : IntAlu : D=0x001191a4 > 2 --> 2045987000: rfeia sp! > 2045987000: rfeia sp! : MemRead : D=0x2010 > A=0x1191a4 > 2045987000: addi_uop sp, sp, #8: IntAlu : D=0x001191ac > 2045987000: uopSet_uop [PC,CPSR] : IntAlu : D=0x > 2045993000: ldr r2, [r8, #4] : MemRead : D=0x0003 > A=0x211f44 > 2045993000: cmps r2, #0: IntAlu : D=0x0001 > 2045993000: addne r10, r8, #4 : IntAlu : D=0x00211f44 > 2045993000: movne r4, #0 : IntAlu : D=0x > 2045993000: b <_ZN6kernel8CapTable6obtainEjPNS_10CapabilityE+92> : IntAlu : > Predicated False > 2045993000: ldr r0, [r10, #4]! > 2045993000: ldr r0, [r10, #4]! : MemRead : D=0x00506780 > A=0x211f48 > 2045993000: addi_uop r10, r10, #4 : IntAlu : D=0x00211f48 > 2045993000: add r4, r4, #1 : IntAlu : D=0x0001 > 2045994000: ldr r2, [r0, #0] : MemRead : D=0x002ee14c > A=0x506780 > 2045994000: ldr r2, [r2, #8] : MemRead : D=0x002d95bc > A=0x2ee154 > 2045994000: blx r2 : IntAlu : D=0x002d4078 > 204600: ldmstm > 3 --> 204600: str_uop r4, [sp, #24] : MemWrite : > D=0x0001 A=0x119194 > 204600: str_uop r5, [sp, #20] : MemWrite : D=0xf020 > A=0x119198 > 204600: str_uop r6, [sp, #16] : MemWrite : D=0x0006 > A=0x11919c > 204600: str_uop r7, [sp, #12] : MemWrite : D=0x > A=0x1191a0 > 204600: str_uop fp, [sp, #8] : MemWrite : D=0x00211e6c > A=0x1191a4 > 4 --> 204600: str_uop lr, [sp, #4] : MemWrite : > D=0x0060 A=0x211e4c > 204600: subi_uop sp, sp, #24 : IntAlu : D=0x00211e38 > 2046006000: add fp, sp, #20: IntAlu : D=0x00211e4c > 2046006000: sub sp, sp, #24: IntAlu : D=0x00211e20 > > I've marked the most important lines. 1 is the place where the user space > SP/LR are written. 2 is the place where rfe is > used to return from supervisor mode to user mode. 3 uses the SP for the first > time after returning to user mode. But > note that the value is still 119XXX, so the SP that was used in supervisor > mode. At 4 the value of SP suddenly changes > to 211XXX, as should have happen much earlier. > > In case it matters, I'm using a single-core system with the classical memory > model. > > Am I missing something or is there really something wrong? > > Best regards, > Nils > ___ > 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]: cpu: move initCPU calls from initState to init
Ayaz Akram has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/24884 )
Change subject: cpu: move initCPU calls from initState to init
..
cpu: move initCPU calls from initState to init
This commit moves the initCPU calls from initState to init
of base cpu (which were added in commit 0b8d02dec492215aa).
This is a temporary fix to solve the problem of X86System
initState getting called before initState of base cpu.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-292
Change-Id: I7434cd811536175562cfa2646f4326907fadad8c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24884
Reviewed-by: Gabe Black
Reviewed-by: Jason Lowe-Power
Maintainer: Gabe Black
Tested-by: kokoro
---
M src/cpu/base.cc
M src/cpu/base.hh
2 files changed, 1 insertion(+), 5 deletions(-)
Approvals:
Jason Lowe-Power: Looks good to me, approved
Gabe Black: Looks good to me, approved; Looks good to me, approved
kokoro: Regressions pass
diff --git a/src/cpu/base.cc b/src/cpu/base.cc
index 5d6a857..80726ac 100644
--- a/src/cpu/base.cc
+++ b/src/cpu/base.cc
@@ -318,11 +318,8 @@
verifyMemoryMode();
}
-}
-void
-BaseCPU::initState()
-{
+//These calls eventually need to be moved to initState
if (FullSystem && !params()->switched_out) {
for (auto *tc: threadContexts)
TheISA::initCPU(tc, tc->contextId());
diff --git a/src/cpu/base.hh b/src/cpu/base.hh
index f47bc8e..5b15f41 100644
--- a/src/cpu/base.hh
+++ b/src/cpu/base.hh
@@ -314,7 +314,6 @@
virtual ~BaseCPU();
void init() override;
-void initState() override;
void startup() override;
void regStats() override;
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/24884
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: I7434cd811536175562cfa2646f4326907fadad8c
Gerrit-Change-Number: 24884
Gerrit-PatchSet: 2
Gerrit-Owner: Ayaz Akram
Gerrit-Reviewer: Ayaz Akram
Gerrit-Reviewer: Gabe Black
Gerrit-Reviewer: Jason Lowe-Power
Gerrit-Reviewer: kokoro
Gerrit-MessageType: merged
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Cron /z/m5/regression/do-regression quick
* build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-timing: FAILED! * build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-atomic: FAILED! * build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-switcheroo-timing: FAILED! * build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-atomic-checkpoint: FAILED! * build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-timing-dual: FAILED! * build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-switcheroo-atomic: FAILED! * build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-atomic-dual: FAILED! * build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-atomic: FAILED! * build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-timing-ruby: FAILED! * build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-atomic: FAILED! * build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-timing: FAILED! * build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/minor-timing: FAILED! * build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/o3-timing: FAILED! * build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing-mt: CHANGED! * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing: CHANGED! * build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-two-level: CHANGED! * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing: CHANGED! * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby: CHANGED! * build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-simple: CHANGED! * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic: CHANGED! * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic: CHANGED! * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing: CHANGED! * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual: CHANGED! * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing: CHANGED! * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual: CHANGED! * build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-simple: CHANGED! * build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-two-level: CHANGED! * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby: CHANGED! * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing: CHANGED! * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing: CHANGED! * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic: CHANGED! * build/NULL/tests/opt/quick/se/80.dram-openpage/null/none/dram-lowp: CHANGED! * build/NULL/tests/opt/quick/se/80.dram-closepage/null/none/dram-lowp: CHANGED! * build/NULL/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby: CHANGED! * build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-simple-mem: CHANGED! * build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-dram-ctrl: CHANGED! * build/NULL_MOESI_hammer/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_hammer: CHANGED! * build/NULL_MESI_Two_Level/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MESI_Two_Level: CHANGED! * build/NULL_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_directory: CHANGED! * build/NULL_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_token: CHANGED! * build/POWER/tests/opt/quick/se/00.hello/power/linux/simple-atomic: CHANGED! * build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing: CHANGED! * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-atomic: CHANGED! * build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/o3-timing: CHANGED! * build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-timing: CHANGED! * build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp: CHANGED! * build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-two-level: CHANGED! * build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-timing-mp: CHANGED! * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing: CHANGED! * build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-atomic: CHANGED! * build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-simple: CHANGED! * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing-ruby: CHANGED! * build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/o3-timing-mp: CHANGED! *
Re: [gem5-dev] ARM: rfe instruction broken on O3 CPU
It looks to me like this is because the MicroUopSetPCCPSR microop (uopSet_uop, the one actually setting the CPSR) is not marked as IsSerializeAfter. The macroop it's a part of is, but the flags on macroops, other than the one that says it's a macroop, don't matter since they are never executed. Their job is just to spit out microops which are executed. The offending microop is not set as IsSerializeAfter, so the instructions behind it start getting processed before it's completed and updated the CPSR and exception level. The stack pointer index is resolved to a particular stack pointer at that point and reflects the old CPSR/exception level and not the new one. A full fix from ARM would probably involve taking away the unused and slightly confusing flags from the macroop that don't do anything which I don't want to dig into myself. To get things working for you, you can *probably* just add IsSerializeAfter to MicroOupSetPCCPSR in arch/arm/isa/insts/macromem.isa on about line 690, right after IsMicroop. So ['IsMicrop'] would become ['IsMicroop', 'IsSerializeAfter']. That instruction/microop should unconditionally be IsSerializeAfter since it modifies state which is used to interpret register indices in later instructions, and if it isn't those instructions will be set up incorrectly like you're seeing here. Gabe On Tue, Jan 28, 2020 at 8:24 AM Nils Asmussen wrote: > Hi all, > > I've stumbled upon an issue with ARM's return from exception (rfe) > instruction in combination with the O3 CPU. > > With the TimingSimpleCPU everything works fine. But with the DerivO3CPU it > seems that the restoration of the userspace > SP register does not happen immediately. For example, look at the > following instruction trace: > > 204598 <(204)%20598->: ldmstm > 204598 <(204)%20598->: addi_uop r35, sp, #0 : IntAlu : > D=0x00119160 > 1 --> 204598 <(204)%20598->: ldr2_uop r701,r702, [r35, #0] : > MemRead : D=0x006000211e50 A=0x119160 > 204598 <(204)%20598->: add sp, sp, #12: IntAlu : > D=0x0011916c > 204598 <(204)%20598->: ldmstm > 204598 <(204)%20598->: ldr2_uop r0,r1, [sp, #0] : MemRead : > D=0x A=0x11916c > 204598 <(204)%20598->: ldr2_uop r2,r3, [sp, #8] : MemRead : > D=0x0001 A=0x119174 > 204598 <(204)%20598->: ldr2_uop r4,r5, [sp, #16] : MemRead : > D=0xf020002f2020 A=0x11917c > 204598 <(204)%20598->: ldr2_uop r6,r7, [sp, #24] : MemRead : > D=0x0006 A=0x119184 > 2045981000 <(204)%20598-1000>: ldr2_uop r8,r9, [sp, #32] : MemRead : > D=0x002f228000211f40 A=0x11918c > 2045981000 <(204)%20598-1000>: ldr2_uop r10,fp, [sp, #40] : MemRead > : D=0x00211e6c00211f50 A=0x119194 > 2045981000 <(204)%20598-1000>: ldr2_uop r12,lr, [sp, #48] : MemRead > : D=0x002d4056 A=0x11919c > 2045981000 <(204)%20598-1000>: addi_uop sp, sp, #56 : IntAlu : > D=0x001191a4 > 2 --> 2045987000 <(204)%20598-7000>: rfeia sp! > 2045987000 <(204)%20598-7000>: rfeia sp! : MemRead : > D=0x2010 A=0x1191a4 > 2045987000 <(204)%20598-7000>: addi_uop sp, sp, #8: IntAlu : > D=0x001191ac > 2045987000 <(204)%20598-7000>: uopSet_uop [PC,CPSR] : IntAlu : > D=0x > 2045993000 <(204)%20599-3000>: ldr r2, [r8, #4] : MemRead : > D=0x0003 A=0x211f44 > 2045993000 <(204)%20599-3000>: cmps r2, #0: IntAlu : > D=0x0001 > 2045993000 <(204)%20599-3000>: addne r10, r8, #4 : IntAlu : > D=0x00211f44 > 2045993000 <(204)%20599-3000>: movne r4, #0 : IntAlu : > D=0x > 2045993000 <(204)%20599-3000>: b > <_ZN6kernel8CapTable6obtainEjPNS_10CapabilityE+92> : IntAlu : Predicated > False > 2045993000 <(204)%20599-3000>: ldr r0, [r10, #4]! > 2045993000 <(204)%20599-3000>: ldr r0, [r10, #4]! : MemRead : > D=0x00506780 A=0x211f48 > 2045993000 <(204)%20599-3000>: addi_uop r10, r10, #4 : IntAlu : > D=0x00211f48 > 2045993000 <(204)%20599-3000>: add r4, r4, #1 : IntAlu : > D=0x0001 > 2045994000 <(204)%20599-4000>: ldr r2, [r0, #0] : MemRead : > D=0x002ee14c A=0x506780 > 2045994000 <(204)%20599-4000>: ldr r2, [r2, #8] : MemRead : > D=0x002d95bc A=0x2ee154 > 2045994000 <(204)%20599-4000>: blx r2 : IntAlu : > D=0x002d4078 > 204600 <(204)%20600->: ldmstm > 3 --> 204600 <(204)%20600->: str_uop r4, [sp, #24] : > MemWrite : D=0x0001 A=0x119194 > 204600 <(204)%20600->: str_uop r5, [sp, #20] : MemWrite : > D=0xf020 A=0x119198 > 204600 <(204)%20600->: str_uop r6, [sp, #16] : MemWrite : > D=0x0006 A=0x11919c > 204600 <(204)%20600->: str_uop r7, [sp, #12] : MemWrite : > D=0x A=0x1191a0 > 204600 <(204)%20600->:
[gem5-dev] Change in gem5/gem5[master]: cpu: move initCPU calls from initState to init
Ayaz Akram has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/24884 )
Change subject: cpu: move initCPU calls from initState to init
..
cpu: move initCPU calls from initState to init
This commit moves the initCPU calls from initState to init
of base cpu (which were added in commit 0b8d02dec492215aa).
This is a temporary fix to solve the problem of X86System
initState getting called before initState of base cpu.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-292
Change-Id: I7434cd811536175562cfa2646f4326907fadad8c
---
M src/cpu/base.cc
M src/cpu/base.hh
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/cpu/base.cc b/src/cpu/base.cc
index 5d6a857..80726ac 100644
--- a/src/cpu/base.cc
+++ b/src/cpu/base.cc
@@ -318,11 +318,8 @@
verifyMemoryMode();
}
-}
-void
-BaseCPU::initState()
-{
+//These calls eventually need to be moved to initState
if (FullSystem && !params()->switched_out) {
for (auto *tc: threadContexts)
TheISA::initCPU(tc, tc->contextId());
diff --git a/src/cpu/base.hh b/src/cpu/base.hh
index f47bc8e..5b15f41 100644
--- a/src/cpu/base.hh
+++ b/src/cpu/base.hh
@@ -314,7 +314,6 @@
virtual ~BaseCPU();
void init() override;
-void initState() override;
void startup() override;
void regStats() override;
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/24884
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: I7434cd811536175562cfa2646f4326907fadad8c
Gerrit-Change-Number: 24884
Gerrit-PatchSet: 1
Gerrit-Owner: Ayaz Akram
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Possible website outage during changeover
Hi all, In the next couple of hours, I'm going to be switching over our website from the current wiki (viewable in static form at http://old.gem5.org/) to the new website (http://new.gem5.org/). There may be some downtime as the DNS servers make the switch. Or, what's more likely, is there's some downtime because I break something :). Just FYI. Cheers, Jason ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Ruby question
Hi Giacomo, You cannot include a header in an .sm file. As far as I know, you also can't use general enums in SLICC either. You could take advantage of the fact that enums are compatible with integers, possibly, to get around this. You can also declare enums in the SLICC, but that will create another enum type. See src/mem/ruby/protocol/RubySlicc_Exports.sm for some examples of SLICC enums. For example, RubyRequestType is used in the gem5 C++ code, but the enum is declared in SLICC. Generally, if you need to reference a type outside of SLICC, you have to expose it by using the `external_type` keyword or by creating a SLICC `structure` and declaring it as `external=True`. You can do this wherever you want in the SLICC code before you use the type (i.e., you don't have to do it in RubySlicc_Types.sm). SLICC `structures` are equivalent to C++ classes and `external_type`s can be classes, typedefs, etc. You can try to declare your enum as an external type, but you won't be able to use the enumeration constants in SLICC, as far as I know. This is a good example of what I was taught about SLICC/Ruby when I was first learning about it from Brad: Whenever you do anything new with SLICC, you'll have to make modifications to the language. I'm not certain of this, but it's most likely that if you want to use a gem5 enum in SLICC, you'll have to extend the compiler to support that (or just find a way around it). Cheers, Jason On Tue, Jan 28, 2020 at 3:36 AM Giacomo Travaglini < giacomo.travagl...@arm.com> wrote: > A question to the Ruby experts: > > How can I include a header file in a .sm one? > More specifically I would like to refer to a gem5 enum from within the sm > file. > > Thanks > > Giacomo > 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 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] ARM: rfe instruction broken on O3 CPU
Hi all, I've stumbled upon an issue with ARM's return from exception (rfe) instruction in combination with the O3 CPU. With the TimingSimpleCPU everything works fine. But with the DerivO3CPU it seems that the restoration of the userspace SP register does not happen immediately. For example, look at the following instruction trace: 204598: ldmstm 204598: addi_uop r35, sp, #0 : IntAlu : D=0x00119160 1 --> 204598: ldr2_uop r701,r702, [r35, #0] : MemRead : D=0x006000211e50 A=0x119160 204598: add sp, sp, #12: IntAlu : D=0x0011916c 204598: ldmstm 204598: ldr2_uop r0,r1, [sp, #0] : MemRead : D=0x A=0x11916c 204598: ldr2_uop r2,r3, [sp, #8] : MemRead : D=0x0001 A=0x119174 204598: ldr2_uop r4,r5, [sp, #16] : MemRead : D=0xf020002f2020 A=0x11917c 204598: ldr2_uop r6,r7, [sp, #24] : MemRead : D=0x0006 A=0x119184 2045981000: ldr2_uop r8,r9, [sp, #32] : MemRead : D=0x002f228000211f40 A=0x11918c 2045981000: ldr2_uop r10,fp, [sp, #40] : MemRead : D=0x00211e6c00211f50 A=0x119194 2045981000: ldr2_uop r12,lr, [sp, #48] : MemRead : D=0x002d4056 A=0x11919c 2045981000: addi_uop sp, sp, #56 : IntAlu : D=0x001191a4 2 --> 2045987000: rfeia sp! 2045987000: rfeia sp! : MemRead : D=0x2010 A=0x1191a4 2045987000: addi_uop sp, sp, #8: IntAlu : D=0x001191ac 2045987000: uopSet_uop [PC,CPSR] : IntAlu : D=0x 2045993000: ldr r2, [r8, #4] : MemRead : D=0x0003 A=0x211f44 2045993000: cmps r2, #0: IntAlu : D=0x0001 2045993000: addne r10, r8, #4 : IntAlu : D=0x00211f44 2045993000: movne r4, #0 : IntAlu : D=0x 2045993000: b <_ZN6kernel8CapTable6obtainEjPNS_10CapabilityE+92> : IntAlu : Predicated False 2045993000: ldr r0, [r10, #4]! 2045993000: ldr r0, [r10, #4]! : MemRead : D=0x00506780 A=0x211f48 2045993000: addi_uop r10, r10, #4 : IntAlu : D=0x00211f48 2045993000: add r4, r4, #1 : IntAlu : D=0x0001 2045994000: ldr r2, [r0, #0] : MemRead : D=0x002ee14c A=0x506780 2045994000: ldr r2, [r2, #8] : MemRead : D=0x002d95bc A=0x2ee154 2045994000: blx r2 : IntAlu : D=0x002d4078 204600: ldmstm 3 --> 204600: str_uop r4, [sp, #24] : MemWrite : D=0x0001 A=0x119194 204600: str_uop r5, [sp, #20] : MemWrite : D=0xf020 A=0x119198 204600: str_uop r6, [sp, #16] : MemWrite : D=0x0006 A=0x11919c 204600: str_uop r7, [sp, #12] : MemWrite : D=0x A=0x1191a0 204600: str_uop fp, [sp, #8] : MemWrite : D=0x00211e6c A=0x1191a4 4 --> 204600: str_uop lr, [sp, #4] : MemWrite : D=0x0060 A=0x211e4c 204600: subi_uop sp, sp, #24 : IntAlu : D=0x00211e38 2046006000: add fp, sp, #20: IntAlu : D=0x00211e4c 2046006000: sub sp, sp, #24: IntAlu : D=0x00211e20 I've marked the most important lines. 1 is the place where the user space SP/LR are written. 2 is the place where rfe is used to return from supervisor mode to user mode. 3 uses the SP for the first time after returning to user mode. But note that the value is still 119XXX, so the SP that was used in supervisor mode. At 4 the value of SP suddenly changes to 211XXX, as should have happen much earlier. In case it matters, I'm using a single-core system with the classical memory model. Am I missing something or is there really something wrong? Best regards, Nils ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: arch-arm: Fix definition of SVE load-and-replicate quadword instructions
Victor Soria has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/24863 )
Change subject: arch-arm: Fix definition of SVE load-and-replicate quadword
instructions
..
arch-arm: Fix definition of SVE load-and-replicate quadword instructions
Wrong operand type in template function. This bug causes a segmentation
fault.
Signed-off-by: Víctor Soria Pardos
Change-Id: Icb7161e4bba72f008e8b80c677b1c106091cbfac
---
M src/arch/arm/isa/insts/sve_mem.isa
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/arch/arm/isa/insts/sve_mem.isa
b/src/arch/arm/isa/insts/sve_mem.isa
index b36c1b2..c34e78a 100644
--- a/src/arch/arm/isa/insts/sve_mem.isa
+++ b/src/arch/arm/isa/insts/sve_mem.isa
@@ -1517,7 +1517,7 @@
eCount = ArmStaticInst::getCurSveVecLen<__uint128_t>(
xc->tcBase());
for (int i = 0; i < eCount; ++i) {
-AA64FpDest_uq[i] = qword;
+AA64FpDest_x[i] = qword;
}
'''
iop = InstObjParams('ld1rq',
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/24863
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: Icb7161e4bba72f008e8b80c677b1c106091cbfac
Gerrit-Change-Number: 24863
Gerrit-PatchSet: 1
Gerrit-Owner: Victor Soria
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Ruby question
A question to the Ruby experts: How can I include a header file in a .sm one? More specifically I would like to refer to a gem5 enum from within the sm file. Thanks Giacomo 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
