[gem5-dev] Change in public/gem5[master]: gpu-compute: change src/regOpDist stat bucket size to 1

[Mark Wyse (Gerrit)]

Mark Wyse has uploaded this change for review. (  
https://gem5-review.googlesource.com/2343



Change subject: gpu-compute: change src/regOpDist stat bucket size to 1
..

gpu-compute: change src/regOpDist stat bucket size to 1

Change-Id: I8ba451fbb49940bfc98ca4028e1d759f83ef9be9
---
M src/gpu-compute/wavefront.cc
1 file changed, 2 insertions(+), 2 deletions(-)



diff --git a/src/gpu-compute/wavefront.cc b/src/gpu-compute/wavefront.cc
index de36dd5..32b8f2b 100644
--- a/src/gpu-compute/wavefront.cc
+++ b/src/gpu-compute/wavefront.cc
@@ -97,13 +97,13 @@
 SimObject::regStats();

 srcRegOpDist
-.init(0, 4, 2)
+.init(0, 4, 1)
 .name(name() + ".src_reg_operand_dist")
 .desc("number of executed instructions with N source register  
operands")

 ;

 dstRegOpDist
-.init(0, 3, 2)
+.init(0, 3, 1)
 .name(name() + ".dst_reg_operand_dist")
 .desc("number of executed instructions with N destination  
register "

   "operands")

--
To view, visit https://gem5-review.googlesource.com/2343
To unsubscribe, visit https://gem5-review.googlesource.com/settings

Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-MessageType: newchange
Gerrit-Change-Id: I8ba451fbb49940bfc98ca4028e1d759f83ef9be9
Gerrit-Change-Number: 2343
Gerrit-PatchSet: 1
Gerrit-Owner: Mark Wyse 
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Exception in Speculated Instruction?

[Gabe Black]

If your ISA doesn't support unaligned accesses, the page table code should
return a fault (architectural or made up) and return that. If it does and
you're not expecting one that's a different story since it indicates some
other bit of code isn't doing it's job, for instance not splitting up an
access.

If there's no architectural fault which makes sense and you're just
reporting something you don't handle yet, etc., you can make up a fault
which just calls panic() when it's invoked. I think M5DebugFault will help,
in src/arch/generic/debugfaults.hh. You could also take this approach if
this is in SE mode for instance, and there's nowhere for the full blown
architectural exception mechanism to send simulated execution to handle
things.

Gabe

On Fri, Mar 10, 2017 at 3:13 PM, Steve Reinhardt  wrote:

> I haven't looked at the source directly to see how much of the unaligned
> access code is in x86-specific code vs. generic code, and I don't remember
> off the top of my head. I'm glad to hear that the splitRequest() call is in
> the generic part of the code.
>
> The symptom that you're getting implies that the TLB is being accessed with
> a non-split unaligned request though, so there must be some code path where
> this is not handled automatically by setting HasUnalignedMemAcc. I'd
> suggest getting a stack trace from where you hit this assertion to see
> where this call is coming from, and why it's not using the split version of
> the requests.
>
> Steve
>
>
> On Fri, Mar 10, 2017 at 3:06 PM, Alec Roelke  wrote:
>
> > There used to be a problem that looked similar to this one where an ld
> > instruction would cross a cache line, and to fix that I was advised to
> look
> > at the splitRequest() function for help.  In doing so, I found that
> > initiateMemRead() in BaseDynInst already calls it if the ISA supports
> > unaligned memory accesses, so I set RISC-V to do that and that problem
> was
> > fixed.  I haven't looked at x86's implementation of anything yet due to
> its
> > complexity; does x86 have additional code beyond this to handle unaligned
> > accesses?
> >
> > On Fri, Mar 10, 2017 at 5:14 PM, Steve Reinhardt 
> wrote:
> >
> > > Have you looked at how x86 supports unaligned accesses? The gem5 memory
> > > system does not support them natively; you have to check if your access
> > is
> > > unaligned, and issue two requests to the cache for the two halves to
> > > guarantee there are no cache line or page crossings within a single
> > > request.
> > >
> > > Steve
> > >
> > >
> > > On Fri, Mar 10, 2017 at 2:06 PM, Alec Roelke 
> wrote:
> > >
> > > > I get an assertion failure:
> > > >
> > > > build/RISCV/mem/page_table.cc:190: Fault
> > > > PageTableBase::translate(RequestPtr): Assertion
> > > `pageAlign(req->getVaddr()
> > > > + req->getSize() - 1) == pageAlign(req->getVaddr())' failed.
> > > >
> > > > I can't tell from my debug trace (with Exec and Commit flags on) if
> > this
> > > is
> > > > happening during exec or commit.  I can see that there's an ld
> > > instruction
> > > > preceding the ret instruction that is supposed to load the correct
> > > address
> > > > into the return-address register, but for some reason is unable to
> > > commit.
> > > > A more complete trace looks like this:
> > > >
> > > > ...
> > > > ret < this ret appears to execute properly
> > > > ld ra,24(sp) <--- this never commits
> > > > li a0,0
> > > > ld s0,16(sp)
> > > > ld s1,8(sp)
> > > > addi sp,sp,32
> > > > ret
> > > > ld s1,0(a1) < this is executed speculatively, but a1 isn't a
> valid
> > > > address
> > > > ...
> > > >
> > > > Register a1 contains -1 at this point.
> > > >
> > > > The commit log doesn't show me any information about that last
> > > instruction
> > > > except for when it is inserted into the ROB, which is why I
> originally
> > > > thought the error was happening during speculation.
> > > >
> > > > On Fri, Mar 10, 2017 at 4:45 PM, Steve Reinhardt 
> > > wrote:
> > > >
> > > > > The instruction should be marked as causing a fault, but the fault
> > > action
> > > > > should not be invoked until the instruction is committed. Because
> > it's
> > > a
> > > > > mis-speculated instruction, it will never be committed, so the
> fault
> > > > should
> > > > > never be observed. I'm not sure what you mean by "crashes", so I'm
> > not
> > > > sure
> > > > > what part of this process is not operating properly for you.
> > > > >
> > > > > Steve
> > > > >
> > > > >
> > > > > On Fri, Mar 10, 2017 at 1:40 PM, Alec Roelke 
> > > wrote:
> > > > >
> > > > > > Hello Everyone,
> > > > > >
> > > > > > I'm trying to debug RISC-V running on the O3 model, and I've
> > > > encountered
> > > > > a
> > > > > > problem where the CPU tries to speculatively execute a load
> > > instruction
> > > > > > (which is actually along a branch that ends up not being taken)
> in
> > > > which
> > > > > > 

Re: [gem5-dev] Exception in Speculated Instruction?

[Steve Reinhardt]

I haven't looked at the source directly to see how much of the unaligned
access code is in x86-specific code vs. generic code, and I don't remember
off the top of my head. I'm glad to hear that the splitRequest() call is in
the generic part of the code.

The symptom that you're getting implies that the TLB is being accessed with
a non-split unaligned request though, so there must be some code path where
this is not handled automatically by setting HasUnalignedMemAcc. I'd
suggest getting a stack trace from where you hit this assertion to see
where this call is coming from, and why it's not using the split version of
the requests.

Steve


On Fri, Mar 10, 2017 at 3:06 PM, Alec Roelke  wrote:

> There used to be a problem that looked similar to this one where an ld
> instruction would cross a cache line, and to fix that I was advised to look
> at the splitRequest() function for help.  In doing so, I found that
> initiateMemRead() in BaseDynInst already calls it if the ISA supports
> unaligned memory accesses, so I set RISC-V to do that and that problem was
> fixed.  I haven't looked at x86's implementation of anything yet due to its
> complexity; does x86 have additional code beyond this to handle unaligned
> accesses?
>
> On Fri, Mar 10, 2017 at 5:14 PM, Steve Reinhardt  wrote:
>
> > Have you looked at how x86 supports unaligned accesses? The gem5 memory
> > system does not support them natively; you have to check if your access
> is
> > unaligned, and issue two requests to the cache for the two halves to
> > guarantee there are no cache line or page crossings within a single
> > request.
> >
> > Steve
> >
> >
> > On Fri, Mar 10, 2017 at 2:06 PM, Alec Roelke  wrote:
> >
> > > I get an assertion failure:
> > >
> > > build/RISCV/mem/page_table.cc:190: Fault
> > > PageTableBase::translate(RequestPtr): Assertion
> > `pageAlign(req->getVaddr()
> > > + req->getSize() - 1) == pageAlign(req->getVaddr())' failed.
> > >
> > > I can't tell from my debug trace (with Exec and Commit flags on) if
> this
> > is
> > > happening during exec or commit.  I can see that there's an ld
> > instruction
> > > preceding the ret instruction that is supposed to load the correct
> > address
> > > into the return-address register, but for some reason is unable to
> > commit.
> > > A more complete trace looks like this:
> > >
> > > ...
> > > ret < this ret appears to execute properly
> > > ld ra,24(sp) <--- this never commits
> > > li a0,0
> > > ld s0,16(sp)
> > > ld s1,8(sp)
> > > addi sp,sp,32
> > > ret
> > > ld s1,0(a1) < this is executed speculatively, but a1 isn't a valid
> > > address
> > > ...
> > >
> > > Register a1 contains -1 at this point.
> > >
> > > The commit log doesn't show me any information about that last
> > instruction
> > > except for when it is inserted into the ROB, which is why I originally
> > > thought the error was happening during speculation.
> > >
> > > On Fri, Mar 10, 2017 at 4:45 PM, Steve Reinhardt 
> > wrote:
> > >
> > > > The instruction should be marked as causing a fault, but the fault
> > action
> > > > should not be invoked until the instruction is committed. Because
> it's
> > a
> > > > mis-speculated instruction, it will never be committed, so the fault
> > > should
> > > > never be observed. I'm not sure what you mean by "crashes", so I'm
> not
> > > sure
> > > > what part of this process is not operating properly for you.
> > > >
> > > > Steve
> > > >
> > > >
> > > > On Fri, Mar 10, 2017 at 1:40 PM, Alec Roelke 
> > wrote:
> > > >
> > > > > Hello Everyone,
> > > > >
> > > > > I'm trying to debug RISC-V running on the O3 model, and I've
> > > encountered
> > > > a
> > > > > problem where the CPU tries to speculatively execute a load
> > instruction
> > > > > (which is actually along a branch that ends up not being taken) in
> > > which
> > > > > the data crosses a page boundary and causes a fault.
> > > > >
> > > > > The specific section of code looks like this:
> > > > >
> > > > > ...
> > > > > ret
> > > > > ld s1,0(a1)
> > > > > ...
> > > > >
> > > > > If you're not familiar with RISC-V, ret is a pseudo-instruction
> that
> > > just
> > > > > jumps to whatever address is stored in the return-address register,
> > and
> > > > ld
> > > > > loads a 64-bit value from memory.
> > > > >
> > > > > The problem I'm encountering is that the value stored in register
> a1
> > is
> > > > not
> > > > > a valid address as that instruction is not supposed to be executed,
> > and
> > > > it
> > > > > just so happens that the word it points to crosses a page boundary.
> > > When
> > > > > gem5 speculatively executes this, it crashes.
> > > > >
> > > > > How can I prevent gem5 from doing this?  I know I could flag load
> and
> > > > store
> > > > > instructions as being nonspeculative, but that will slow down
> > execution
> > > > and
> > > > > affect output stats.  I'm working on top of these four 

Re: [gem5-dev] Exception in Speculated Instruction?

[Alec Roelke]

There used to be a problem that looked similar to this one where an ld
instruction would cross a cache line, and to fix that I was advised to look
at the splitRequest() function for help.  In doing so, I found that
initiateMemRead() in BaseDynInst already calls it if the ISA supports
unaligned memory accesses, so I set RISC-V to do that and that problem was
fixed.  I haven't looked at x86's implementation of anything yet due to its
complexity; does x86 have additional code beyond this to handle unaligned
accesses?

On Fri, Mar 10, 2017 at 5:14 PM, Steve Reinhardt  wrote:

> Have you looked at how x86 supports unaligned accesses? The gem5 memory
> system does not support them natively; you have to check if your access is
> unaligned, and issue two requests to the cache for the two halves to
> guarantee there are no cache line or page crossings within a single
> request.
>
> Steve
>
>
> On Fri, Mar 10, 2017 at 2:06 PM, Alec Roelke  wrote:
>
> > I get an assertion failure:
> >
> > build/RISCV/mem/page_table.cc:190: Fault
> > PageTableBase::translate(RequestPtr): Assertion
> `pageAlign(req->getVaddr()
> > + req->getSize() - 1) == pageAlign(req->getVaddr())' failed.
> >
> > I can't tell from my debug trace (with Exec and Commit flags on) if this
> is
> > happening during exec or commit.  I can see that there's an ld
> instruction
> > preceding the ret instruction that is supposed to load the correct
> address
> > into the return-address register, but for some reason is unable to
> commit.
> > A more complete trace looks like this:
> >
> > ...
> > ret < this ret appears to execute properly
> > ld ra,24(sp) <--- this never commits
> > li a0,0
> > ld s0,16(sp)
> > ld s1,8(sp)
> > addi sp,sp,32
> > ret
> > ld s1,0(a1) < this is executed speculatively, but a1 isn't a valid
> > address
> > ...
> >
> > Register a1 contains -1 at this point.
> >
> > The commit log doesn't show me any information about that last
> instruction
> > except for when it is inserted into the ROB, which is why I originally
> > thought the error was happening during speculation.
> >
> > On Fri, Mar 10, 2017 at 4:45 PM, Steve Reinhardt 
> wrote:
> >
> > > The instruction should be marked as causing a fault, but the fault
> action
> > > should not be invoked until the instruction is committed. Because it's
> a
> > > mis-speculated instruction, it will never be committed, so the fault
> > should
> > > never be observed. I'm not sure what you mean by "crashes", so I'm not
> > sure
> > > what part of this process is not operating properly for you.
> > >
> > > Steve
> > >
> > >
> > > On Fri, Mar 10, 2017 at 1:40 PM, Alec Roelke 
> wrote:
> > >
> > > > Hello Everyone,
> > > >
> > > > I'm trying to debug RISC-V running on the O3 model, and I've
> > encountered
> > > a
> > > > problem where the CPU tries to speculatively execute a load
> instruction
> > > > (which is actually along a branch that ends up not being taken) in
> > which
> > > > the data crosses a page boundary and causes a fault.
> > > >
> > > > The specific section of code looks like this:
> > > >
> > > > ...
> > > > ret
> > > > ld s1,0(a1)
> > > > ...
> > > >
> > > > If you're not familiar with RISC-V, ret is a pseudo-instruction that
> > just
> > > > jumps to whatever address is stored in the return-address register,
> and
> > > ld
> > > > loads a 64-bit value from memory.
> > > >
> > > > The problem I'm encountering is that the value stored in register a1
> is
> > > not
> > > > a valid address as that instruction is not supposed to be executed,
> and
> > > it
> > > > just so happens that the word it points to crosses a page boundary.
> > When
> > > > gem5 speculatively executes this, it crashes.
> > > >
> > > > How can I prevent gem5 from doing this?  I know I could flag load and
> > > store
> > > > instructions as being nonspeculative, but that will slow down
> execution
> > > and
> > > > affect output stats.  I'm working on top of these four patches:
> > > >
> > > >- https://gem5-review.googlesource.com/c/2304/
> > > >- https://gem5-review.googlesource.com/c/2305/5
> > > >- https://gem5-review.googlesource.com/c/2340/2
> > > >- https://gem5-review.googlesource.com/c/2341/2
> > > >
> > > > Thanks,
> > > > Alec Roelke
> > > > ___
> > > > 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 mailing 

Re: [gem5-dev] Exception in Speculated Instruction?

[Steve Reinhardt]

Have you looked at how x86 supports unaligned accesses? The gem5 memory
system does not support them natively; you have to check if your access is
unaligned, and issue two requests to the cache for the two halves to
guarantee there are no cache line or page crossings within a single request.

Steve


On Fri, Mar 10, 2017 at 2:06 PM, Alec Roelke  wrote:

> I get an assertion failure:
>
> build/RISCV/mem/page_table.cc:190: Fault
> PageTableBase::translate(RequestPtr): Assertion `pageAlign(req->getVaddr()
> + req->getSize() - 1) == pageAlign(req->getVaddr())' failed.
>
> I can't tell from my debug trace (with Exec and Commit flags on) if this is
> happening during exec or commit.  I can see that there's an ld instruction
> preceding the ret instruction that is supposed to load the correct address
> into the return-address register, but for some reason is unable to commit.
> A more complete trace looks like this:
>
> ...
> ret < this ret appears to execute properly
> ld ra,24(sp) <--- this never commits
> li a0,0
> ld s0,16(sp)
> ld s1,8(sp)
> addi sp,sp,32
> ret
> ld s1,0(a1) < this is executed speculatively, but a1 isn't a valid
> address
> ...
>
> Register a1 contains -1 at this point.
>
> The commit log doesn't show me any information about that last instruction
> except for when it is inserted into the ROB, which is why I originally
> thought the error was happening during speculation.
>
> On Fri, Mar 10, 2017 at 4:45 PM, Steve Reinhardt  wrote:
>
> > The instruction should be marked as causing a fault, but the fault action
> > should not be invoked until the instruction is committed. Because it's a
> > mis-speculated instruction, it will never be committed, so the fault
> should
> > never be observed. I'm not sure what you mean by "crashes", so I'm not
> sure
> > what part of this process is not operating properly for you.
> >
> > Steve
> >
> >
> > On Fri, Mar 10, 2017 at 1:40 PM, Alec Roelke  wrote:
> >
> > > Hello Everyone,
> > >
> > > I'm trying to debug RISC-V running on the O3 model, and I've
> encountered
> > a
> > > problem where the CPU tries to speculatively execute a load instruction
> > > (which is actually along a branch that ends up not being taken) in
> which
> > > the data crosses a page boundary and causes a fault.
> > >
> > > The specific section of code looks like this:
> > >
> > > ...
> > > ret
> > > ld s1,0(a1)
> > > ...
> > >
> > > If you're not familiar with RISC-V, ret is a pseudo-instruction that
> just
> > > jumps to whatever address is stored in the return-address register, and
> > ld
> > > loads a 64-bit value from memory.
> > >
> > > The problem I'm encountering is that the value stored in register a1 is
> > not
> > > a valid address as that instruction is not supposed to be executed, and
> > it
> > > just so happens that the word it points to crosses a page boundary.
> When
> > > gem5 speculatively executes this, it crashes.
> > >
> > > How can I prevent gem5 from doing this?  I know I could flag load and
> > store
> > > instructions as being nonspeculative, but that will slow down execution
> > and
> > > affect output stats.  I'm working on top of these four patches:
> > >
> > >- https://gem5-review.googlesource.com/c/2304/
> > >- https://gem5-review.googlesource.com/c/2305/5
> > >- https://gem5-review.googlesource.com/c/2340/2
> > >- https://gem5-review.googlesource.com/c/2341/2
> > >
> > > Thanks,
> > > Alec Roelke
> > > ___
> > > 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

Re: [gem5-dev] Exception in Speculated Instruction?

[Alec Roelke]

I get an assertion failure:

build/RISCV/mem/page_table.cc:190: Fault
PageTableBase::translate(RequestPtr): Assertion `pageAlign(req->getVaddr()
+ req->getSize() - 1) == pageAlign(req->getVaddr())' failed.

I can't tell from my debug trace (with Exec and Commit flags on) if this is
happening during exec or commit.  I can see that there's an ld instruction
preceding the ret instruction that is supposed to load the correct address
into the return-address register, but for some reason is unable to commit.
A more complete trace looks like this:

...
ret < this ret appears to execute properly
ld ra,24(sp) <--- this never commits
li a0,0
ld s0,16(sp)
ld s1,8(sp)
addi sp,sp,32
ret
ld s1,0(a1) < this is executed speculatively, but a1 isn't a valid
address
...

Register a1 contains -1 at this point.

The commit log doesn't show me any information about that last instruction
except for when it is inserted into the ROB, which is why I originally
thought the error was happening during speculation.

On Fri, Mar 10, 2017 at 4:45 PM, Steve Reinhardt  wrote:

> The instruction should be marked as causing a fault, but the fault action
> should not be invoked until the instruction is committed. Because it's a
> mis-speculated instruction, it will never be committed, so the fault should
> never be observed. I'm not sure what you mean by "crashes", so I'm not sure
> what part of this process is not operating properly for you.
>
> Steve
>
>
> On Fri, Mar 10, 2017 at 1:40 PM, Alec Roelke  wrote:
>
> > Hello Everyone,
> >
> > I'm trying to debug RISC-V running on the O3 model, and I've encountered
> a
> > problem where the CPU tries to speculatively execute a load instruction
> > (which is actually along a branch that ends up not being taken) in which
> > the data crosses a page boundary and causes a fault.
> >
> > The specific section of code looks like this:
> >
> > ...
> > ret
> > ld s1,0(a1)
> > ...
> >
> > If you're not familiar with RISC-V, ret is a pseudo-instruction that just
> > jumps to whatever address is stored in the return-address register, and
> ld
> > loads a 64-bit value from memory.
> >
> > The problem I'm encountering is that the value stored in register a1 is
> not
> > a valid address as that instruction is not supposed to be executed, and
> it
> > just so happens that the word it points to crosses a page boundary.  When
> > gem5 speculatively executes this, it crashes.
> >
> > How can I prevent gem5 from doing this?  I know I could flag load and
> store
> > instructions as being nonspeculative, but that will slow down execution
> and
> > affect output stats.  I'm working on top of these four patches:
> >
> >- https://gem5-review.googlesource.com/c/2304/
> >- https://gem5-review.googlesource.com/c/2305/5
> >- https://gem5-review.googlesource.com/c/2340/2
> >- https://gem5-review.googlesource.com/c/2341/2
> >
> > Thanks,
> > Alec Roelke
> > ___
> > 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] Exception in Speculated Instruction?

[Steve Reinhardt]

The instruction should be marked as causing a fault, but the fault action
should not be invoked until the instruction is committed. Because it's a
mis-speculated instruction, it will never be committed, so the fault should
never be observed. I'm not sure what you mean by "crashes", so I'm not sure
what part of this process is not operating properly for you.

Steve


On Fri, Mar 10, 2017 at 1:40 PM, Alec Roelke  wrote:

> Hello Everyone,
>
> I'm trying to debug RISC-V running on the O3 model, and I've encountered a
> problem where the CPU tries to speculatively execute a load instruction
> (which is actually along a branch that ends up not being taken) in which
> the data crosses a page boundary and causes a fault.
>
> The specific section of code looks like this:
>
> ...
> ret
> ld s1,0(a1)
> ...
>
> If you're not familiar with RISC-V, ret is a pseudo-instruction that just
> jumps to whatever address is stored in the return-address register, and ld
> loads a 64-bit value from memory.
>
> The problem I'm encountering is that the value stored in register a1 is not
> a valid address as that instruction is not supposed to be executed, and it
> just so happens that the word it points to crosses a page boundary.  When
> gem5 speculatively executes this, it crashes.
>
> How can I prevent gem5 from doing this?  I know I could flag load and store
> instructions as being nonspeculative, but that will slow down execution and
> affect output stats.  I'm working on top of these four patches:
>
>- https://gem5-review.googlesource.com/c/2304/
>- https://gem5-review.googlesource.com/c/2305/5
>- https://gem5-review.googlesource.com/c/2340/2
>- https://gem5-review.googlesource.com/c/2341/2
>
> Thanks,
> Alec Roelke
> ___
> 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] Exception in Speculated Instruction?

[Alec Roelke]

Hello Everyone,

I'm trying to debug RISC-V running on the O3 model, and I've encountered a
problem where the CPU tries to speculatively execute a load instruction
(which is actually along a branch that ends up not being taken) in which
the data crosses a page boundary and causes a fault.

The specific section of code looks like this:

...
ret
ld s1,0(a1)
...

If you're not familiar with RISC-V, ret is a pseudo-instruction that just
jumps to whatever address is stored in the return-address register, and ld
loads a 64-bit value from memory.

The problem I'm encountering is that the value stored in register a1 is not
a valid address as that instruction is not supposed to be executed, and it
just so happens that the word it points to crosses a page boundary.  When
gem5 speculatively executes this, it crashes.

How can I prevent gem5 from doing this?  I know I could flag load and store
instructions as being nonspeculative, but that will slow down execution and
affect output stats.  I'm working on top of these four patches:

   - https://gem5-review.googlesource.com/c/2304/
   - https://gem5-review.googlesource.com/c/2305/5
   - https://gem5-review.googlesource.com/c/2340/2
   - https://gem5-review.googlesource.com/c/2341/2

Thanks,
Alec Roelke
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: riscv: enable unaligned memory accesses

[Alec Roelke (Gerrit)]

Alec Roelke has uploaded this change for review. (  
https://gem5-review.googlesource.com/2341



Change subject: riscv: enable unaligned memory accesses
..

riscv: enable unaligned memory accesses

Sometimes an ld instruction will be split across a
cache boundary.  Previously RISC-V was set to not
allow this.  This patch fixes that.

Change-Id: I8bc8ea6d67f65a9b3662e14c4037f4224799d20f
---
M src/arch/riscv/isa_traits.hh
1 file changed, 2 insertions(+), 2 deletions(-)



diff --git a/src/arch/riscv/isa_traits.hh b/src/arch/riscv/isa_traits.hh
index f7a2c87..327d644 100644
--- a/src/arch/riscv/isa_traits.hh
+++ b/src/arch/riscv/isa_traits.hh
@@ -65,8 +65,8 @@

 const ExtMachInst NoopMachInst = 0x0013;

-// Memory accesses can not be unaligned
-const bool HasUnalignedMemAcc = false;
+// Memory accesses can be unaligned (at least for double-word memory  
accesses)

+const bool HasUnalignedMemAcc = true;

 const bool CurThreadInfoImplemented = false;
 const int CurThreadInfoReg = -1;

--
To view, visit https://gem5-review.googlesource.com/2341
To unsubscribe, visit https://gem5-review.googlesource.com/settings

Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-MessageType: newchange
Gerrit-Change-Id: I8bc8ea6d67f65a9b3662e14c4037f4224799d20f
Gerrit-Change-Number: 2341
Gerrit-PatchSet: 2
Gerrit-Owner: Alec Roelke 
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: riscv: fix compatibility with Linux toolchain

[Alec Roelke (Gerrit)]

Hello Jason Lowe-Power, Brandon Potter,

I'd like you to reexamine a change. Please visit

https://gem5-review.googlesource.com/2305

to look at the new patch set (#5).

Change subject: riscv: fix compatibility with Linux toolchain
..

riscv: fix compatibility with Linux toolchain

Previously, RISC-V in gem5 only supported RISC-V's Newlib toolchain
(riscv64-unknown-elf-*) due to incorrect assumptions made in the initial
setup of the user stack in SE mode.  This patch fixes that by referring
to the RISC-V proxy kernel code (https://github.com/riscv/riscv-pk) and
setting up the stack according to how it does it.  Now binaries compiled
using the Linux toolchain (riscv64-unknown-linux-gnu-*) will run as
well.

[Update for recent changes to MemState to add accessors and mutators to
get its members.]

Change-Id: I6d2c486df7688efe3df54273e9aa0fd686851285
---
M src/arch/riscv/process.cc
M tests/test-progs/insttest/src/riscv/Makefile
2 files changed, 115 insertions(+), 140 deletions(-)




diff --git a/src/arch/riscv/process.cc b/src/arch/riscv/process.cc
index f50fb31..b962372 100644
--- a/src/arch/riscv/process.cc
+++ b/src/arch/riscv/process.cc
@@ -33,6 +33,11 @@
  */
 #include "arch/riscv/process.hh"

+#include 
+#include 
+#include 
+#include 
+#include 
 #include 

 #include "arch/riscv/isa_traits.hh"
@@ -40,8 +45,9 @@
 #include "base/loader/object_file.hh"
 #include "base/misc.hh"
 #include "cpu/thread_context.hh"
-#include "debug/Loader.hh"
+#include "debug/Stack.hh"
 #include "mem/page_table.hh"
+#include "params/Process.hh"
 #include "sim/aux_vector.hh"
 #include "sim/process.hh"
 #include "sim/process_impl.hh"
@@ -54,23 +60,15 @@
 RiscvProcess::RiscvProcess(ProcessParams * params,
 ObjectFile *objFile) : Process(params, objFile)
 {
-// Set up stack. On RISC-V, stack starts at the top of kuseg
-// user address space. RISC-V stack grows down from here
-Addr stack_base = 0x7FFF;
-
-Addr max_stack_size = 8 * 1024 * 1024;
-
-// Set pointer for next thread stack.  Reserve 8M for main stack.
-Addr next_thread_stack_base = stack_base - max_stack_size;
-
-// Set up break point (Top of Heap)
-Addr brk_point = objFile->bssBase() + objFile->bssSize();
-
-// Set up region for mmaps.  Start it 1GB above the top of the heap.
-Addr mmap_end = brk_point + 0x4000L;
-
+const Addr mem_base = 0x8000;
+const Addr stack_base = mem_base;
+const Addr max_stack_size = PageBytes * 64;
+const Addr next_thread_stack_base = stack_base - max_stack_size;
+const Addr brk_point = roundUp(objFile->bssBase() + objFile->bssSize(),
+PageBytes);
+const Addr mmap_end = mem_base;
 memState = make_shared(brk_point, stack_base, max_stack_size,
- next_thread_stack_base, mmap_end);
+next_thread_stack_base, mmap_end);
 }

 void
@@ -85,145 +83,122 @@
 RiscvProcess::argsInit(int pageSize)
 {
 updateBias();
-
-// load object file into target memory
 objFile->loadSections(initVirtMem);
+ElfObject* elfObject = dynamic_cast(objFile);
+memState->setStackMin(memState->getStackBase());

-typedef AuxVector auxv_t;
-vector auxv;
-ElfObject * elfObject = dynamic_cast(objFile);
-if (elfObject) {
-// Set the system page size
-auxv.push_back(auxv_t(M5_AT_PAGESZ, RiscvISA::PageBytes));
-// Set the frequency at which time() increments
-auxv.push_back(auxv_t(M5_AT_CLKTCK, 100));
-// For statically linked executables, this is the virtual
-// address of the program header tables if they appear in the
-// executable image.
-auxv.push_back(auxv_t(M5_AT_PHDR,  
elfObject->programHeaderTable()));

-DPRINTF(Loader, "auxv at PHDR %08p\n",
-elfObject->programHeaderTable());
-// This is the size of a program header entry from the elf file.
-auxv.push_back(auxv_t(M5_AT_PHENT,  
elfObject->programHeaderSize()));
-// This is the number of program headers from the original elf  
file.
-auxv.push_back(auxv_t(M5_AT_PHNUM,  
elfObject->programHeaderCount()));

-auxv.push_back(auxv_t(M5_AT_BASE, getBias()));
-//The entry point to the program
-auxv.push_back(auxv_t(M5_AT_ENTRY, objFile->entryPoint()));
-//Different user and group IDs
-auxv.push_back(auxv_t(M5_AT_UID, uid()));
-auxv.push_back(auxv_t(M5_AT_EUID, euid()));
-auxv.push_back(auxv_t(M5_AT_GID, gid()));
-auxv.push_back(auxv_t(M5_AT_EGID, egid()));
+// Determine stack size and populate auxv
+Addr stack_top = memState->getStackMin();
+for (const string& arg: argv)
+stack_top -= arg.size() + 1;
+for (const string& env: envp)
+stack_top -= env.size() + 1;
+stack_top &= -sizeof(Addr);
+
+vector auxv;
+if (elfObject != nullptr) {
+

[gem5-dev] Change in public/gem5[master]: riscv: fix compatibility with Linux toolchain

[Alec Roelke (Gerrit)]

Hello Jason Lowe-Power, Brandon Potter,

I'd like you to reexamine a change. Please visit

https://gem5-review.googlesource.com/2305

to look at the new patch set (#4).

Change subject: riscv: fix compatibility with Linux toolchain
..

riscv: fix compatibility with Linux toolchain

Previously, RISC-V in gem5 only supported RISC-V's Newlib toolchain
(riscv64-unknown-elf-*) due to incorrect assumptions made in the initial
setup of the user stack in SE mode.  This patch fixes that by referring
to the RISC-V proxy kernel code (https://github.com/riscv/riscv-pk) and
setting up the stack according to how it does it.  Now binaries compiled
using the Linux toolchain (riscv64-unknown-linux-gnu-*) will run as
well.

Change-Id: I6d2c486df7688efe3df54273e9aa0fd686851285
---
M src/arch/riscv/process.cc
M tests/test-progs/insttest/src/riscv/Makefile
2 files changed, 115 insertions(+), 140 deletions(-)




diff --git a/src/arch/riscv/process.cc b/src/arch/riscv/process.cc
index f50fb31..b962372 100644
--- a/src/arch/riscv/process.cc
+++ b/src/arch/riscv/process.cc
@@ -33,6 +33,11 @@
  */
 #include "arch/riscv/process.hh"

+#include 
+#include 
+#include 
+#include 
+#include 
 #include 

 #include "arch/riscv/isa_traits.hh"
@@ -40,8 +45,9 @@
 #include "base/loader/object_file.hh"
 #include "base/misc.hh"
 #include "cpu/thread_context.hh"
-#include "debug/Loader.hh"
+#include "debug/Stack.hh"
 #include "mem/page_table.hh"
+#include "params/Process.hh"
 #include "sim/aux_vector.hh"
 #include "sim/process.hh"
 #include "sim/process_impl.hh"
@@ -54,23 +60,15 @@
 RiscvProcess::RiscvProcess(ProcessParams * params,
 ObjectFile *objFile) : Process(params, objFile)
 {
-// Set up stack. On RISC-V, stack starts at the top of kuseg
-// user address space. RISC-V stack grows down from here
-Addr stack_base = 0x7FFF;
-
-Addr max_stack_size = 8 * 1024 * 1024;
-
-// Set pointer for next thread stack.  Reserve 8M for main stack.
-Addr next_thread_stack_base = stack_base - max_stack_size;
-
-// Set up break point (Top of Heap)
-Addr brk_point = objFile->bssBase() + objFile->bssSize();
-
-// Set up region for mmaps.  Start it 1GB above the top of the heap.
-Addr mmap_end = brk_point + 0x4000L;
-
+const Addr mem_base = 0x8000;
+const Addr stack_base = mem_base;
+const Addr max_stack_size = PageBytes * 64;
+const Addr next_thread_stack_base = stack_base - max_stack_size;
+const Addr brk_point = roundUp(objFile->bssBase() + objFile->bssSize(),
+PageBytes);
+const Addr mmap_end = mem_base;
 memState = make_shared(brk_point, stack_base, max_stack_size,
- next_thread_stack_base, mmap_end);
+next_thread_stack_base, mmap_end);
 }

 void
@@ -85,145 +83,122 @@
 RiscvProcess::argsInit(int pageSize)
 {
 updateBias();
-
-// load object file into target memory
 objFile->loadSections(initVirtMem);
+ElfObject* elfObject = dynamic_cast(objFile);
+memState->setStackMin(memState->getStackBase());

-typedef AuxVector auxv_t;
-vector auxv;
-ElfObject * elfObject = dynamic_cast(objFile);
-if (elfObject) {
-// Set the system page size
-auxv.push_back(auxv_t(M5_AT_PAGESZ, RiscvISA::PageBytes));
-// Set the frequency at which time() increments
-auxv.push_back(auxv_t(M5_AT_CLKTCK, 100));
-// For statically linked executables, this is the virtual
-// address of the program header tables if they appear in the
-// executable image.
-auxv.push_back(auxv_t(M5_AT_PHDR,  
elfObject->programHeaderTable()));

-DPRINTF(Loader, "auxv at PHDR %08p\n",
-elfObject->programHeaderTable());
-// This is the size of a program header entry from the elf file.
-auxv.push_back(auxv_t(M5_AT_PHENT,  
elfObject->programHeaderSize()));
-// This is the number of program headers from the original elf  
file.
-auxv.push_back(auxv_t(M5_AT_PHNUM,  
elfObject->programHeaderCount()));

-auxv.push_back(auxv_t(M5_AT_BASE, getBias()));
-//The entry point to the program
-auxv.push_back(auxv_t(M5_AT_ENTRY, objFile->entryPoint()));
-//Different user and group IDs
-auxv.push_back(auxv_t(M5_AT_UID, uid()));
-auxv.push_back(auxv_t(M5_AT_EUID, euid()));
-auxv.push_back(auxv_t(M5_AT_GID, gid()));
-auxv.push_back(auxv_t(M5_AT_EGID, egid()));
+// Determine stack size and populate auxv
+Addr stack_top = memState->getStackMin();
+for (const string& arg: argv)
+stack_top -= arg.size() + 1;
+for (const string& env: envp)
+stack_top -= env.size() + 1;
+stack_top &= -sizeof(Addr);
+
+vector auxv;
+if (elfObject != nullptr) {
+auxv.push_back({M5_AT_ENTRY, objFile->entryPoint()});
+auxv.push_back({M5_AT_PHNUM, 

[gem5-dev] Change in public/gem5[master]: sim: Implement load_addr_mask auto-calculation

[Andreas Sandberg (Gerrit)]

Hello Curtis Dunham,

I'd like you to reexamine a change. Please visit

https://gem5-review.googlesource.com/2323

to look at the new patch set (#2).

Change subject: sim: Implement load_addr_mask auto-calculation
..

sim: Implement load_addr_mask auto-calculation

Recent Linux kernels for AArch64 have changed their start addresses
but we still want to relocate the kernel to 0x8008 which
required hacking the load_addr_mask in Realview.py to be 0x7ff
from 0xfff to mask off the proper number of MSBs to load the
kernel in the desired location.  To avoid having to make this change
in the future again, we auto-calculate  the load_addr_mask if it is
specified as 0x0 in the System sim-object to find the most restrictive
address mask instead of having the configuration specify it.  If the
configuration does specify the address mask, we use it instead of
auto-calculating.

Change-Id: I18aabb5d09945c6e3e3819c9c8036ea24b6c35cf
Signed-off-by: Geoffrey Blake 
Reviewed-by: Curtis Dunham 
Signed-off-by: Andreas Sandberg 
---
M src/arch/arm/ArmSystem.py
M src/dev/arm/RealView.py
M src/sim/System.py
M src/sim/system.cc
4 files changed, 30 insertions(+), 10 deletions(-)




diff --git a/src/arch/arm/ArmSystem.py b/src/arch/arm/ArmSystem.py
index 9100db0..4020046 100644
--- a/src/arch/arm/ArmSystem.py
+++ b/src/arch/arm/ArmSystem.py
@@ -1,4 +1,4 @@
-# Copyright (c) 2009, 2012-2013, 2015 ARM Limited
+# Copyright (c) 2009, 2012-2013, 2015-2017 ARM Limited
 # All rights reserved.
 #
 # The license below extends only to copyright in the software and shall
@@ -51,7 +51,6 @@
 class ArmSystem(System):
 type = 'ArmSystem'
 cxx_header = "arch/arm/system.hh"
-load_addr_mask = 0x
 multi_proc = Param.Bool(True, "Multiprocessor system?")
 boot_loader = VectorParam.String([],
 "File that contains the boot loader code. Zero or more files may  
be "

@@ -78,7 +77,6 @@
 class GenericArmSystem(ArmSystem):
 type = 'GenericArmSystem'
 cxx_header = "arch/arm/system.hh"
-load_addr_mask = 0x0fff
 machine_type = Param.ArmMachineType('VExpress_EMM',
 "Machine id from http://www.arm.linux.org.uk/developer/machines/;)
 atags_addr = Param.Addr("Address where default atags structure  
should " \

@@ -98,6 +96,10 @@
 type = 'LinuxArmSystem'
 cxx_header = "arch/arm/linux/system.hh"

+# Have Linux systems for ARM auto-calc their load_addr_mask for proper
+# kernel relocation.
+load_addr_mask = 0x0
+
 @classmethod
 def export_methods(cls, code):
 code('''void dumpDmesg();''')
diff --git a/src/dev/arm/RealView.py b/src/dev/arm/RealView.py
index 20112d4..b44cffc 100644
--- a/src/dev/arm/RealView.py
+++ b/src/dev/arm/RealView.py
@@ -360,7 +360,6 @@
 self.nvmem.port = mem_bus.master
 cur_sys.boot_loader = loc('boot.arm')
 cur_sys.atags_addr = 0x100
-cur_sys.load_addr_mask = 0xfff
 cur_sys.load_offset = 0


@@ -673,7 +672,6 @@
 self.nvmem.port = mem_bus.master
 cur_sys.boot_loader = loc('boot_emm.arm')
 cur_sys.atags_addr = 0x800
-cur_sys.load_addr_mask = 0xfff
 cur_sys.load_offset = 0x8000

 # Attach I/O devices that are on chip and also set the appropriate
@@ -784,7 +782,6 @@
 self.nvmem.port = mem_bus.master
 cur_sys.boot_loader = loc('boot_emm.arm64')
 cur_sys.atags_addr = 0x800
-cur_sys.load_addr_mask = 0xfff
 cur_sys.load_offset = 0x8000


@@ -954,5 +951,4 @@
 self.nvmem.port = mem_bus.master
 cur_sys.boot_loader = [ loc('boot_emm.arm64'), loc('boot_emm.arm')  
]

 cur_sys.atags_addr = 0x800
-cur_sys.load_addr_mask = 0xfff
 cur_sys.load_offset = 0x8000
diff --git a/src/sim/System.py b/src/sim/System.py
index e3e42d8..d6c6556 100644
--- a/src/sim/System.py
+++ b/src/sim/System.py
@@ -1,3 +1,15 @@
+# Copyright (c) 2017 ARM Limited
+# All rights reserved.
+#
+# The license below extends only to copyright in the software and shall
+# not be construed as granting a license to any other intellectual
+# property including but not limited to intellectual property relating
+# to a hardware implementation of the functionality of the software
+# licensed hereunder.  You may use the software subject to the license
+# terms below provided that you ensure that this notice is replicated
+# unmodified and in its entirety in all distributions of the software,
+# modified or unmodified, in source code or in binary form.
+#
 # Copyright (c) 2005-2007 The Regents of The University of Michigan
 # Copyright (c) 2011 Regents of the University of California
 # All rights reserved.
@@ -97,8 +109,10 @@
 "whether to address check on kernel (disable for baremetal)")
 readfile = Param.String("", "file to read 

[gem5-dev] Change in public/gem5[master]: dev, arm: Add draining to the GIC model

[Andreas Sandberg (Gerrit)]

Hello Curtis Dunham,

I'd like you to do a code review. Please visit

https://gem5-review.googlesource.com/2331

to review the following change.


Change subject: dev, arm: Add draining to the GIC model
..

dev, arm: Add draining to the GIC model

The GIC model currently adds a delay to interrupts when posting them
to a target CPU. This means that an interrupt signal will be
represented by an event for a short period of time. We currently
ignore this when draining and serialize the tick when the interrupt
will fire. Upon loading the checkpoint, the simulated GIC reschedules
the pending events. This behaviour is undesirable when we implement
support for switching between in-kernel GIC emulation and gem5 GIC
emulation. In that case, the (kernel) GIC model gets a lot simpler if
we don't need to worry about in-flight interrupts from the gem5 GIC.

This changeset adds a draining check to force the GIC into a state
where all interrupts have been delivered prior to checkpointing/CPU
switching. It also removes the now redundant serialization of
interrupt events.

Change-Id: I8b8b080aa291ca029a3a7bdd1777f1fcd5b01179
Signed-off-by: Andreas Sandberg 
Reviewed-by: Curtis Dunham 
---
M src/dev/arm/gic_pl390.cc
M src/dev/arm/gic_pl390.hh
2 files changed, 49 insertions(+), 21 deletions(-)



diff --git a/src/dev/arm/gic_pl390.cc b/src/dev/arm/gic_pl390.cc
index f21d5c5..04c3949 100644
--- a/src/dev/arm/gic_pl390.cc
+++ b/src/dev/arm/gic_pl390.cc
@@ -76,7 +76,8 @@
   cpuSgiPending {}, cpuSgiActive {},
   cpuSgiPendingExt {}, cpuSgiActiveExt {},
   cpuPpiPending {}, cpuPpiActive {},
-  irqEnable(false)
+  irqEnable(false),
+  pendingDelayedInterrupts(0)
 {
 for (int x = 0; x < CPU_MAX; x++) {
 iccrpr[x] = 0xff;
@@ -85,7 +86,7 @@
 cpuBpr[x] = 0;
 // Initialize cpu highest int
 cpuHighestInt[x] = SPURIOUS_INT;
-postIntEvent[x] = new PostIntEvent(x, p->platform);
+postIntEvent[x] = new PostIntEvent(*this, x);
 }
 DPRINTF(Interrupt, "cpuEnabled[0]=%d cpuEnabled[1]=%d\n",  
cpuEnabled[0],

 cpuEnabled[1]);
@@ -812,10 +813,31 @@
 void
 Pl390::postInt(uint32_t cpu, Tick when)
 {
-if (!(postIntEvent[cpu]->scheduled()))
+if (!(postIntEvent[cpu]->scheduled())) {
+++pendingDelayedInterrupts;
 eventq->schedule(postIntEvent[cpu], when);
+}
 }

+void
+Pl390::postDelayedInt(uint32_t cpu)
+{
+platform->intrctrl->post(cpu, ArmISA::INT_IRQ, 0);
+--pendingDelayedInterrupts;
+assert(pendingDelayedInterrupts >= 0);
+if (pendingDelayedInterrupts == 0)
+signalDrainDone();
+}
+
+DrainState
+Pl390::drain()
+{
+if (pendingDelayedInterrupts == 0) {
+return DrainState::Drained;
+} else {
+return DrainState::Draining;
+}
+}

 void
 Pl390::serialize(CheckpointOut ) const
@@ -842,14 +864,6 @@
 SERIALIZE_ARRAY(cpuPpiActive, CPU_MAX);
 SERIALIZE_ARRAY(cpuPpiPending, CPU_MAX);
 SERIALIZE_SCALAR(irqEnable);
-Tick interrupt_time[CPU_MAX];
-for (uint32_t cpu = 0; cpu < CPU_MAX; cpu++) {
-interrupt_time[cpu] = 0;
-if (postIntEvent[cpu]->scheduled()) {
-interrupt_time[cpu] = postIntEvent[cpu]->when();
-}
-}
-SERIALIZE_ARRAY(interrupt_time, CPU_MAX);
 SERIALIZE_SCALAR(gem5ExtensionsEnabled);

 for (uint32_t i=0; i < bankedRegs.size(); ++i) {
@@ -895,13 +909,18 @@
 UNSERIALIZE_ARRAY(cpuPpiPending, CPU_MAX);
 UNSERIALIZE_SCALAR(irqEnable);

-Tick interrupt_time[CPU_MAX];
-UNSERIALIZE_ARRAY(interrupt_time, CPU_MAX);
+// Handle checkpoints from before we drained the GIC to prevent
+// in-flight interrupts.
+if (cp.entryExists(Serializable::currentSection(), "interrupt_time")) {
+Tick interrupt_time[CPU_MAX];
+UNSERIALIZE_ARRAY(interrupt_time, CPU_MAX);

-for (uint32_t cpu = 0; cpu < CPU_MAX; cpu++) {
-if (interrupt_time[cpu])
-schedule(postIntEvent[cpu], interrupt_time[cpu]);
+for (uint32_t cpu = 0; cpu < CPU_MAX; cpu++) {
+if (interrupt_time[cpu])
+schedule(postIntEvent[cpu], interrupt_time[cpu]);
+}
 }
+
 if (!UNSERIALIZE_OPT_SCALAR(gem5ExtensionsEnabled))
 gem5ExtensionsEnabled = false;

diff --git a/src/dev/arm/gic_pl390.hh b/src/dev/arm/gic_pl390.hh
index 533a0f3..6647058 100644
--- a/src/dev/arm/gic_pl390.hh
+++ b/src/dev/arm/gic_pl390.hh
@@ -318,25 +318,32 @@
 int intNumToWord(int num) const { return num >> 5; }
 int intNumToBit(int num) const { return num % 32; }

-/** Post an interrupt to a CPU
+/**
+ * Post an interrupt to a CPU with a delay
  */
 void postInt(uint32_t cpu, Tick when);
+
+/**
+ * Deliver a delayed interrupt to the target CPU
+ */
+void postDelayedInt(uint32_t cpu);

 /** Event definition to post 

[gem5-dev] Change in public/gem5[master]: arm: Clean up the GIC implementation

[Andreas Sandberg (Gerrit)]

Hello Curtis Dunham,

I'd like you to do a code review. Please visit

https://gem5-review.googlesource.com/2330

to review the following change.


Change subject: arm: Clean up the GIC implementation
..

arm: Clean up the GIC implementation

Lots of minor cleaups:
  * Make cached params const
  * Don't serialize params
  * Use AddrRange to represent the distributor and CPU address spaces
  * Store a const AddrRangeList of all PIO ranges

Change-Id: I40a17bc3a38868fb3b8af247790e852cf99ddf1d
Signed-off-by: Andreas Sandberg 
Reviewed-by: Curtis Dunham 
---
M src/dev/arm/gic_pl390.cc
M src/dev/arm/gic_pl390.hh
2 files changed, 41 insertions(+), 69 deletions(-)



diff --git a/src/dev/arm/gic_pl390.cc b/src/dev/arm/gic_pl390.cc
index e7dc8e9..f21d5c5 100644
--- a/src/dev/arm/gic_pl390.cc
+++ b/src/dev/arm/gic_pl390.cc
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2010, 2013, 2015-2016 ARM Limited
+ * Copyright (c) 2010, 2013, 2015-2017 ARM Limited
  * All rights reserved
  *
  * The license below extends only to copyright in the software and shall
@@ -63,8 +63,11 @@
 const AddrRange Pl390::GICD_ICFGR (0xc00, 0xcff);

 Pl390::Pl390(const Params *p)
-: BaseGic(p), distAddr(p->dist_addr),
-  cpuAddr(p->cpu_addr), distPioDelay(p->dist_pio_delay),
+: BaseGic(p),
+  distRange(RangeSize(p->dist_addr, DIST_SIZE)),
+  cpuRange(RangeSize(p->cpu_addr, CPU_SIZE)),
+  addrRanges{distRange, cpuRange},
+  distPioDelay(p->dist_pio_delay),
   cpuPioDelay(p->cpu_pio_delay), intLatency(p->int_latency),
   enabled(false), haveGem5Extensions(p->gem5_extensions),
   itLines(p->it_lines),
@@ -93,12 +96,11 @@
 Tick
 Pl390::read(PacketPtr pkt)
 {
+const Addr addr = pkt->getAddr();

-Addr addr = pkt->getAddr();
-
-if (addr >= distAddr && addr < distAddr + DIST_SIZE)
+if (distRange.contains(addr))
 return readDistributor(pkt);
-else if (addr >= cpuAddr && addr < cpuAddr + CPU_SIZE)
+else if (cpuRange.contains(addr))
 return readCpu(pkt);
 else
 panic("Read to unknown address %#x\n", pkt->getAddr());
@@ -108,12 +110,11 @@
 Tick
 Pl390::write(PacketPtr pkt)
 {
+const Addr addr = pkt->getAddr();

-Addr addr = pkt->getAddr();
-
-if (addr >= distAddr && addr < distAddr + DIST_SIZE)
+if (distRange.contains(addr))
 return writeDistributor(pkt);
-else if (addr >= cpuAddr && addr < cpuAddr + CPU_SIZE)
+else if (cpuRange.contains(addr))
 return writeCpu(pkt);
 else
 panic("Write to unknown address %#x\n", pkt->getAddr());
@@ -122,9 +123,8 @@
 Tick
 Pl390::readDistributor(PacketPtr pkt)
 {
-Addr daddr = pkt->getAddr() - distAddr;
-
-ContextID ctx = pkt->req->contextId();
+const Addr daddr = pkt->getAddr() - distRange.start();
+const ContextID ctx = pkt->req->contextId();

 DPRINTF(GIC, "gic distributor read register %#x\n", daddr);

@@ -267,10 +267,10 @@
 Tick
 Pl390::readCpu(PacketPtr pkt)
 {
-Addr daddr = pkt->getAddr() - cpuAddr;
+const Addr daddr = pkt->getAddr() - cpuRange.start();

 assert(pkt->req->hasContextId());
-ContextID ctx = pkt->req->contextId();
+const ContextID ctx = pkt->req->contextId();
 assert(ctx < sys->numRunningContexts());

 DPRINTF(GIC, "gic cpu read register %#x cpu context: %d\n", daddr,
@@ -361,10 +361,10 @@
 Tick
 Pl390::writeDistributor(PacketPtr pkt)
 {
-Addr daddr = pkt->getAddr() - distAddr;
+const Addr daddr = pkt->getAddr() - distRange.start();

 assert(pkt->req->hasContextId());
-ContextID ctx = pkt->req->contextId();
+const ContextID ctx = pkt->req->contextId();

 uint32_t pkt_data M5_VAR_USED;
 switch (pkt->getSize())
@@ -520,10 +520,10 @@
 Tick
 Pl390::writeCpu(PacketPtr pkt)
 {
-Addr daddr = pkt->getAddr() - cpuAddr;
+const Addr daddr = pkt->getAddr() - cpuRange.start();

 assert(pkt->req->hasContextId());
-ContextID ctx = pkt->req->contextId();
+const ContextID ctx = pkt->req->contextId();
 IAR iar;

 DPRINTF(GIC, "gic cpu write register cpu:%d %#x val: %#x\n",
@@ -816,25 +816,12 @@
 eventq->schedule(postIntEvent[cpu], when);
 }

-AddrRangeList
-Pl390::getAddrRanges() const
-{
-AddrRangeList ranges;
-ranges.push_back(RangeSize(distAddr, DIST_SIZE));
-ranges.push_back(RangeSize(cpuAddr, CPU_SIZE));
-return ranges;
-}
-

 void
 Pl390::serialize(CheckpointOut ) const
 {
 DPRINTF(Checkpoint, "Serializing Arm GIC\n");

-SERIALIZE_SCALAR(distAddr);
-SERIALIZE_SCALAR(cpuAddr);
-SERIALIZE_SCALAR(distPioDelay);
-SERIALIZE_SCALAR(cpuPioDelay);
 SERIALIZE_SCALAR(enabled);
 SERIALIZE_SCALAR(itLines);
 SERIALIZE_ARRAY(intEnabled, INT_BITS_MAX-1);
@@ -887,10 +874,6 @@
 {
 DPRINTF(Checkpoint, "Unserializing Arm GIC\n");

-UNSERIALIZE_SCALAR(distAddr);
-UNSERIALIZE_SCALAR(cpuAddr);
-

[gem5-dev] Change in public/gem5[master]: util: Add a tool to list outgoing/incoming changes

[Andreas Sandberg (Gerrit)]

Andreas Sandberg has uploaded this change for review. (  
https://gem5-review.googlesource.com/2329



Change subject: util: Add a tool to list outgoing/incoming changes
..

util: Add a tool to list outgoing/incoming changes

Add a small Python script that uses Gerrit's Change-Id: tags to list
incoming and outgoing changes.

Change-Id: Iea1757b2d64a57a4c7b4e47718cfcaa725a99615
Signed-off-by: Andreas Sandberg 
Reviewed-by: Sascha Bischoff 
---
A util/maint/list_changes.py
1 file changed, 206 insertions(+), 0 deletions(-)



diff --git a/util/maint/list_changes.py b/util/maint/list_changes.py
new file mode 100755
index 000..5cbcf59
--- /dev/null
+++ b/util/maint/list_changes.py
@@ -0,0 +1,206 @@
+#!/usr/bin/env python2
+#
+# Copyright (c) 2017 ARM Limited
+# All rights reserved
+#
+# The license below extends only to copyright in the software and shall
+# not be construed as granting a license to any other intellectual
+# property including but not limited to intellectual property relating
+# to a hardware implementation of the functionality of the software
+# licensed hereunder.  You may use the software subject to the license
+# terms below provided that you ensure that this notice is replicated
+# unmodified and in its entirety in all distributions of the software,
+# modified or unmodified, in source code or in binary form.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are
+# met: redistributions of source code must retain the above copyright
+# notice, this list of conditions and the following disclaimer;
+# redistributions in binary form must reproduce the above copyright
+# notice, this list of conditions and the following disclaimer in the
+# documentation and/or other materials provided with the distribution;
+# neither the name of the copyright holders nor the names of its
+# contributors may be used to endorse or promote products derived from
+# this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+#
+# Authors: Andreas Sandberg
+
+
+import subprocess
+import re
+from functools import wraps
+
+class Commit(object):
+_re_tag = re.compile(r"^((?:\w|-)+): (.*)$")
+
+def __init__(self, rev):
+self.rev = rev
+self._log = None
+self._tags = None
+
+def _git(self, args):
+return subprocess.check_output([ "git", ] + args)
+
+@property
+def log(self):
+"""Log message belonging to a commit returned as a list with on  
line

+per element.
+
+"""
+if self._log is None:
+self._log = self._git(
+["show", "--format=%B", "--no-patch", str(self.rev) ]
+).rstrip("\n").split("\n")
+return self._log
+
+@property
+def tags(self):
+"""Get all commit message tags in the current commit.
+
+Returns: { tag, [ value, ... ] }
+
+"""
+if self._tags is None:
+tags = {}
+for l in self.log[1:]:
+m = Commit._re_tag.match(l)
+if m:
+key, value = m.group(1), m.group(2)
+try:
+tags[key].append(value)
+except KeyError:
+tags[key] = [ value ]
+self._tags = tags
+
+return self._tags
+
+@property
+def change_id(self):
+"""Get the Change-Id tag from the commit
+
+Returns: A change ID or None if no change ID has been
+specified.
+
+"""
+try:
+cids = self.tags["Change-Id"]
+except KeyError:
+return None
+
+assert len(cids) == 1
+return cids[0]
+
+def __str__(self):
+return "%s: %s" % (self.rev[0:8], self.log[0])
+
+def list_revs(upstream, branch):
+"""Get a generator that lists git revisions that exist in 'branch' but
+not in 'upstream'.
+
+Returns: Generator of Commit objects
+
+"""
+
+changes = subprocess.check_output(
+[ "git", "rev-list", "%s..%s" % 

[gem5-dev] Cron <m5test@zizzer> /z/m5/regression/do-regression quick

[Cron Daemon]

* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing: 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!
*** diff[simout]: SKIPPED* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-simple:
 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/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/03.learning-gem5/sparc/linux/learning-gem5-p1-two-level:
 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/40.m5threads-test-atomic/sparc/linux/simple-timing-mp:
 CHANGED!
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp:
 CHANGED!
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-timing: 
CHANGED!
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/o3-timing: CHANGED!
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-atomic: 
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!
* build/SPARC/tests/opt/quick/se/50.vortex/sparc/linux/simple-atomic: 
CHANGED!
* build/SPARC/tests/opt/quick/se/70.twolf/sparc/linux/simple-atomic: 
CHANGED!
* build/SPARC/tests/opt/quick/se/10.mcf/sparc/linux/simple-atomic: CHANGED!
* build/SPARC/tests/opt/quick/se/50.vortex/sparc/linux/simple-timing: 
CHANGED!
* build/SPARC/tests/opt/quick/se/70.twolf/sparc/linux/simple-timing: 
CHANGED!
* build/X86/tests/opt/quick/se/00.hello/x86/linux/o3-timing: CHANGED!
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-atomic: CHANGED!
* 
build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-simple:
 CHANGED!
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing: CHANGED!
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing-ruby: 
CHANGED!
* 
build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-two-level:
 CHANGED!
* build/X86/tests/opt/quick/se/70.twolf/x86/linux/simple-atomic: CHANGED!
* build/X86/tests/opt/quick/se/10.mcf/x86/linux/simple-atomic: CHANGED!
* 
build/ARM/tests/opt/quick/se/03.learning-gem5/arm/linux/learning-gem5-p1-two-level:
 CHANGED!
* 
build/ARM/tests/opt/quick/se/03.learning-gem5/arm/linux/learning-gem5-p1-simple:
 CHANGED!
* 
build/ARM/tests/opt/quick/se/00.hello/arm/linux/simple-atomic-dummychecker: 
CHANGED!
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/o3-timing-checker: 
CHANGED!
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/simple-timing: CHANGED!
* build/X86/tests/opt/quick/se/70.twolf/x86/linux/simple-timing: CHANGED!
* build/ARM/tests/opt/quick/se/50.vortex/arm/linux/simple-atomic: CHANGED!
* build/ARM/tests/opt/quick/se/50.vortex/arm/linux/simple-timing: CHANGED!
* build/ARM/tests/opt/quick/se/10.mcf/arm/linux/simple-timing: CHANGED!
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/o3-timing: CHANGED!
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/minor-timing: CHANGED!
* build/ARM/tests/opt/quick/se/10.mcf/arm/linux/simple-atomic: CHANGED!
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/simple-atomic: CHANGED!
* build/ARM/tests/opt/quick/se/70.twolf/arm/linux/simple-timing: CHANGED!
* build/ARM/tests/opt/quick/se/70.twolf/arm/linux/simple-atomic: CHANGED!
* 
build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-timing-dual:
 CHANGED!
* 
build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-timing: 
CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64a/simple-timing-ruby:
 CHANGED!
* build/RISCV/tests/opt/quick/se/00.hello/riscv/linux/minor-timing: CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64a/minor-timing: 
CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64m/simple-atomic: 
CHANGED!
* build/RISCV/tests/opt/quick/se/00.hello/riscv/linux/simple-atomic: 
CHANGED!
* build/RISCV/tests/opt/quick/se/00.hello/riscv/linux/o3-timing: CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64f/simple-atomic: 
CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64f/simple-timing: 
CHANGED!
* 

[gem5-dev] Change in public/gem5[master]: misc: add copyright/name information for contribution

[Pierre-Yves Péneau (Gerrit)]

Pierre-Yves Péneau has uploaded this change for review. (  
https://gem5-review.googlesource.com/2328



Change subject: misc: add copyright/name information for contribution
..

misc: add copyright/name information for contribution

Change-Id: I9242ce50b86b02ec1880d411627da11265cb8961
---
M CONTRIBUTING.md
1 file changed, 3 insertions(+), 0 deletions(-)



diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8e82798..ecaafb3 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -186,6 +186,9 @@
 It is imperative that you use your real name and your real email address in
 both tags and in the author field of the changeset.

+For significant changes, authors are encouraged to add copyright  
information

+and their names at the beginning of the file.
+
 Note: If you do not follow these guidelines, the gerrit review site will
 automatically reject your patch.
 If this happens, update your changeset descriptions to match the required  
style


--
To view, visit https://gem5-review.googlesource.com/2328
To unsubscribe, visit https://gem5-review.googlesource.com/settings

Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-MessageType: newchange
Gerrit-Change-Id: I9242ce50b86b02ec1880d411627da11265cb8961
Gerrit-Change-Number: 2328
Gerrit-PatchSet: 1
Gerrit-Owner: Pierre-Yves Péneau 
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] More problems in SE land

[Andreas Hansson]

Great. Thanks Brandon.

Just shout if you need any help testing it out.

Andreas

From: "Potter, Brandon" >
Date: Friday, 10 March 2017 at 08:31
To: Andreas Hansson >, 
gem5 Developer List >
Subject: RE: More problems in SE land

I will post a patch to fix the compilation problem in the next few days.

-Brandon

From: Andreas Hansson [mailto:andreas.hans...@arm.com]
Sent: Friday, March 10, 2017 2:29 AM
To: gem5 Developer List >
Cc: Potter, Brandon >
Subject: Re: More problems in SE land

Merely a reminder that this is still broken.

Andreas

From: Andreas Hansson >
Date: Tuesday, 7 March 2017 at 08:54
To: gem5 Developer List >
Subject: More problems in SE land

Hi all (and Brandon in particular),

More problems in SE land I’m afraid. The following changeset prevents gem5 from 
building on macOS:

commit 2367198921765848a4f5b3d020a7cc5776209f80
Author: Brandon Potter >
Date:   Mon Feb 27 14:10:15 2017 -0500

syscall_emul: [PATCH 15/22] add clone/execve for threading and multiprocess 
simulations

Modifies the clone system call and adds execve system call. Requires 
allowing
processes to steal thread contexts from other processes in the same system
object and the ability to detach pieces of process state (such as MemState)
to allow dynamic sharing.

The result is the following:

build/ARM/sim/process.cc:157:9: error: use of undeclared identifier 'CLONE_VM'
if (CLONE_VM & flags) {
^
build/ARM/sim/process.cc:187:9: error: use of undeclared identifier
  'CLONE_FILES'
if (CLONE_FILES & flags) {
^
build/ARM/sim/process.cc:227:9: error: use of undeclared identifier
  'CLONE_THREAD'
if (CLONE_THREAD & flags) {
^
3 errors generated.

I am inclined to suggest we create a linux_process.cc or similar for all the 
sys calls that are only available on Linux (to avoid ifdef’s all over the 
place).

Andreas

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.
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

Re: [gem5-dev] More problems in SE land

[Potter, Brandon]

I will post a patch to fix the compilation problem in the next few days.

-Brandon

From: Andreas Hansson [mailto:andreas.hans...@arm.com]
Sent: Friday, March 10, 2017 2:29 AM
To: gem5 Developer List 
Cc: Potter, Brandon 
Subject: Re: More problems in SE land

Merely a reminder that this is still broken.

Andreas

From: Andreas Hansson >
Date: Tuesday, 7 March 2017 at 08:54
To: gem5 Developer List >
Subject: More problems in SE land

Hi all (and Brandon in particular),

More problems in SE land I’m afraid. The following changeset prevents gem5 from 
building on macOS:

commit 2367198921765848a4f5b3d020a7cc5776209f80
Author: Brandon Potter >
Date:   Mon Feb 27 14:10:15 2017 -0500

syscall_emul: [PATCH 15/22] add clone/execve for threading and multiprocess 
simulations

Modifies the clone system call and adds execve system call. Requires 
allowing
processes to steal thread contexts from other processes in the same system
object and the ability to detach pieces of process state (such as MemState)
to allow dynamic sharing.

The result is the following:

build/ARM/sim/process.cc:157:9: error: use of undeclared identifier 'CLONE_VM'
if (CLONE_VM & flags) {
^
build/ARM/sim/process.cc:187:9: error: use of undeclared identifier
  'CLONE_FILES'
if (CLONE_FILES & flags) {
^
build/ARM/sim/process.cc:227:9: error: use of undeclared identifier
  'CLONE_THREAD'
if (CLONE_THREAD & flags) {
^
3 errors generated.

I am inclined to suggest we create a linux_process.cc or similar for all the 
sys calls that are only available on Linux (to avoid ifdef’s all over the 
place).

Andreas

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

Re: [gem5-dev] More problems in SE land

[Andreas Hansson]

Merely a reminder that this is still broken.

Andreas

From: Andreas Hansson >
Date: Tuesday, 7 March 2017 at 08:54
To: gem5 Developer List >
Subject: More problems in SE land

Hi all (and Brandon in particular),

More problems in SE land I’m afraid. The following changeset prevents gem5 from 
building on macOS:

commit 2367198921765848a4f5b3d020a7cc5776209f80
Author: Brandon Potter >
Date:   Mon Feb 27 14:10:15 2017 -0500

syscall_emul: [PATCH 15/22] add clone/execve for threading and multiprocess 
simulations

Modifies the clone system call and adds execve system call. Requires 
allowing
processes to steal thread contexts from other processes in the same system
object and the ability to detach pieces of process state (such as MemState)
to allow dynamic sharing.

The result is the following:

build/ARM/sim/process.cc:157:9: error: use of undeclared identifier 'CLONE_VM'
if (CLONE_VM & flags) {
^
build/ARM/sim/process.cc:187:9: error: use of undeclared identifier
  'CLONE_FILES'
if (CLONE_FILES & flags) {
^
build/ARM/sim/process.cc:227:9: error: use of undeclared identifier
  'CLONE_THREAD'
if (CLONE_THREAD & flags) {
^
3 errors generated.

I am inclined to suggest we create a linux_process.cc or similar for all the 
sys calls that are only available on Linux (to avoid ifdef’s all over the 
place).

Andreas

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