Re: [gem5-dev] Review Request 3793: x86: Fix implicit stack addressing in 64-bit mode

[Sanchayan Maity]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3793/#review9345
---

Ship it!


Ship It!

- Sanchayan Maity


On Jan. 28, 2017, 4:29 a.m., Jason Lowe-Power wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3793/
> ---
> 
> (Updated Jan. 28, 2017, 4:29 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> x86: Fix implicit stack addressing in 64-bit mode
> 
> When in 64-bit mode, if the stack is accessed implicitly by an instruction,
> the alternate address prefix should be ignored if present.
> 
> This patch adds an extra flag to the ldstop which signifies when the
> address override should be ignored. Then, for all of the affected
> instructions, this patch adds two options to the ld and st opcode to
> use the current stack addressing mode for all addresses and to ignore the
> AddressSizeFlagBit.
> Finally, this patch updates the x86 TLB to not truncate the address if it
> is in 64-bit mode and the IgnoreAddrSizeFlagBit is set.
> 
> This fixes a problem when calling __libc_start_main with a binary that
> is linked with a recent version of ld. This version of ld uses the
> address override prefix (0x67) on the call instruction instead of a nop.
> 
> Note: This has not been tested in compatibility mode and only the call
> instruction with the address override prefix has been tested.
> 
> See [1] page 9 (pdf page 45)
> 
> For instructions that are affected see [1] page 519 (pdf page 555).
> 
> [1] http://support.amd.com/TechDocs/24594.pdf
> 
> 
> Diffs
> -
> 
>   src/arch/x86/isa/insts/general_purpose/control_transfer/call.py 
> cd7f3a1dbf55 
>   src/arch/x86/isa/insts/general_purpose/data_transfer/stack_operations.py 
> cd7f3a1dbf55 
>   src/arch/x86/isa/microops/ldstop.isa cd7f3a1dbf55 
> 
> Diff: http://reviews.gem5.org/r/3793/diff/
> 
> 
> Testing
> ---
> 
> Runs "hello" compiled with gcc version "gcc (GCC) 6.3.1 20170109". Also runs 
> hello compiled with earlier gcc in test-progs, and hello32 from test-progs.
> Currently testing Linux boot.
> 
> Testing done on arch docker image. See 
> https://hub.docker.com/r/powerjg/arch-dev/.
> Run "docker run -v `pwd`:/gem5/ -it powerjg/arch-dev /bin/bash" to 
> build/run/test gem5.
> 
> 
> Thanks,
> 
> Jason Lowe-Power
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3793: x86: Fix implicit stack addressing in 64-bit mode

[Jason Lowe-Power]

> On Jan. 27, 2017, 10:37 p.m., Steve Reinhardt wrote:
> > Nice! I suggest somewhat more obvious mnemonics (e.g., ld_stack/st_stack, 
> > if '_' is allowed), and just a couple more comments, but that's all 
> > optional. Feel free to submit w/o reposting on my account.

Might as well do it right while I'm knee-deep in this code.


- Jason


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3793/#review9342
---


On Jan. 27, 2017, 10:59 p.m., Jason Lowe-Power wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3793/
> ---
> 
> (Updated Jan. 27, 2017, 10:59 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> x86: Fix implicit stack addressing in 64-bit mode
> 
> When in 64-bit mode, if the stack is accessed implicitly by an instruction,
> the alternate address prefix should be ignored if present.
> 
> This patch adds an extra flag to the ldstop which signifies when the
> address override should be ignored. Then, for all of the affected
> instructions, this patch adds two options to the ld and st opcode to
> use the current stack addressing mode for all addresses and to ignore the
> AddressSizeFlagBit.
> Finally, this patch updates the x86 TLB to not truncate the address if it
> is in 64-bit mode and the IgnoreAddrSizeFlagBit is set.
> 
> This fixes a problem when calling __libc_start_main with a binary that
> is linked with a recent version of ld. This version of ld uses the
> address override prefix (0x67) on the call instruction instead of a nop.
> 
> Note: This has not been tested in compatibility mode and only the call
> instruction with the address override prefix has been tested.
> 
> See [1] page 9 (pdf page 45)
> 
> For instructions that are affected see [1] page 519 (pdf page 555).
> 
> [1] http://support.amd.com/TechDocs/24594.pdf
> 
> 
> Diffs
> -
> 
>   src/arch/x86/isa/insts/general_purpose/control_transfer/call.py 
> cd7f3a1dbf55 
>   src/arch/x86/isa/insts/general_purpose/data_transfer/stack_operations.py 
> cd7f3a1dbf55 
>   src/arch/x86/isa/microops/ldstop.isa cd7f3a1dbf55 
> 
> Diff: http://reviews.gem5.org/r/3793/diff/
> 
> 
> Testing
> ---
> 
> Runs "hello" compiled with gcc version "gcc (GCC) 6.3.1 20170109". Also runs 
> hello compiled with earlier gcc in test-progs, and hello32 from test-progs.
> Currently testing Linux boot.
> 
> Testing done on arch docker image. See 
> https://hub.docker.com/r/powerjg/arch-dev/.
> Run "docker run -v `pwd`:/gem5/ -it powerjg/arch-dev /bin/bash" to 
> build/run/test gem5.
> 
> 
> Thanks,
> 
> Jason Lowe-Power
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3793: x86: Fix implicit stack addressing in 64-bit mode

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3793/
---

(Updated Jan. 27, 2017, 10:59 p.m.)


Review request for Default.


Repository: gem5


Description
---

x86: Fix implicit stack addressing in 64-bit mode

When in 64-bit mode, if the stack is accessed implicitly by an instruction,
the alternate address prefix should be ignored if present.

This patch adds an extra flag to the ldstop which signifies when the
address override should be ignored. Then, for all of the affected
instructions, this patch adds two options to the ld and st opcode to
use the current stack addressing mode for all addresses and to ignore the
AddressSizeFlagBit.
Finally, this patch updates the x86 TLB to not truncate the address if it
is in 64-bit mode and the IgnoreAddrSizeFlagBit is set.

This fixes a problem when calling __libc_start_main with a binary that
is linked with a recent version of ld. This version of ld uses the
address override prefix (0x67) on the call instruction instead of a nop.

Note: This has not been tested in compatibility mode and only the call
instruction with the address override prefix has been tested.

See [1] page 9 (pdf page 45)

For instructions that are affected see [1] page 519 (pdf page 555).

[1] http://support.amd.com/TechDocs/24594.pdf


Diffs (updated)
-

  src/arch/x86/isa/insts/general_purpose/control_transfer/call.py cd7f3a1dbf55 
  src/arch/x86/isa/insts/general_purpose/data_transfer/stack_operations.py 
cd7f3a1dbf55 
  src/arch/x86/isa/microops/ldstop.isa cd7f3a1dbf55 

Diff: http://reviews.gem5.org/r/3793/diff/


Testing
---

Runs "hello" compiled with gcc version "gcc (GCC) 6.3.1 20170109". Also runs 
hello compiled with earlier gcc in test-progs, and hello32 from test-progs.
Currently testing Linux boot.

Testing done on arch docker image. See 
https://hub.docker.com/r/powerjg/arch-dev/.
Run "docker run -v `pwd`:/gem5/ -it powerjg/arch-dev /bin/bash" to 
build/run/test gem5.


Thanks,

Jason Lowe-Power

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Ideas for sprint projects

[Jason Lowe-Power]

I honestly don't know much about bazel. I heard that it has or is going to
have tightly integrated support for testing and continuous integration. I
only brought it up to start a conversation :). Given that bazel isn't going
to be out of beta until at least Q4 2017, it's likely that we should stick
with something more stable for the time being. (
https://bazel.build/roadmap.html) The main reason I bring it up is that I'd
hate for someone to spend a month re-writing our build system for cmake,
only to have to re-write it again for the next "best" build system in a few
years.

Cheers,
Jason

On Fri, Jan 27, 2017 at 4:07 PM Cagdas Dirik (cdirik) 
wrote:

> Thank you for putting them together Jason!
>
> One quick question - regarding "replacing scons...". Is there a specific
> reason for stepping over cmake and jumping to bazel? It feels to me
> "replacing scons with cmake" will be more beneficial (assuming cmake is
> more common for gem5 developers than bazel).
>
> Cagdas
>
> -Original Message-
> From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jason
> Lowe-Power
> Sent: Thursday, January 26, 2017 12:41 PM
> To: gem5 Developer List 
> Subject: Re: [gem5-dev] Ideas for sprint projects
>
> Thanks everyone who came up with some ideas!
>
> I've compiled them on this page on the wiki: http://gem5.org/Sprint_Ideas.
> Feel free to edit or add more ideas. I tried to expand on each idea with a
> few sentences, but I didn't get to all of them. I also included the person
> who suggested the idea with it.
>
> Cheers,
> Jason
>
> On Wed, Jan 25, 2017 at 12:02 PM Andreas Hansson 
> wrote:
>
> > Hi all,
> >
> > A large-sized project for some crafty person out there: A
> > binary-translation CPU for fast-forwarding, much like the KVMCpu, but
> > more portable. It could, for example, be built on top of the Tiny Code
> > Generator (TCG), as it is BSD licensed.
> >
> > Quite a big task, but also a very big contribution to gem5.
> >
> > Andreas
> >
> > On 23/01/2017, 16:57, "gem5-dev on behalf of Andreas Hansson"
> >  wrote:
> >
> > >Hi all,
> > >
> > >Another medium-sized idea: Embed the generated system SVG in a web
> > >page that can be used to interactively navigate the simulation
> > >results
> > >
> > >This should be fairly easy for anyone skilled in client-side
> > >scripting. It may even be used to view incremental results while the
> > >simulation is running.
> > >
> > >Andreas
> > >
> > >On 23/01/2017, 15:57, "gem5-dev on behalf of Andreas Sandberg"
> > >
> wrote:
> > >
> > >>Hi Everyone,
> > >>
> > >>Thanks for organising this! See below for some of my ideas.
> > >>
> > >>Small projects:
> > >>   * Clean up serialization code for better code reuse (particularly
> > >>container helpers)
> > >>   * Create a separate test classification for CI smoke tests
> > >>(faster than quick)
> > >>
> > >>Medium-sized projects:
> > >>   * New test binaries based on the LLVM test suite
> > >>   * Mini-DSL for param overrides from the command line
> > >>   * Config cleanups. E.g., move some of config/common/ to a
> > >>m5.config name space.
> > >>   * Proper support for pthreads in SE mode
> > >>   * Implement a fast mode in the HDLCD controller to support
> > >>graphical worklaods (e.g., Android) in KVM
> > >>
> > >>Large projects:
> > >>   * Get scons to build basic components only once and share them
> > >>between architectures
> > >>
> > >>
> > >>I'd like to throw cmake in to the build system mix as well. I
> > >>started hacking on a small prototype a while back, but it isn't able
> > >>to build
> > >>gem5 yet.
> > >>
> > >>
> > >>Cheers,
> > >>Andreas
> > >>
> > >>
> > >>On 17/01/17 16:12, Jason Lowe-Power wrote:
> > >>> Hi gem5 Developers!
> > >>>
> > >>> As you're probably aware, I'm going to be running a gem5 coding
> > >>>sprint in  the afternoon after the Learning gem5 tutorial at HPCA
> > >>>on Sunday Feb 5.
> > >>>
> > >>> I'm looking for ideas for small projects that could be started (or
> > >>>even  better, completed) in a few hours. Do you have any small bugs
> > >>>that have  been bothering you? Any little features that would be
> > >>>nice, but you haven't  had the time to work on? Now's the time to
> > >>>get these things done!
> > >>>
> > >>> Also, if you have any bigger projects that you think it would be
> > >>>good for  people to chat about in the same room to come up with a
> > >>>plan of attack, we  may be able to fit one or two of those in, too.
> > >>>
> > >>> Some examples that I have so far:
> > >>>
> > >>> Little projects:
> > >>> 1. Fix TLB warmup for x86. (See http://reviews.gem5.org/r/3474/)
> > >>> 2. Modify EventWrapper to understand C++11 lambdas so you can pass
> > >>> parameters to simple process() functions without creating a new
> class.
> > >>> 3. Develop some ISA instruction tests to 

Re: [gem5-dev] Review Request 3793: x86: Fix implicit stack addressing in 64-bit mode

[Steve Reinhardt]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3793/#review9342
---

Ship it!


Nice! I suggest somewhat more obvious mnemonics (e.g., ld_stack/st_stack, if 
'_' is allowed), and just a couple more comments, but that's all optional. Feel 
free to submit w/o reposting on my account.


src/arch/x86/isa/microops/ldstop.isa (line 501)


could use a comment here



src/arch/x86/isa/microops/ldstop.isa (line 644)


comment here too


- Steve Reinhardt


On Jan. 27, 2017, 9:40 a.m., Jason Lowe-Power wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3793/
> ---
> 
> (Updated Jan. 27, 2017, 9:40 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> x86: Fix implicit stack addressing in 64-bit mode
> 
> When in 64-bit mode, if the stack is accessed implicitly by an instruction,
> the alternate address prefix should be ignored if present.
> 
> This patch adds an extra flag to the ldstop which signifies when the
> address override should be ignored. Then, for all of the affected
> instructions, this patch adds two options to the ld and st opcode to
> use the current stack addressing mode for all addresses and to ignore the
> AddressSizeFlagBit.
> Finally, this patch updates the x86 TLB to not truncate the address if it
> is in 64-bit mode and the IgnoreAddrSizeFlagBit is set.
> 
> This fixes a problem when calling __libc_start_main with a binary that
> is linked with a recent version of ld. This version of ld uses the
> address override prefix (0x67) on the call instruction instead of a nop.
> 
> Note: This has not been tested in compatibility mode and only the call
> instruction with the address override prefix has been tested.
> 
> See [1] page 9 (pdf page 45)
> 
> For instructions that are affected see [1] page 519 (pdf page 555).
> 
> [1] http://support.amd.com/TechDocs/24594.pdf
> 
> 
> Diffs
> -
> 
>   src/arch/x86/isa/insts/general_purpose/control_transfer/call.py 
> cd7f3a1dbf55 
>   src/arch/x86/isa/insts/general_purpose/data_transfer/stack_operations.py 
> cd7f3a1dbf55 
>   src/arch/x86/isa/microops/ldstop.isa cd7f3a1dbf55 
> 
> Diff: http://reviews.gem5.org/r/3793/diff/
> 
> 
> Testing
> ---
> 
> Runs "hello" compiled with gcc version "gcc (GCC) 6.3.1 20170109". Also runs 
> hello compiled with earlier gcc in test-progs, and hello32 from test-progs.
> Currently testing Linux boot.
> 
> Testing done on arch docker image. See 
> https://hub.docker.com/r/powerjg/arch-dev/.
> Run "docker run -v `pwd`:/gem5/ -it powerjg/arch-dev /bin/bash" to 
> build/run/test gem5.
> 
> 
> Thanks,
> 
> Jason Lowe-Power
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Ideas for sprint projects

[Cagdas Dirik (cdirik)]

Thank you for putting them together Jason!

One quick question - regarding "replacing scons...". Is there a specific reason 
for stepping over cmake and jumping to bazel? It feels to me "replacing scons 
with cmake" will be more beneficial (assuming cmake is more common for gem5 
developers than bazel).

Cagdas 

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jason Lowe-Power
Sent: Thursday, January 26, 2017 12:41 PM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Ideas for sprint projects

Thanks everyone who came up with some ideas!

I've compiled them on this page on the wiki: http://gem5.org/Sprint_Ideas.
Feel free to edit or add more ideas. I tried to expand on each idea with a few 
sentences, but I didn't get to all of them. I also included the person who 
suggested the idea with it.

Cheers,
Jason

On Wed, Jan 25, 2017 at 12:02 PM Andreas Hansson 
wrote:

> Hi all,
>
> A large-sized project for some crafty person out there: A 
> binary-translation CPU for fast-forwarding, much like the KVMCpu, but 
> more portable. It could, for example, be built on top of the Tiny Code 
> Generator (TCG), as it is BSD licensed.
>
> Quite a big task, but also a very big contribution to gem5.
>
> Andreas
>
> On 23/01/2017, 16:57, "gem5-dev on behalf of Andreas Hansson"
>  wrote:
>
> >Hi all,
> >
> >Another medium-sized idea: Embed the generated system SVG in a web 
> >page that can be used to interactively navigate the simulation 
> >results
> >
> >This should be fairly easy for anyone skilled in client-side 
> >scripting. It may even be used to view incremental results while the 
> >simulation is running.
> >
> >Andreas
> >
> >On 23/01/2017, 15:57, "gem5-dev on behalf of Andreas Sandberg"
> > wrote:
> >
> >>Hi Everyone,
> >>
> >>Thanks for organising this! See below for some of my ideas.
> >>
> >>Small projects:
> >>   * Clean up serialization code for better code reuse (particularly 
> >>container helpers)
> >>   * Create a separate test classification for CI smoke tests 
> >>(faster than quick)
> >>
> >>Medium-sized projects:
> >>   * New test binaries based on the LLVM test suite
> >>   * Mini-DSL for param overrides from the command line
> >>   * Config cleanups. E.g., move some of config/common/ to a 
> >>m5.config name space.
> >>   * Proper support for pthreads in SE mode
> >>   * Implement a fast mode in the HDLCD controller to support 
> >>graphical worklaods (e.g., Android) in KVM
> >>
> >>Large projects:
> >>   * Get scons to build basic components only once and share them 
> >>between architectures
> >>
> >>
> >>I'd like to throw cmake in to the build system mix as well. I 
> >>started hacking on a small prototype a while back, but it isn't able 
> >>to build
> >>gem5 yet.
> >>
> >>
> >>Cheers,
> >>Andreas
> >>
> >>
> >>On 17/01/17 16:12, Jason Lowe-Power wrote:
> >>> Hi gem5 Developers!
> >>>
> >>> As you're probably aware, I'm going to be running a gem5 coding 
> >>>sprint in  the afternoon after the Learning gem5 tutorial at HPCA 
> >>>on Sunday Feb 5.
> >>>
> >>> I'm looking for ideas for small projects that could be started (or 
> >>>even  better, completed) in a few hours. Do you have any small bugs 
> >>>that have  been bothering you? Any little features that would be 
> >>>nice, but you haven't  had the time to work on? Now's the time to 
> >>>get these things done!
> >>>
> >>> Also, if you have any bigger projects that you think it would be 
> >>>good for  people to chat about in the same room to come up with a 
> >>>plan of attack, we  may be able to fit one or two of those in, too.
> >>>
> >>> Some examples that I have so far:
> >>>
> >>> Little projects:
> >>> 1. Fix TLB warmup for x86. (See http://reviews.gem5.org/r/3474/) 
> >>> 2. Modify EventWrapper to understand C++11 lambdas so you can pass 
> >>> parameters to simple process() functions without creating a new class.
> >>> 3. Develop some ISA instruction tests to find out what is 
> >>> implemented correctly and possibly find some bugs. (See RISC-V 
> >>> insttest)
> >>>
> >>> Long-term things we may want to discuss:
> >>> 1. Revamping the test infrastructure 2. Replacing scons, possibly 
> >>> with Bazel (see https://bazel.build/)
> >>>
> >>> Please respond with any ideas you have! We definitely won't get to  
> >>>everything, but throwing ideas out there now will give us a large 
> >>>base of  options for the coding sprint.
> >>>
> >>> Thanks,
> >>> Jason
> >>
> >>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] changeset in gem5: proto: Fix warnings for protoc v3

[Nikos Nikoleris]

changeset 63325e5b0a9d in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=63325e5b0a9d
description:
proto: Fix warnings for protoc v3

protoc v3 introduces a new syntax for proto files and warns when the
syntax is not explicitly stated.

protoc relies on the fact that undefined preprocessor symbols are
explanded to 0 but since we use -Wundef they end up generating
warnings.

Change-Id: If07abeb54e932469c8f2c4d38634a97fdae40f77
Reviewed-by: Andreas Hansson 
Reviewed-by: Andreas Sandberg 
Signed-off-by: Jason Lowe-Power 

diffstat:

 src/proto/SConscript|  7 ++-
 src/proto/inst.proto|  3 ++-
 src/proto/inst_dep_record.proto |  4 +++-
 src/proto/packet.proto  |  4 +++-
 4 files changed, 14 insertions(+), 4 deletions(-)

diffs (73 lines):

diff -r ada5603bdb1c -r 63325e5b0a9d src/proto/SConscript
--- a/src/proto/SConscript  Fri Jan 27 15:05:01 2017 -0600
+++ b/src/proto/SConscript  Fri Jan 27 15:07:20 2017 -0600
@@ -1,6 +1,6 @@
 # -*- mode:python -*-
 
-# Copyright (c) 2012 ARM Limited
+# Copyright (c) 2012,2017 ARM Limited
 # All rights reserved.
 #
 # The license below extends only to copyright in the software and shall
@@ -45,3 +45,8 @@
 ProtoBuf('packet.proto')
 ProtoBuf('inst.proto')
 Source('protoio.cc')
+
+# protoc relies on the fact that undefined preprocessor symbols are
+# explanded to 0 but since we use -Wundef they end up generating
+# warnings.
+env.Append(CCFLAGS='-DPROTOBUF_INLINE_NOT_IN_HEADERS=0')
diff -r ada5603bdb1c -r 63325e5b0a9d src/proto/inst.proto
--- a/src/proto/inst.proto  Fri Jan 27 15:05:01 2017 -0600
+++ b/src/proto/inst.proto  Fri Jan 27 15:07:20 2017 -0600
@@ -1,4 +1,4 @@
-// Copyright (c) 2014 ARM Limited
+// Copyright (c) 2014,2017 ARM Limited
 // All rights reserved
 //
 // The license below extends only to copyright in the software and shall
@@ -35,6 +35,7 @@
 //
 // Authors: Ali Saidi
 
+syntax = "proto2";
 
 // Put all the generated messages in a namespace
 package ProtoMessage;
diff -r ada5603bdb1c -r 63325e5b0a9d src/proto/inst_dep_record.proto
--- a/src/proto/inst_dep_record.proto   Fri Jan 27 15:05:01 2017 -0600
+++ b/src/proto/inst_dep_record.proto   Fri Jan 27 15:07:20 2017 -0600
@@ -1,4 +1,4 @@
-// Copyright (c) 2013 ARM Limited
+// Copyright (c) 2013,2017 ARM Limited
 // All rights reserved
 //
 // The license below extends only to copyright in the software and shall
@@ -35,6 +35,8 @@
 //
 // Authors: Radhika Jagtap
 
+syntax = "proto2";
+
 // Put all the generated messages in a namespace
 package ProtoMessage;
 
diff -r ada5603bdb1c -r 63325e5b0a9d src/proto/packet.proto
--- a/src/proto/packet.protoFri Jan 27 15:05:01 2017 -0600
+++ b/src/proto/packet.protoFri Jan 27 15:07:20 2017 -0600
@@ -1,4 +1,4 @@
-// Copyright (c) 2012-2013 ARM Limited
+// Copyright (c) 2012-2013,2017 ARM Limited
 // All rights reserved
 //
 // The license below extends only to copyright in the software and shall
@@ -35,6 +35,8 @@
 //
 // Authors: Andreas Hansson
 
+syntax = "proto2";
+
 // Put all the generated messages in a namespace
 package ProtoMessage;
 
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: riscv: Fix crash when syscall argument reg in...

[Alec Roelke]

changeset ada5603bdb1c in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=ada5603bdb1c
description:
riscv: Fix crash when syscall argument reg index is too high

By default, doSyscall gets the values of six registers to be used for
system call arguments.  RISC-V, by convention, only has four.  Because
RISC-V's implementation of these indices is as arrays of integers rather
than as base indices plus offsets, trying to get the fifth argument
register's value will cause a crash.  This patch fixes that by 
returning 0
for any index higher than 3.

Signed-off-by: Jason Lowe-Power 

diffstat:

 src/arch/riscv/process.cc |  8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diffs (18 lines):

diff -r 8702d8dc2def -r ada5603bdb1c src/arch/riscv/process.cc
--- a/src/arch/riscv/process.cc Fri Jan 27 15:03:17 2017 -0600
+++ b/src/arch/riscv/process.cc Fri Jan 27 15:05:01 2017 -0600
@@ -217,7 +217,13 @@
 RiscvISA::IntReg
 RiscvLiveProcess::getSyscallArg(ThreadContext *tc, int )
 {
-return tc->readIntReg(SyscallArgumentRegs[i++]);
+// RISC-V only has four system call argument registers by convention, so
+// if a larger index is requested return 0
+RiscvISA::IntReg retval = 0;
+if (i < 4)
+retval = tc->readIntReg(SyscallArgumentRegs[i]);
+i++;
+return retval;
 }
 
 void
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: mem: Refactor CommMonitor stats, add basic at...

[Rahul Thakur]

changeset 220375a47eeb in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=220375a47eeb
description:
mem: Refactor CommMonitor stats, add basic atomic mode stats

Signed-off-by: Jason Lowe-Power 

diffstat:

 src/mem/comm_monitor.cc |  236 
 src/mem/comm_monitor.hh |   24 +++-
 2 files changed, 134 insertions(+), 126 deletions(-)

diffs (truncated from 358 to 300 lines):

diff -r 4f04a6593119 -r 220375a47eeb src/mem/comm_monitor.cc
--- a/src/mem/comm_monitor.cc   Fri Jan 27 14:58:15 2017 -0600
+++ b/src/mem/comm_monitor.cc   Fri Jan 27 14:58:16 2017 -0600
@@ -1,6 +1,7 @@
 /*
  * Copyright (c) 2012-2013, 2015 ARM Limited
- * All rights reserved
+ * Copyright (c) 2016 Google Inc.
+ * 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
@@ -36,6 +37,7 @@
  *
  * Authors: Thomas Grass
  *  Andreas Hansson
+ *  Rahul Thakur
  */
 
 #include "mem/comm_monitor.hh"
@@ -51,8 +53,6 @@
   samplePeriodicEvent(this),
   samplePeriodTicks(params->sample_period),
   samplePeriod(params->sample_period / SimClock::Float::s),
-  readAddrMask(params->read_addr_mask),
-  writeAddrMask(params->write_addr_mask),
   stats(params)
 {
 DPRINTF(CommMonitor,
@@ -113,13 +113,119 @@
 slavePort.sendFunctionalSnoop(pkt);
 }
 
+void
+CommMonitor::MonitorStats::updateReqStats(
+const ProbePoints::PacketInfo& pkt_info, bool is_atomic,
+bool expects_response)
+{
+if (pkt_info.cmd.isRead()) {
+// Increment number of observed read transactions
+if (!disableTransactionHists)
+++readTrans;
+
+// Get sample of burst length
+if (!disableBurstLengthHists)
+readBurstLengthHist.sample(pkt_info.size);
+
+// Sample the masked address
+if (!disableAddrDists)
+readAddrDist.sample(pkt_info.addr & readAddrMask);
+
+if (!disableITTDists) {
+// Sample value of read-read inter transaction time
+if (timeOfLastRead != 0)
+ittReadRead.sample(curTick() - timeOfLastRead);
+timeOfLastRead = curTick();
+
+// Sample value of req-req inter transaction time
+if (timeOfLastReq != 0)
+ittReqReq.sample(curTick() - timeOfLastReq);
+timeOfLastReq = curTick();
+}
+if (!is_atomic && !disableOutstandingHists && expects_response)
+++outstandingReadReqs;
+
+} else if (pkt_info.cmd.isWrite()) {
+// Same as for reads
+if (!disableTransactionHists)
+++writeTrans;
+
+if (!disableBurstLengthHists)
+writeBurstLengthHist.sample(pkt_info.size);
+
+// Update the bandwidth stats on the request
+if (!disableBandwidthHists) {
+writtenBytes += pkt_info.size;
+totalWrittenBytes += pkt_info.size;
+}
+
+// Sample the masked write address
+if (!disableAddrDists)
+writeAddrDist.sample(pkt_info.addr & writeAddrMask);
+
+if (!disableITTDists) {
+// Sample value of write-to-write inter transaction time
+if (timeOfLastWrite != 0)
+ittWriteWrite.sample(curTick() - timeOfLastWrite);
+timeOfLastWrite = curTick();
+
+// Sample value of req-to-req inter transaction time
+if (timeOfLastReq != 0)
+ittReqReq.sample(curTick() - timeOfLastReq);
+timeOfLastReq = curTick();
+}
+
+if (!is_atomic && !disableOutstandingHists && expects_response)
+++outstandingWriteReqs;
+}
+}
+
+void
+CommMonitor::MonitorStats::updateRespStats(
+const ProbePoints::PacketInfo& pkt_info, Tick latency, bool is_atomic)
+{
+if (pkt_info.cmd.isRead()) {
+// Decrement number of outstanding read requests
+if (!is_atomic && !disableOutstandingHists) {
+assert(outstandingReadReqs != 0);
+--outstandingReadReqs;
+}
+
+if (!disableLatencyHists)
+readLatencyHist.sample(latency);
+
+// Update the bandwidth stats based on responses for reads
+if (!disableBandwidthHists) {
+readBytes += pkt_info.size;
+totalReadBytes += pkt_info.size;
+}
+
+} else if (pkt_info.cmd.isWrite()) {
+// Decrement number of outstanding write requests
+if (!is_atomic && !disableOutstandingHists) {
+assert(outstandingWriteReqs != 0);
+--outstandingWriteReqs;
+}
+
+if (!disableLatencyHists)
+writeLatencyHist.sample(latency);
+}
+}
+
 Tick
 CommMonitor::recvAtomic(PacketPtr pkt)
 {
+const bool expects_response(pkt->needsResponse() &&
+!pkt->cacheResponding());
 

[gem5-dev] changeset in gem5: mem: Add memory footprint probe

[Rahul Thakur]

changeset 4f04a6593119 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=4f04a6593119
description:
mem: Add memory footprint probe

Signed-off-by: Jason Lowe-Power 

diffstat:

 COPYING |1 +
 configs/dram/lat_mem_rd.py  |1 +
 src/mem/probes/MemFootprintProbe.py |   48 +
 src/mem/probes/SConscript   |3 +
 src/mem/probes/mem_footprint.cc |  132 
 src/mem/probes/mem_footprint.hh |   97 ++
 6 files changed, 282 insertions(+), 0 deletions(-)

diffs (truncated from 321 to 300 lines):

diff -r be62996c95d1 -r 4f04a6593119 COPYING
--- a/COPYING   Fri Jan 27 12:40:01 2017 +
+++ b/COPYING   Fri Jan 27 14:58:15 2017 -0600
@@ -45,3 +45,4 @@
 Copyright (c) 1993-1994 Christopher G. Demetriou
 Copyright (c) 1997-2002 Makoto Matsumoto and Takuji Nishimura
 Copyright (c) 1998,2001 Manuel Bouyer.
+Copyright (c) 2016 Google Inc.
diff -r be62996c95d1 -r 4f04a6593119 configs/dram/lat_mem_rd.py
--- a/configs/dram/lat_mem_rd.pyFri Jan 27 12:40:01 2017 +
+++ b/configs/dram/lat_mem_rd.pyFri Jan 27 14:58:15 2017 -0600
@@ -252,6 +252,7 @@
 
 # add a communication monitor
 system.monitor = CommMonitor()
+system.monitor.footprint = MemFootprintProbe()
 
 # connect the traffic generator to the system
 system.tgen.port = system.monitor.slave
diff -r be62996c95d1 -r 4f04a6593119 src/mem/probes/MemFootprintProbe.py
--- /dev/null   Thu Jan 01 00:00:00 1970 +
+++ b/src/mem/probes/MemFootprintProbe.py   Fri Jan 27 14:58:15 2017 -0600
@@ -0,0 +1,48 @@
+# Copyright (c) 2016 Google Inc.
+# 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: Rahul Thakur
+
+from m5.params import *
+from m5.proxy import *
+from BaseMemProbe import BaseMemProbe
+
+class MemFootprintProbe(BaseMemProbe):
+type = "MemFootprintProbe"
+cxx_header = "mem/probes/mem_footprint.hh"
+system = Param.System(Parent.any,
+  "System pointer to get cache line and mem size")
+page_size = Param.Unsigned(4096, "Page size for page-level footprint")
diff -r be62996c95d1 -r 4f04a6593119 src/mem/probes/SConscript
--- a/src/mem/probes/SConscript Fri Jan 27 12:40:01 2017 +
+++ b/src/mem/probes/SConscript Fri Jan 27 14:58:15 2017 -0600
@@ -45,6 +45,9 @@
 SimObject('StackDistProbe.py')
 Source('stack_dist.cc')
 
+SimObject('MemFootprintProbe.py')
+Source('mem_footprint.cc')
+
 # Packet tracing requires protobuf support
 if env['HAVE_PROTOBUF']:
 SimObject('MemTraceProbe.py')
diff -r be62996c95d1 -r 4f04a6593119 src/mem/probes/mem_footprint.cc
--- /dev/null   Thu Jan 01 00:00:00 1970 +
+++ b/src/mem/probes/mem_footprint.cc   Fri Jan 27 14:58:15 2017 -0600
@@ -0,0 +1,132 @@
+/*
+ * Copyright (c) 2016 Google Inc.
+ * All rights reserved.
+ *
+ * The license below extends only to copyright in the software and
+ * shall not be 

Re: [gem5-dev] changeset in gem5: syscall_emul: [patch 4/22] remove redundant M...

[Potter, Brandon]

Yes, I'm looking into this; this is priority #1 for me right now.

-Brandon

-Original Message-
From: Andreas Sandberg [mailto:andreas.sandb...@arm.com] 
Sent: Friday, January 27, 2017 6:40 AM
To: gem5 Developer List ; gem5-...@m5sim.org; Potter, 
Brandon 
Subject: Re: [gem5-dev] changeset in gem5: syscall_emul: [patch 4/22] remove 
redundant M...

Hi Brandon,

Something bad (they hang) happened with the SE-mode ALPHA and SPARC regressions 
the other day. A quick bisection suggest that this commit was the first bad 
one. Could you have a look?

//Andreas

On 23/01/17 21:22, Brandon Potter wrote:
> changeset cd7f3a1dbf55 in /z/repo/gem5
> details: http://repo.gem5.org/gem5?cmd=changeset;node=cd7f3a1dbf55
> description:
>   syscall_emul: [patch 4/22] remove redundant M5_pid field from 
> process
>
> diffstat:
>
>   src/arch/alpha/process.cc |   4 ++--
>   src/arch/sparc/faults.cc  |   4 ++--
>   src/sim/Process.py|  13 +++--
>   src/sim/process.cc|  15 ++-
>   src/sim/process.hh|  38 ++
>   src/sim/system.cc |   3 ---
>   src/sim/system.hh |   8 
>   7 files changed, 35 insertions(+), 50 deletions(-)
>
> diffs (243 lines):
>
> diff -r 54436a1784dc -r cd7f3a1dbf55 src/arch/alpha/process.cc
> --- a/src/arch/alpha/process.cc   Wed Nov 09 14:27:40 2016 -0600
> +++ b/src/arch/alpha/process.cc   Wed Nov 09 14:27:40 2016 -0600
> @@ -179,7 +179,7 @@
>   AlphaLiveProcess::setupASNReg()
>   {
>   ThreadContext *tc = system->getThreadContext(contextIds[0]);
> -tc->setMiscRegNoEffect(IPR_DTB_ASN, M5_pid << 57);
> +tc->setMiscRegNoEffect(IPR_DTB_ASN, _pid << 57);
>   }
>
>
> @@ -187,7 +187,7 @@
>   AlphaLiveProcess::loadState(CheckpointIn )
>   {
>   LiveProcess::loadState(cp);
> -// need to set up ASN after unserialization since M5_pid value may
> +// need to set up ASN after unserialization since _pid value may
>   // come from checkpoint
>   setupASNReg();
>   }
> diff -r 54436a1784dc -r cd7f3a1dbf55 src/arch/sparc/faults.cc
> --- a/src/arch/sparc/faults.ccWed Nov 09 14:27:40 2016 -0600
> +++ b/src/arch/sparc/faults.ccWed Nov 09 14:27:40 2016 -0600
> @@ -630,7 +630,7 @@
>   } else {
>   Addr alignedVaddr = p->pTable->pageAlign(vaddr);
>   tc->getITBPtr()->insert(alignedVaddr, 0 /*partition id*/,
> -p->M5_pid /*context id*/, false, entry.pte);
> +p->_pid /*context id*/, false, entry.pte);
>   }
>   }
>
> @@ -654,7 +654,7 @@
>   } else {
>   Addr alignedVaddr = p->pTable->pageAlign(vaddr);
>   tc->getDTBPtr()->insert(alignedVaddr, 0 /*partition id*/,
> -p->M5_pid /*context id*/, false, entry.pte);
> +p->_pid /*context id*/, false, entry.pte);
>   }
>   }
>
> diff -r 54436a1784dc -r cd7f3a1dbf55 src/sim/Process.py
> --- a/src/sim/Process.py  Wed Nov 09 14:27:40 2016 -0600
> +++ b/src/sim/Process.py  Wed Nov 09 14:27:40 2016 -0600
> @@ -43,6 +43,13 @@
>   kvmInSE = Param.Bool('false', 'initialize the process for KvmCPU in SE')
>   max_stack_size = Param.MemorySize('64MB', 'maximum size of the 
> stack')
>
> +uid = Param.Int(100, 'user id')
> +euid = Param.Int(100, 'effective user id')
> +gid = Param.Int(100, 'group id')
> +egid = Param.Int(100, 'effective group id')
> +pid = Param.Int(100, 'process id')
> +ppid = Param.Int(99, 'parent process id')
> +
>   @classmethod
>   def export_methods(cls, code):
>   code('bool map(Addr vaddr, Addr paddr, int size, bool 
> cacheable=true);') @@ -60,12 +67,6 @@
>   cmd = VectorParam.String("command line (executable plus arguments)")
>   env = VectorParam.String([], "environment settings")
>   cwd = Param.String('', "current working directory")
> -uid = Param.Int(100, 'user id')
> -euid = Param.Int(100, 'effective user id')
> -gid = Param.Int(100, 'group id')
> -egid = Param.Int(100, 'effective group id')
> -pid = Param.Int(100, 'process id')
> -ppid = Param.Int(99, 'parent process id')
>   simpoint = Param.UInt64(0, 'simulation point at which to start 
> simulation')
>   drivers = VectorParam.EmulatedDriver([], 'Available emulated 
> drivers')
>
> diff -r 54436a1784dc -r cd7f3a1dbf55 src/sim/process.cc
> --- a/src/sim/process.cc  Wed Nov 09 14:27:40 2016 -0600
> +++ b/src/sim/process.cc  Wed Nov 09 14:27:40 2016 -0600
> @@ -131,12 +131,11 @@
> brk_point(0), stack_base(0), stack_size(0), stack_min(0),
> max_stack_size(params->max_stack_size),
> next_thread_stack_base(0),
> -  M5_pid(system->allocatePID()),
> useArchPT(params->useArchPT),
> kvmInSE(params->kvmInSE),
> pTable(useArchPT ?
> -static_cast(new ArchPageTable(name(), M5_pid, 
> system)) :
> -static_cast(new FuncPageTable(name(), 

Re: [gem5-dev] Review Request 3793: x86: Fix implicit stack addressing in 64-bit mode

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3793/
---

(Updated Jan. 27, 2017, 5:40 p.m.)


Review request for Default.


Repository: gem5


Description
---

x86: Fix implicit stack addressing in 64-bit mode

When in 64-bit mode, if the stack is accessed implicitly by an instruction,
the alternate address prefix should be ignored if present.

This patch adds an extra flag to the ldstop which signifies when the
address override should be ignored. Then, for all of the affected
instructions, this patch adds two options to the ld and st opcode to
use the current stack addressing mode for all addresses and to ignore the
AddressSizeFlagBit.
Finally, this patch updates the x86 TLB to not truncate the address if it
is in 64-bit mode and the IgnoreAddrSizeFlagBit is set.

This fixes a problem when calling __libc_start_main with a binary that
is linked with a recent version of ld. This version of ld uses the
address override prefix (0x67) on the call instruction instead of a nop.

Note: This has not been tested in compatibility mode and only the call
instruction with the address override prefix has been tested.

See [1] page 9 (pdf page 45)

For instructions that are affected see [1] page 519 (pdf page 555).

[1] http://support.amd.com/TechDocs/24594.pdf


Diffs (updated)
-

  src/arch/x86/isa/insts/general_purpose/control_transfer/call.py cd7f3a1dbf55 
  src/arch/x86/isa/insts/general_purpose/data_transfer/stack_operations.py 
cd7f3a1dbf55 
  src/arch/x86/isa/microops/ldstop.isa cd7f3a1dbf55 

Diff: http://reviews.gem5.org/r/3793/diff/


Testing
---

Runs "hello" compiled with gcc version "gcc (GCC) 6.3.1 20170109". Also runs 
hello compiled with earlier gcc in test-progs, and hello32 from test-progs.
Currently testing Linux boot.

Testing done on arch docker image. See 
https://hub.docker.com/r/powerjg/arch-dev/.
Run "docker run -v `pwd`:/gem5/ -it powerjg/arch-dev /bin/bash" to 
build/run/test gem5.


Thanks,

Jason Lowe-Power

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3793: x86: Fix implicit stack addressing in 64-bit mode

[Jason Lowe-Power]

> On Jan. 26, 2017, 6:47 p.m., Steve Reinhardt wrote:
> > src/arch/x86/isa/microops/ldstop.isa, line 382
> > 
> >
> > why not just put 'if not implicitStack:' in front of the previous line 
> > (that adds the legacy.addr check to self.memFlags)? If that works, then we 
> > could get rid of IgnoreAddrSizeFlagBit.

I guess I was worried about what would happen if the prefix was included when 
in 32-bit mode. But I think I've reasoned through this and it seems like it 
would be handled correctly.


On Jan. 26, 2017, 6:47 p.m., Jason Lowe-Power wrote:
> > If we were trying to keep things clean, I'd suggest adding new micro-ops 
> > like ld.ss and st.ss that would wrap ld an st and automatically set 
> > segment=ss, implicitStack=True, addressSize=ssz, and maybe dataSize=ssz 
> > (looks like we usually set this, but not always, and I'm not sure if the 
> > exceptions are significant) and, for st.ss, disp=-env.dataSize.
> > 
> > I can totally understand if you don't want to mess with that at this point 
> > though, so I won't press you on it.

I tried this method. It was worth it for me to learn how to do this. I'm not 
sure if '.' is allowed in microp names. Whenver I tried to include a '.' I got 
an error "*** Error creating microop object with mnemonic st."


- Jason


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3793/#review9328
---


On Jan. 27, 2017, 5:40 p.m., Jason Lowe-Power wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3793/
> ---
> 
> (Updated Jan. 27, 2017, 5:40 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> x86: Fix implicit stack addressing in 64-bit mode
> 
> When in 64-bit mode, if the stack is accessed implicitly by an instruction,
> the alternate address prefix should be ignored if present.
> 
> This patch adds an extra flag to the ldstop which signifies when the
> address override should be ignored. Then, for all of the affected
> instructions, this patch adds two options to the ld and st opcode to
> use the current stack addressing mode for all addresses and to ignore the
> AddressSizeFlagBit.
> Finally, this patch updates the x86 TLB to not truncate the address if it
> is in 64-bit mode and the IgnoreAddrSizeFlagBit is set.
> 
> This fixes a problem when calling __libc_start_main with a binary that
> is linked with a recent version of ld. This version of ld uses the
> address override prefix (0x67) on the call instruction instead of a nop.
> 
> Note: This has not been tested in compatibility mode and only the call
> instruction with the address override prefix has been tested.
> 
> See [1] page 9 (pdf page 45)
> 
> For instructions that are affected see [1] page 519 (pdf page 555).
> 
> [1] http://support.amd.com/TechDocs/24594.pdf
> 
> 
> Diffs
> -
> 
>   src/arch/x86/isa/insts/general_purpose/control_transfer/call.py 
> cd7f3a1dbf55 
>   src/arch/x86/isa/insts/general_purpose/data_transfer/stack_operations.py 
> cd7f3a1dbf55 
>   src/arch/x86/isa/microops/ldstop.isa cd7f3a1dbf55 
> 
> Diff: http://reviews.gem5.org/r/3793/diff/
> 
> 
> Testing
> ---
> 
> Runs "hello" compiled with gcc version "gcc (GCC) 6.3.1 20170109". Also runs 
> hello compiled with earlier gcc in test-progs, and hello32 from test-progs.
> Currently testing Linux boot.
> 
> Testing done on arch docker image. See 
> https://hub.docker.com/r/powerjg/arch-dev/.
> Run "docker run -v `pwd`:/gem5/ -it powerjg/arch-dev /bin/bash" to 
> build/run/test gem5.
> 
> 
> Thanks,
> 
> Jason Lowe-Power
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3795: misc: Add Python.h header to pyevents.hh

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3795/
---

Review request for Default.


Repository: gem5


Description
---

misc: Add Python.h header to pyevents.hh


Diffs
-

  src/python/swig/pyevent.hh cd7f3a1dbf55 

Diff: http://reviews.gem5.org/r/3795/diff/


Testing
---


Thanks,

Jason Lowe-Power

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3792: misc: Update #!env calls for python to explicit version

[Andreas Sandberg]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3792/#review9339
---

Ship it!


Ship It!

- Andreas Sandberg


On Jan. 27, 2017, 5:32 p.m., Jason Lowe-Power wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3792/
> ---
> 
> (Updated Jan. 27, 2017, 5:32 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> misc: Update #!env calls for python to explicit version
> 
> In some newer Linux distributions, env python default to Python 3.0. This
> patch explicitly uses "python2" instead of just "python" for all scripts
> that use #!
> 
> Reported-by: Sanchayan Maity 
> 
> 
> Diffs
> -
> 
>   util/minorview.py cd7f3a1dbf55 
>   util/o3-pipeview.py cd7f3a1dbf55 
>   util/oprofile-top.py cd7f3a1dbf55 
>   util/pbs/job.py cd7f3a1dbf55 
>   util/pbs/send.py cd7f3a1dbf55 
>   util/protolib.py cd7f3a1dbf55 
>   util/qdo cd7f3a1dbf55 
>   util/regress cd7f3a1dbf55 
>   util/slicc cd7f3a1dbf55 
>   util/stats/stats.py cd7f3a1dbf55 
>   util/streamline/m5stats2streamline.py cd7f3a1dbf55 
>   util/style.py cd7f3a1dbf55 
>   util/style/__init__.py cd7f3a1dbf55 
>   util/style/repo.py cd7f3a1dbf55 
>   util/style/sort_includes.py cd7f3a1dbf55 
>   util/style/style.py cd7f3a1dbf55 
>   util/style/verifiers.py cd7f3a1dbf55 
>   util/maint/git-patch-to-hg-patch cd7f3a1dbf55 
>   util/memtest-soak.py cd7f3a1dbf55 
>   ext/mcpat/regression/regression.py cd7f3a1dbf55 
>   ext/mcpat/regression/verify_output.py cd7f3a1dbf55 
>   ext/ply/example/classcalc/calc.py cd7f3a1dbf55 
>   ext/ply/example/newclasscalc/calc.py cd7f3a1dbf55 
>   src/unittest/genini.py cd7f3a1dbf55 
>   tests/testing/__init__.py cd7f3a1dbf55 
>   tests/testing/helpers.py cd7f3a1dbf55 
>   tests/testing/results.py cd7f3a1dbf55 
>   tests/testing/tests.py cd7f3a1dbf55 
>   tests/testing/units.py cd7f3a1dbf55 
>   tests/tests.py cd7f3a1dbf55 
>   util/batch/job.py cd7f3a1dbf55 
>   util/batch/send.py cd7f3a1dbf55 
>   util/checkpoint-tester.py cd7f3a1dbf55 
>   util/compile cd7f3a1dbf55 
>   util/cpt_upgrader.py cd7f3a1dbf55 
>   util/decode_inst_dep_trace.py cd7f3a1dbf55 
>   util/decode_inst_trace.py cd7f3a1dbf55 
>   util/decode_packet_trace.py cd7f3a1dbf55 
>   util/dram_lat_mem_rd_plot.py cd7f3a1dbf55 
>   util/dram_sweep_plot.py cd7f3a1dbf55 
>   util/encode_inst_dep_trace.py cd7f3a1dbf55 
>   util/encode_packet_trace.py cd7f3a1dbf55 
>   util/find_copyrights.py cd7f3a1dbf55 
>   util/git-pre-commit.py cd7f3a1dbf55 
>   util/hgstyle.py cd7f3a1dbf55 
> 
> Diff: http://reviews.gem5.org/r/3792/diff/
> 
> 
> Testing
> ---
> 
> gem5 compiles on arch with this patch and http://reviews.gem5.org/r/3779/.
> 
> Testing done on arch docker image. See 
> https://hub.docker.com/r/powerjg/arch-dev/.
> Run "docker run -v `pwd`:/gem5/ -it powerjg/arch-dev /bin/bash" to 
> build/run/test gem5.
> 
> 
> Thanks,
> 
> Jason Lowe-Power
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3792: misc: Update #!env calls for python to explicit version

[Andreas Sandberg]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3792/#review9337
---


Seems reasonable to me. Could you factor out the header change and put it in a 
separate commit?

- Andreas Sandberg


On Jan. 26, 2017, 4:47 p.m., Jason Lowe-Power wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3792/
> ---
> 
> (Updated Jan. 26, 2017, 4:47 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> misc: Update #!env calls for python to explicit version
> 
> In some newer Linux distributions, env python default to Python 3.0. This
> patch explicitly uses "python2" instead of just "python" for all scripts
> that use #!
> 
> Reported-by: Sanchayan Maity 
> 
> 
> Diffs
> -
> 
>   util/git-pre-commit.py cd7f3a1dbf55 
>   util/hgstyle.py cd7f3a1dbf55 
>   util/maint/git-patch-to-hg-patch cd7f3a1dbf55 
>   util/memtest-soak.py cd7f3a1dbf55 
>   util/minorview.py cd7f3a1dbf55 
>   util/o3-pipeview.py cd7f3a1dbf55 
>   util/oprofile-top.py cd7f3a1dbf55 
>   util/pbs/job.py cd7f3a1dbf55 
>   util/pbs/send.py cd7f3a1dbf55 
>   util/protolib.py cd7f3a1dbf55 
>   util/qdo cd7f3a1dbf55 
>   util/decode_inst_dep_trace.py cd7f3a1dbf55 
>   util/decode_inst_trace.py cd7f3a1dbf55 
>   util/decode_packet_trace.py cd7f3a1dbf55 
>   util/dram_lat_mem_rd_plot.py cd7f3a1dbf55 
>   util/dram_sweep_plot.py cd7f3a1dbf55 
>   util/encode_inst_dep_trace.py cd7f3a1dbf55 
>   util/encode_packet_trace.py cd7f3a1dbf55 
>   util/find_copyrights.py cd7f3a1dbf55 
>   tests/testing/helpers.py cd7f3a1dbf55 
>   tests/testing/results.py cd7f3a1dbf55 
>   tests/testing/tests.py cd7f3a1dbf55 
>   tests/testing/units.py cd7f3a1dbf55 
>   tests/tests.py cd7f3a1dbf55 
>   util/batch/job.py cd7f3a1dbf55 
>   util/batch/send.py cd7f3a1dbf55 
>   util/checkpoint-tester.py cd7f3a1dbf55 
>   util/compile cd7f3a1dbf55 
>   util/cpt_upgrader.py cd7f3a1dbf55 
>   ext/mcpat/regression/regression.py cd7f3a1dbf55 
>   ext/mcpat/regression/verify_output.py cd7f3a1dbf55 
>   ext/ply/example/classcalc/calc.py cd7f3a1dbf55 
>   ext/ply/example/newclasscalc/calc.py cd7f3a1dbf55 
>   src/python/swig/pyevent.hh cd7f3a1dbf55 
>   src/unittest/genini.py cd7f3a1dbf55 
>   tests/testing/__init__.py cd7f3a1dbf55 
>   util/style/style.py cd7f3a1dbf55 
>   util/style/verifiers.py cd7f3a1dbf55 
>   util/regress cd7f3a1dbf55 
>   util/slicc cd7f3a1dbf55 
>   util/stats/stats.py cd7f3a1dbf55 
>   util/streamline/m5stats2streamline.py cd7f3a1dbf55 
>   util/style.py cd7f3a1dbf55 
>   util/style/__init__.py cd7f3a1dbf55 
>   util/style/repo.py cd7f3a1dbf55 
>   util/style/sort_includes.py cd7f3a1dbf55 
> 
> Diff: http://reviews.gem5.org/r/3792/diff/
> 
> 
> Testing
> ---
> 
> gem5 compiles on arch with this patch and http://reviews.gem5.org/r/3779/.
> 
> Testing done on arch docker image. See 
> https://hub.docker.com/r/powerjg/arch-dev/.
> Run "docker run -v `pwd`:/gem5/ -it powerjg/arch-dev /bin/bash" to 
> build/run/test gem5.
> 
> 
> Thanks,
> 
> Jason Lowe-Power
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3795: misc: Add Python.h header to pyevents.hh

[Andreas Sandberg]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3795/#review9340
---

Ship it!


Ship It!

- Andreas Sandberg


On Jan. 27, 2017, 5:32 p.m., Jason Lowe-Power wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3795/
> ---
> 
> (Updated Jan. 27, 2017, 5:32 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> misc: Add Python.h header to pyevents.hh
> 
> 
> Diffs
> -
> 
>   src/python/swig/pyevent.hh cd7f3a1dbf55 
> 
> Diff: http://reviews.gem5.org/r/3795/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Lowe-Power
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3792: misc: Update #!env calls for python to explicit version

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3792/
---

(Updated Jan. 27, 2017, 5:32 p.m.)


Review request for Default.


Repository: gem5


Description
---

misc: Update #!env calls for python to explicit version

In some newer Linux distributions, env python default to Python 3.0. This
patch explicitly uses "python2" instead of just "python" for all scripts
that use #!

Reported-by: Sanchayan Maity 


Diffs (updated)
-

  util/minorview.py cd7f3a1dbf55 
  util/o3-pipeview.py cd7f3a1dbf55 
  util/oprofile-top.py cd7f3a1dbf55 
  util/pbs/job.py cd7f3a1dbf55 
  util/pbs/send.py cd7f3a1dbf55 
  util/protolib.py cd7f3a1dbf55 
  util/qdo cd7f3a1dbf55 
  util/regress cd7f3a1dbf55 
  util/slicc cd7f3a1dbf55 
  util/stats/stats.py cd7f3a1dbf55 
  util/streamline/m5stats2streamline.py cd7f3a1dbf55 
  util/style.py cd7f3a1dbf55 
  util/style/__init__.py cd7f3a1dbf55 
  util/style/repo.py cd7f3a1dbf55 
  util/style/sort_includes.py cd7f3a1dbf55 
  util/style/style.py cd7f3a1dbf55 
  util/style/verifiers.py cd7f3a1dbf55 
  util/maint/git-patch-to-hg-patch cd7f3a1dbf55 
  util/memtest-soak.py cd7f3a1dbf55 
  ext/mcpat/regression/regression.py cd7f3a1dbf55 
  ext/mcpat/regression/verify_output.py cd7f3a1dbf55 
  ext/ply/example/classcalc/calc.py cd7f3a1dbf55 
  ext/ply/example/newclasscalc/calc.py cd7f3a1dbf55 
  src/unittest/genini.py cd7f3a1dbf55 
  tests/testing/__init__.py cd7f3a1dbf55 
  tests/testing/helpers.py cd7f3a1dbf55 
  tests/testing/results.py cd7f3a1dbf55 
  tests/testing/tests.py cd7f3a1dbf55 
  tests/testing/units.py cd7f3a1dbf55 
  tests/tests.py cd7f3a1dbf55 
  util/batch/job.py cd7f3a1dbf55 
  util/batch/send.py cd7f3a1dbf55 
  util/checkpoint-tester.py cd7f3a1dbf55 
  util/compile cd7f3a1dbf55 
  util/cpt_upgrader.py cd7f3a1dbf55 
  util/decode_inst_dep_trace.py cd7f3a1dbf55 
  util/decode_inst_trace.py cd7f3a1dbf55 
  util/decode_packet_trace.py cd7f3a1dbf55 
  util/dram_lat_mem_rd_plot.py cd7f3a1dbf55 
  util/dram_sweep_plot.py cd7f3a1dbf55 
  util/encode_inst_dep_trace.py cd7f3a1dbf55 
  util/encode_packet_trace.py cd7f3a1dbf55 
  util/find_copyrights.py cd7f3a1dbf55 
  util/git-pre-commit.py cd7f3a1dbf55 
  util/hgstyle.py cd7f3a1dbf55 

Diff: http://reviews.gem5.org/r/3792/diff/


Testing
---

gem5 compiles on arch with this patch and http://reviews.gem5.org/r/3779/.

Testing done on arch docker image. See 
https://hub.docker.com/r/powerjg/arch-dev/.
Run "docker run -v `pwd`:/gem5/ -it powerjg/arch-dev /bin/bash" to 
build/run/test gem5.


Thanks,

Jason Lowe-Power

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3792: misc: Update #!env calls for python to explicit version

[Jason Lowe-Power]

> On Jan. 27, 2017, 5:21 p.m., Andreas Sandberg wrote:
> > Seems reasonable to me. Could you factor out the header change and put it 
> > in a separate commit?

Absolutely.


- Jason


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3792/#review9337
---


On Jan. 26, 2017, 4:47 p.m., Jason Lowe-Power wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3792/
> ---
> 
> (Updated Jan. 26, 2017, 4:47 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> misc: Update #!env calls for python to explicit version
> 
> In some newer Linux distributions, env python default to Python 3.0. This
> patch explicitly uses "python2" instead of just "python" for all scripts
> that use #!
> 
> Reported-by: Sanchayan Maity 
> 
> 
> Diffs
> -
> 
>   util/git-pre-commit.py cd7f3a1dbf55 
>   util/hgstyle.py cd7f3a1dbf55 
>   util/maint/git-patch-to-hg-patch cd7f3a1dbf55 
>   util/memtest-soak.py cd7f3a1dbf55 
>   util/minorview.py cd7f3a1dbf55 
>   util/o3-pipeview.py cd7f3a1dbf55 
>   util/oprofile-top.py cd7f3a1dbf55 
>   util/pbs/job.py cd7f3a1dbf55 
>   util/pbs/send.py cd7f3a1dbf55 
>   util/protolib.py cd7f3a1dbf55 
>   util/qdo cd7f3a1dbf55 
>   util/decode_inst_dep_trace.py cd7f3a1dbf55 
>   util/decode_inst_trace.py cd7f3a1dbf55 
>   util/decode_packet_trace.py cd7f3a1dbf55 
>   util/dram_lat_mem_rd_plot.py cd7f3a1dbf55 
>   util/dram_sweep_plot.py cd7f3a1dbf55 
>   util/encode_inst_dep_trace.py cd7f3a1dbf55 
>   util/encode_packet_trace.py cd7f3a1dbf55 
>   util/find_copyrights.py cd7f3a1dbf55 
>   tests/testing/helpers.py cd7f3a1dbf55 
>   tests/testing/results.py cd7f3a1dbf55 
>   tests/testing/tests.py cd7f3a1dbf55 
>   tests/testing/units.py cd7f3a1dbf55 
>   tests/tests.py cd7f3a1dbf55 
>   util/batch/job.py cd7f3a1dbf55 
>   util/batch/send.py cd7f3a1dbf55 
>   util/checkpoint-tester.py cd7f3a1dbf55 
>   util/compile cd7f3a1dbf55 
>   util/cpt_upgrader.py cd7f3a1dbf55 
>   ext/mcpat/regression/regression.py cd7f3a1dbf55 
>   ext/mcpat/regression/verify_output.py cd7f3a1dbf55 
>   ext/ply/example/classcalc/calc.py cd7f3a1dbf55 
>   ext/ply/example/newclasscalc/calc.py cd7f3a1dbf55 
>   src/python/swig/pyevent.hh cd7f3a1dbf55 
>   src/unittest/genini.py cd7f3a1dbf55 
>   tests/testing/__init__.py cd7f3a1dbf55 
>   util/style/style.py cd7f3a1dbf55 
>   util/style/verifiers.py cd7f3a1dbf55 
>   util/regress cd7f3a1dbf55 
>   util/slicc cd7f3a1dbf55 
>   util/stats/stats.py cd7f3a1dbf55 
>   util/streamline/m5stats2streamline.py cd7f3a1dbf55 
>   util/style.py cd7f3a1dbf55 
>   util/style/__init__.py cd7f3a1dbf55 
>   util/style/repo.py cd7f3a1dbf55 
>   util/style/sort_includes.py cd7f3a1dbf55 
> 
> Diff: http://reviews.gem5.org/r/3792/diff/
> 
> 
> Testing
> ---
> 
> gem5 compiles on arch with this patch and http://reviews.gem5.org/r/3779/.
> 
> Testing done on arch docker image. See 
> https://hub.docker.com/r/powerjg/arch-dev/.
> Run "docker run -v `pwd`:/gem5/ -it powerjg/arch-dev /bin/bash" to 
> build/run/test gem5.
> 
> 
> Thanks,
> 
> Jason Lowe-Power
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3794: style: Force Python.h to be included before main header

[Jason Lowe-Power]

> On Jan. 27, 2017, 3 p.m., Jason Lowe-Power wrote:
> > Oops. I should have included this in my description of 
> > http://reviews.gem5.org/r/3792/. I think another solution is to include 
> > Python.h in src/python/swig/pyevent.hh. See my change in 
> > http://reviews.gem5.org/r/3792/diff/1/#33.
> > 
> > If my fix does work, I think it's better to just include Python.h there 
> > instead of changing the style.
> 
> Andreas Sandberg wrote:
> I'd like to avoid including Python.h in any header files for dependency 
> reasons. Another reason for including it before any other header is that it 
> solves this entire class of issues (the flip side is that we wouldn't always 
> spot headers that requires it).
> 
> We actually used to require the Python header to be first in the files 
> that required it, but it got lost in a a style update a while back.
> 
> Jason Lowe-Power wrote:
> Could you explain more about why you don't want to include Python.h in 
> pyevent.hh? It seems to me that since this file requires things declared in 
> Python.h (e.g., PyObject) that it should be included here. Otherwise, we have 
> to remember that anytime we include python/swig/pyevent.hh we first must 
> include Python.h.
> 
> Andreas Sandberg wrote:
> Sorry, you're absolutely right. It should definitely be included in 
> pyevent.hh. Does that solve the rest of the Python issues? If so, do we 
> need/want this change?

I *think* it solves all of the issues. I was able to use 
http://reviews.gem5.org/r/3792/ and http://reviews.gem5.org/r/3779/ to resolve 
all of the build issues on Arch Linux.

I'm not opposed to pushing this to change the style back, if we think that 
makes sense, too. But I think it's somewhat orthogonal to the build errors.


- Jason


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3794/#review9331
---


On Jan. 27, 2017, 1:39 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3794/
> ---
> 
> (Updated Jan. 27, 2017, 1:39 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11803:1dba09aeeefd
> ---
> style: Force Python.h to be included before main header
> 
> Python's header files set various compiler macros (e.g.,
> _XOPEN_SOURCE) unconditionally. This triggers preprocessor warnings
> that end up being treated as errors. The style guide used to mandate
> that Python headers are included before any other header. This
> requirement was changed to always include a source file's main header
> first, which ended up triggering these errors.
> 
> This change updates the style checker to always include Python.h
> before the main header file.
> 
> Change-Id: Id6a4f7fc64a336a8fd26691a0ca682abeb1d1579
> Signed-off-by: Andreas Sandberg 
> Reviewed-by: Nikos Nikoleris 
> 
> 
> Diffs
> -
> 
>   src/python/swig/pyevent.cc be62996c95d1 
>   src/sim/init.cc be62996c95d1 
>   src/sim/py_interact.cc be62996c95d1 
>   util/style/sort_includes.py be62996c95d1 
> 
> Diff: http://reviews.gem5.org/r/3794/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3794: style: Force Python.h to be included before main header

[Andreas Sandberg]

> On Jan. 27, 2017, 3 p.m., Jason Lowe-Power wrote:
> > Oops. I should have included this in my description of 
> > http://reviews.gem5.org/r/3792/. I think another solution is to include 
> > Python.h in src/python/swig/pyevent.hh. See my change in 
> > http://reviews.gem5.org/r/3792/diff/1/#33.
> > 
> > If my fix does work, I think it's better to just include Python.h there 
> > instead of changing the style.
> 
> Andreas Sandberg wrote:
> I'd like to avoid including Python.h in any header files for dependency 
> reasons. Another reason for including it before any other header is that it 
> solves this entire class of issues (the flip side is that we wouldn't always 
> spot headers that requires it).
> 
> We actually used to require the Python header to be first in the files 
> that required it, but it got lost in a a style update a while back.
> 
> Jason Lowe-Power wrote:
> Could you explain more about why you don't want to include Python.h in 
> pyevent.hh? It seems to me that since this file requires things declared in 
> Python.h (e.g., PyObject) that it should be included here. Otherwise, we have 
> to remember that anytime we include python/swig/pyevent.hh we first must 
> include Python.h.

Sorry, you're absolutely right. It should definitely be included in pyevent.hh. 
Does that solve the rest of the Python issues? If so, do we need/want this 
change?


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3794/#review9331
---


On Jan. 27, 2017, 1:39 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3794/
> ---
> 
> (Updated Jan. 27, 2017, 1:39 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11803:1dba09aeeefd
> ---
> style: Force Python.h to be included before main header
> 
> Python's header files set various compiler macros (e.g.,
> _XOPEN_SOURCE) unconditionally. This triggers preprocessor warnings
> that end up being treated as errors. The style guide used to mandate
> that Python headers are included before any other header. This
> requirement was changed to always include a source file's main header
> first, which ended up triggering these errors.
> 
> This change updates the style checker to always include Python.h
> before the main header file.
> 
> Change-Id: Id6a4f7fc64a336a8fd26691a0ca682abeb1d1579
> Signed-off-by: Andreas Sandberg 
> Reviewed-by: Nikos Nikoleris 
> 
> 
> Diffs
> -
> 
>   src/python/swig/pyevent.cc be62996c95d1 
>   src/sim/init.cc be62996c95d1 
>   src/sim/py_interact.cc be62996c95d1 
>   util/style/sort_includes.py be62996c95d1 
> 
> Diff: http://reviews.gem5.org/r/3794/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3794: style: Force Python.h to be included before main header

[Jason Lowe-Power]

> On Jan. 27, 2017, 3 p.m., Jason Lowe-Power wrote:
> > Oops. I should have included this in my description of 
> > http://reviews.gem5.org/r/3792/. I think another solution is to include 
> > Python.h in src/python/swig/pyevent.hh. See my change in 
> > http://reviews.gem5.org/r/3792/diff/1/#33.
> > 
> > If my fix does work, I think it's better to just include Python.h there 
> > instead of changing the style.
> 
> Andreas Sandberg wrote:
> I'd like to avoid including Python.h in any header files for dependency 
> reasons. Another reason for including it before any other header is that it 
> solves this entire class of issues (the flip side is that we wouldn't always 
> spot headers that requires it).
> 
> We actually used to require the Python header to be first in the files 
> that required it, but it got lost in a a style update a while back.

Could you explain more about why you don't want to include Python.h in 
pyevent.hh? It seems to me that since this file requires things declared in 
Python.h (e.g., PyObject) that it should be included here. Otherwise, we have 
to remember that anytime we include python/swig/pyevent.hh we first must 
include Python.h.


- Jason


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3794/#review9331
---


On Jan. 27, 2017, 1:39 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3794/
> ---
> 
> (Updated Jan. 27, 2017, 1:39 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11803:1dba09aeeefd
> ---
> style: Force Python.h to be included before main header
> 
> Python's header files set various compiler macros (e.g.,
> _XOPEN_SOURCE) unconditionally. This triggers preprocessor warnings
> that end up being treated as errors. The style guide used to mandate
> that Python headers are included before any other header. This
> requirement was changed to always include a source file's main header
> first, which ended up triggering these errors.
> 
> This change updates the style checker to always include Python.h
> before the main header file.
> 
> Change-Id: Id6a4f7fc64a336a8fd26691a0ca682abeb1d1579
> Signed-off-by: Andreas Sandberg 
> Reviewed-by: Nikos Nikoleris 
> 
> 
> Diffs
> -
> 
>   src/python/swig/pyevent.cc be62996c95d1 
>   src/sim/init.cc be62996c95d1 
>   src/sim/py_interact.cc be62996c95d1 
>   util/style/sort_includes.py be62996c95d1 
> 
> Diff: http://reviews.gem5.org/r/3794/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3794: style: Force Python.h to be included before main header

[Andreas Sandberg]

> On Jan. 27, 2017, 3 p.m., Jason Lowe-Power wrote:
> > Oops. I should have included this in my description of 
> > http://reviews.gem5.org/r/3792/. I think another solution is to include 
> > Python.h in src/python/swig/pyevent.hh. See my change in 
> > http://reviews.gem5.org/r/3792/diff/1/#33.
> > 
> > If my fix does work, I think it's better to just include Python.h there 
> > instead of changing the style.

I'd like to avoid including Python.h in any header files for dependency 
reasons. Another reason for including it before any other header is that it 
solves this entire class of issues (the flip side is that we wouldn't always 
spot headers that requires it).

We actually used to require the Python header to be first in the files that 
required it, but it got lost in a a style update a while back.


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3794/#review9331
---


On Jan. 27, 2017, 1:39 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3794/
> ---
> 
> (Updated Jan. 27, 2017, 1:39 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11803:1dba09aeeefd
> ---
> style: Force Python.h to be included before main header
> 
> Python's header files set various compiler macros (e.g.,
> _XOPEN_SOURCE) unconditionally. This triggers preprocessor warnings
> that end up being treated as errors. The style guide used to mandate
> that Python headers are included before any other header. This
> requirement was changed to always include a source file's main header
> first, which ended up triggering these errors.
> 
> This change updates the style checker to always include Python.h
> before the main header file.
> 
> Change-Id: Id6a4f7fc64a336a8fd26691a0ca682abeb1d1579
> Signed-off-by: Andreas Sandberg 
> Reviewed-by: Nikos Nikoleris 
> 
> 
> Diffs
> -
> 
>   src/python/swig/pyevent.cc be62996c95d1 
>   src/sim/init.cc be62996c95d1 
>   src/sim/py_interact.cc be62996c95d1 
>   util/style/sort_includes.py be62996c95d1 
> 
> Diff: http://reviews.gem5.org/r/3794/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] [gem5-users] gem5 build failure

[Pierre-Yves Péneau]

On 01/27/2017 02:42 PM, Andreas Sandberg wrote:
> On 27/01/17 12:32, Pierre-Yves Péneau wrote:
>> On 01/27/2017 01:20 PM, Andreas Sandberg wrote:
>>> Hi Pierre,
>>>
>>> I send out an email to the dev list on the 12th of January (Header order
>>> issues) describing a similar issue we have in our CI system. I have an
>>> updated version of the style checker that enforces that Python.h is
>>> included first and plan to post it after lunch.
>> Oh, I didn't see this mail sorry. Problem solved then !
> 
> Could you have a look at RB3794 [1] and see if that solves your problem?
> If it does, we should make sure to commit this change ASAP and update
> the style guide.

It works. Thank you !

> Cheers,
> Andreas
> 
> [1] http://reviews.gem5.org/r/3794/
> 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

-- 
+-+
| Pierre-Yves Péneau - PhD student |  first.last at lirmm.fr  |
| LIRMM / CNRS - SYSMIC team   |+ 33 4 67 41 86 33|
| Building 4 Office H2.2   |http://walafc0.org|
+-+
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3794: style: Force Python.h to be included before main header

[Pierre-Yves Péneau]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3794/#review9332
---

Ship it!


Ship It!

- Pierre-Yves Péneau


On Jan. 27, 2017, 2:39 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3794/
> ---
> 
> (Updated Jan. 27, 2017, 2:39 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11803:1dba09aeeefd
> ---
> style: Force Python.h to be included before main header
> 
> Python's header files set various compiler macros (e.g.,
> _XOPEN_SOURCE) unconditionally. This triggers preprocessor warnings
> that end up being treated as errors. The style guide used to mandate
> that Python headers are included before any other header. This
> requirement was changed to always include a source file's main header
> first, which ended up triggering these errors.
> 
> This change updates the style checker to always include Python.h
> before the main header file.
> 
> Change-Id: Id6a4f7fc64a336a8fd26691a0ca682abeb1d1579
> Signed-off-by: Andreas Sandberg 
> Reviewed-by: Nikos Nikoleris 
> 
> 
> Diffs
> -
> 
>   src/python/swig/pyevent.cc be62996c95d1 
>   src/sim/init.cc be62996c95d1 
>   src/sim/py_interact.cc be62996c95d1 
>   util/style/sort_includes.py be62996c95d1 
> 
> Diff: http://reviews.gem5.org/r/3794/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3794: style: Force Python.h to be included before main header

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3794/#review9331
---


Oops. I should have included this in my description of 
http://reviews.gem5.org/r/3792/. I think another solution is to include 
Python.h in src/python/swig/pyevent.hh. See my change in 
http://reviews.gem5.org/r/3792/diff/1/#33.

If my fix does work, I think it's better to just include Python.h there instead 
of changing the style.

- Jason Lowe-Power


On Jan. 27, 2017, 1:39 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3794/
> ---
> 
> (Updated Jan. 27, 2017, 1:39 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11803:1dba09aeeefd
> ---
> style: Force Python.h to be included before main header
> 
> Python's header files set various compiler macros (e.g.,
> _XOPEN_SOURCE) unconditionally. This triggers preprocessor warnings
> that end up being treated as errors. The style guide used to mandate
> that Python headers are included before any other header. This
> requirement was changed to always include a source file's main header
> first, which ended up triggering these errors.
> 
> This change updates the style checker to always include Python.h
> before the main header file.
> 
> Change-Id: Id6a4f7fc64a336a8fd26691a0ca682abeb1d1579
> Signed-off-by: Andreas Sandberg 
> Reviewed-by: Nikos Nikoleris 
> 
> 
> Diffs
> -
> 
>   src/python/swig/pyevent.cc be62996c95d1 
>   src/sim/init.cc be62996c95d1 
>   src/sim/py_interact.cc be62996c95d1 
>   util/style/sort_includes.py be62996c95d1 
> 
> Diff: http://reviews.gem5.org/r/3794/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] [gem5-users] gem5 build failure

[Andreas Sandberg]

On 27/01/17 12:32, Pierre-Yves Péneau wrote:

On 01/27/2017 01:20 PM, Andreas Sandberg wrote:

Hi Pierre,

I send out an email to the dev list on the 12th of January (Header order
issues) describing a similar issue we have in our CI system. I have an
updated version of the style checker that enforces that Python.h is
included first and plan to post it after lunch.

Oh, I didn't see this mail sorry. Problem solved then !


Could you have a look at RB3794 [1] and see if that solves your problem?
If it does, we should make sure to commit this change ASAP and update
the style guide.

Cheers,
Andreas

[1] http://reviews.gem5.org/r/3794/
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] Review Request 3794: style: Force Python.h to be included before main header

[Andreas Sandberg]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3794/
---

Review request for Default.


Repository: gem5


Description
---

Changeset 11803:1dba09aeeefd
---
style: Force Python.h to be included before main header

Python's header files set various compiler macros (e.g.,
_XOPEN_SOURCE) unconditionally. This triggers preprocessor warnings
that end up being treated as errors. The style guide used to mandate
that Python headers are included before any other header. This
requirement was changed to always include a source file's main header
first, which ended up triggering these errors.

This change updates the style checker to always include Python.h
before the main header file.

Change-Id: Id6a4f7fc64a336a8fd26691a0ca682abeb1d1579
Signed-off-by: Andreas Sandberg 
Reviewed-by: Nikos Nikoleris 


Diffs
-

  src/python/swig/pyevent.cc be62996c95d1 
  src/sim/init.cc be62996c95d1 
  src/sim/py_interact.cc be62996c95d1 
  util/style/sort_includes.py be62996c95d1 

Diff: http://reviews.gem5.org/r/3794/diff/


Testing
---


Thanks,

Andreas Sandberg

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] changeset in gem5: python: Move native wrappers to the _m5 names...

[Andreas Sandberg]

changeset be62996c95d1 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=be62996c95d1
description:
python: Move native wrappers to the _m5 namespace

Swig wrappers for native objects currently share the _m5.internal name
space with Python code. This is undesirable if we ever want to switch
from Swig to some other framework for native binding (e.g., PyBind11
or Boost::Python). This changeset moves all of such wrappers to the
_m5 namespace, which is now reserved for native code.

Change-Id: I2d2bc12dbc05b57b7c5a75f072e08124413d77f3
Signed-off-by: Andreas Sandberg 
Reviewed-by: Curtis Dunham 
Reviewed-by: Jason Lowe-Power 

diffstat:

 src/SConscript   |  20 ++--
 src/python/SConscript|  19 ++-
 src/python/_m5/__init__.py   |  39 +++
 src/python/m5/SimObject.py   |   6 +++---
 src/python/m5/__init__.py|  11 ++-
 src/python/m5/core.py|   5 +
 src/python/m5/debug.py   |  11 +--
 src/python/m5/event.py   |   8 
 src/python/m5/internal/params.py |   4 ++--
 src/python/m5/params.py  |  12 ++--
 src/python/m5/simulate.py|  33 +++--
 src/python/m5/stats/__init__.py  |  20 ++--
 src/python/m5/ticks.py   |   4 ++--
 src/python/m5/trace.py   |  12 ++--
 src/python/swig/core.i   |   2 +-
 src/python/swig/debug.i  |   2 +-
 src/python/swig/drain.i  |   2 +-
 src/python/swig/event.i  |   2 +-
 src/python/swig/pyobject.i   |   2 +-
 src/python/swig/range.i  |   2 +-
 src/python/swig/serialize.i  |   2 +-
 src/python/swig/stats.i  |   2 +-
 src/python/swig/trace.i  |   2 +-
 src/unittest/SConscript  |   2 +-
 src/unittest/stattest.i  |   2 +-
 src/unittest/stattestmain.py |   2 +-
 tests/configs/switcheroo.py  |   3 ++-
 27 files changed, 129 insertions(+), 102 deletions(-)

diffs (truncated from 711 to 300 lines):

diff -r cd7f3a1dbf55 -r be62996c95d1 src/SConscript
--- a/src/SConscriptWed Nov 09 14:27:40 2016 -0600
+++ b/src/SConscriptFri Jan 27 12:40:01 2017 +
@@ -483,7 +483,7 @@
 if fullname == 'm5.objects':
 return self
 
-if fullname.startswith('m5.internal'):
+if fullname.startswith('_m5'):
 return None
 
 source = self.modules.get(fullname, None)
@@ -588,14 +588,14 @@
 
 code = code_formatter()
 code("""
-import m5.internal
+import _m5.core
 import m5.util
 
 buildEnv = m5.util.SmartDict($build_env)
 
-compileDate = m5.internal.core.compileDate
+compileDate = _m5.core.compileDate
 _globals = globals()
-for key,val in m5.internal.core.__dict__.iteritems():
+for key,val in _m5.core.__dict__.iteritems():
 if key.startswith('flag_'):
 flag = key[5:]
 _globals[flag] = val
@@ -773,13 +773,13 @@
 # Generate any needed param SWIG wrapper files
 params_i_files = []
 for name,param in sorted(params_to_swig.iteritems()):
-i_file = File('python/m5/internal/%s.i' % (param.swig_module_name()))
+i_file = File('python/_m5/%s.i' % (param.swig_module_name()))
 params_i_files.append(i_file)
 env.Command(i_file, Value(name),
 MakeAction(createParamSwigWrapper, Transform("SW PARAM")))
 env.Depends(i_file, depends)
 env.Depends(SWIG, i_file)
-SwigSource('m5.internal', i_file)
+SwigSource('_m5', i_file)
 
 # Generate all enum header files
 for name,enum in sorted(all_enums.iteritems()):
@@ -799,22 +799,22 @@
 env.Depends(hh_file, depends + extra_deps)
 env.Depends(SWIG, hh_file)
 
-i_file = File('python/m5/internal/enum_%s.i' % name)
+i_file = File('python/_m5/enum_%s.i' % name)
 env.Command(i_file, Value(name),
 MakeAction(createEnumSwigWrapper, Transform("ENUMSWIG")))
 env.Depends(i_file, depends + extra_deps)
 env.Depends(SWIG, i_file)
-SwigSource('m5.internal', i_file)
+SwigSource('_m5', i_file)
 
 # Generate SimObject SWIG wrapper files
 for name,simobj in sorted(sim_objects.iteritems()):
 py_source = PySource.modules[simobj.__module__]
 extra_deps = [ py_source.tnode ]
-i_file = File('python/m5/internal/param_%s.i' % name)
+i_file = File('python/_m5/param_%s.i' % name)
 env.Command(i_file, Value(name),
 MakeAction(createSimObjectSwigWrapper, Transform("SO SWIG")))
 env.Depends(i_file, depends + extra_deps)
-SwigSource('m5.internal', i_file)
+SwigSource('_m5', i_file)
 
 # Generate the main swig init file
 def makeEmbeddedSwigInit(package):
diff -r cd7f3a1dbf55 -r be62996c95d1 src/python/SConscript
--- a/src/python/SConscript Wed Nov 09 14:27:40 2016 -0600
+++ 

Re: [gem5-dev] changeset in gem5: syscall_emul: [patch 4/22] remove redundant M...

[Andreas Sandberg]

Hi Brandon,

Something bad (they hang) happened with the SE-mode ALPHA and SPARC
regressions the other day. A quick bisection suggest that this commit
was the first bad one. Could you have a look?

//Andreas

On 23/01/17 21:22, Brandon Potter wrote:

changeset cd7f3a1dbf55 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=cd7f3a1dbf55
description:
  syscall_emul: [patch 4/22] remove redundant M5_pid field from process

diffstat:

  src/arch/alpha/process.cc |   4 ++--
  src/arch/sparc/faults.cc  |   4 ++--
  src/sim/Process.py|  13 +++--
  src/sim/process.cc|  15 ++-
  src/sim/process.hh|  38 ++
  src/sim/system.cc |   3 ---
  src/sim/system.hh |   8 
  7 files changed, 35 insertions(+), 50 deletions(-)

diffs (243 lines):

diff -r 54436a1784dc -r cd7f3a1dbf55 src/arch/alpha/process.cc
--- a/src/arch/alpha/process.cc   Wed Nov 09 14:27:40 2016 -0600
+++ b/src/arch/alpha/process.cc   Wed Nov 09 14:27:40 2016 -0600
@@ -179,7 +179,7 @@
  AlphaLiveProcess::setupASNReg()
  {
  ThreadContext *tc = system->getThreadContext(contextIds[0]);
-tc->setMiscRegNoEffect(IPR_DTB_ASN, M5_pid << 57);
+tc->setMiscRegNoEffect(IPR_DTB_ASN, _pid << 57);
  }


@@ -187,7 +187,7 @@
  AlphaLiveProcess::loadState(CheckpointIn )
  {
  LiveProcess::loadState(cp);
-// need to set up ASN after unserialization since M5_pid value may
+// need to set up ASN after unserialization since _pid value may
  // come from checkpoint
  setupASNReg();
  }
diff -r 54436a1784dc -r cd7f3a1dbf55 src/arch/sparc/faults.cc
--- a/src/arch/sparc/faults.ccWed Nov 09 14:27:40 2016 -0600
+++ b/src/arch/sparc/faults.ccWed Nov 09 14:27:40 2016 -0600
@@ -630,7 +630,7 @@
  } else {
  Addr alignedVaddr = p->pTable->pageAlign(vaddr);
  tc->getITBPtr()->insert(alignedVaddr, 0 /*partition id*/,
-p->M5_pid /*context id*/, false, entry.pte);
+p->_pid /*context id*/, false, entry.pte);
  }
  }

@@ -654,7 +654,7 @@
  } else {
  Addr alignedVaddr = p->pTable->pageAlign(vaddr);
  tc->getDTBPtr()->insert(alignedVaddr, 0 /*partition id*/,
-p->M5_pid /*context id*/, false, entry.pte);
+p->_pid /*context id*/, false, entry.pte);
  }
  }

diff -r 54436a1784dc -r cd7f3a1dbf55 src/sim/Process.py
--- a/src/sim/Process.py  Wed Nov 09 14:27:40 2016 -0600
+++ b/src/sim/Process.py  Wed Nov 09 14:27:40 2016 -0600
@@ -43,6 +43,13 @@
  kvmInSE = Param.Bool('false', 'initialize the process for KvmCPU in SE')
  max_stack_size = Param.MemorySize('64MB', 'maximum size of the stack')

+uid = Param.Int(100, 'user id')
+euid = Param.Int(100, 'effective user id')
+gid = Param.Int(100, 'group id')
+egid = Param.Int(100, 'effective group id')
+pid = Param.Int(100, 'process id')
+ppid = Param.Int(99, 'parent process id')
+
  @classmethod
  def export_methods(cls, code):
  code('bool map(Addr vaddr, Addr paddr, int size, bool 
cacheable=true);')
@@ -60,12 +67,6 @@
  cmd = VectorParam.String("command line (executable plus arguments)")
  env = VectorParam.String([], "environment settings")
  cwd = Param.String('', "current working directory")
-uid = Param.Int(100, 'user id')
-euid = Param.Int(100, 'effective user id')
-gid = Param.Int(100, 'group id')
-egid = Param.Int(100, 'effective group id')
-pid = Param.Int(100, 'process id')
-ppid = Param.Int(99, 'parent process id')
  simpoint = Param.UInt64(0, 'simulation point at which to start 
simulation')
  drivers = VectorParam.EmulatedDriver([], 'Available emulated drivers')

diff -r 54436a1784dc -r cd7f3a1dbf55 src/sim/process.cc
--- a/src/sim/process.cc  Wed Nov 09 14:27:40 2016 -0600
+++ b/src/sim/process.cc  Wed Nov 09 14:27:40 2016 -0600
@@ -131,12 +131,11 @@
brk_point(0), stack_base(0), stack_size(0), stack_min(0),
max_stack_size(params->max_stack_size),
next_thread_stack_base(0),
-  M5_pid(system->allocatePID()),
useArchPT(params->useArchPT),
kvmInSE(params->kvmInSE),
pTable(useArchPT ?
-static_cast(new ArchPageTable(name(), M5_pid, 
system)) :
-static_cast(new FuncPageTable(name(), M5_pid)) ),
+static_cast(new ArchPageTable(name(), _pid, system)) :
+static_cast(new FuncPageTable(name(), _pid))),
initVirtMem(system->getSystemPort(), this,
SETranslatingPortProxy::Always),
fd_array(make_shared>()),
@@ -147,7 +146,10 @@
  {"cout",   STDOUT_FILENO},
  {"stdout", STDOUT_FILENO},
  {"cerr",   STDERR_FILENO},
-{"stderr", STDERR_FILENO}}
+{"stderr", STDERR_FILENO}},
+  _uid(params->uid), _euid(params->euid),
+  _gid(params->gid), _egid(params->egid),

Re: [gem5-dev] [gem5-users] gem5 build failure

[Pierre-Yves Péneau]

On 01/27/2017 01:20 PM, Andreas Sandberg wrote:
> Hi Pierre,
> 
> I send out an email to the dev list on the 12th of January (Header order
> issues) describing a similar issue we have in our CI system. I have an
> updated version of the style checker that enforces that Python.h is
> included first and plan to post it after lunch.

Oh, I didn't see this mail sorry. Problem solved then !

> I would like to avoid including Python.h in header files unless
> absolutely necessary. In general, we should try to keep dependencies
> within header files as small as possible to avoid wasting time on
> recompiling things.

I agree.

> Cheers,
> Andreas
> 
> 
> On 27/01/17 10:48, Pierre-Yves Péneau wrote:
>> I think I have found why this is not working. With the new refactoring
>> script, the header corresponding to the source file must be included
>> first. But, when Python.h is needed, it also must be included first to
>> avoid this error.
>>
>> So, I think there is two workaround:
>> i) the refactoring script should check if Python.h is needed and if so,
>> include it first and then include the header file.
>> ii) move the Python.h inclusion in the header file. The second one is
>> easier as it does not need to change the refactoring script. It also
>> sounds better to me.
>>
>> I tried the second solution and it's working. What do you think ?
>>
>> On 01/26/2017 06:05 PM, Pierre-Yves Péneau wrote:
>>> Hi all,
>>>
>>> I am trying to build the latest gem5 version and I get the error below.
>>>
 $ scons /var/tmp/gem5-current/build/X86/gem5.fast
>>> [snip]
>>>
   [ CXX] X86/python/swig/pyevent.cc -> .fo
 In file included from /usr/include/python2.7/pyconfig.h:6:0,
   from /usr/include/python2.7/Python.h:8,
   from /var/tmp/gem5-current/build/X86/sim/init.hh:34,
   from
 /var/tmp/gem5-current/build/X86/python/swig/pyevent.hh:35,
   from
 /var/tmp/gem5-current/build/X86/python/swig/pyevent.cc:31:
 /usr/include/python2.7/pyconfig-64.h:1182:0: error:
 "_POSIX_C_SOURCE" redefined [-Werror]
   #define _POSIX_C_SOURCE 200112L
   ^
 In file included from
 /usr/include/c++/4.8.2/x86_64-redhat-linux/bits/os_defines.h:39:0,
   from
 /usr/include/c++/4.8.2/x86_64-redhat-linux/bits/c++config.h:2097,
   from /usr/include/c++/4.8.2/utility:68,
   from /usr/include/c++/4.8.2/algorithm:60,
   from
 /var/tmp/gem5-current/build/X86/sim/eventq.hh:41,
   from
 /var/tmp/gem5-current/build/X86/python/swig/pyevent.hh:34,
   from
 /var/tmp/gem5-current/build/X86/python/swig/pyevent.cc:31:
 /usr/include/features.h:168:0: note: this is the location of the
 previous definition
   # define _POSIX_C_SOURCE 200809L
   ^
 In file included from /usr/include/python2.7/pyconfig.h:6:0,
   from /usr/include/python2.7/Python.h:8,
   from /var/tmp/gem5-current/build/X86/sim/init.hh:34,
   from
 /var/tmp/gem5-current/build/X86/python/swig/pyevent.hh:35,
   from
 /var/tmp/gem5-current/build/X86/python/swig/pyevent.cc:31:
 /usr/include/python2.7/pyconfig-64.h:1204:0: error: "_XOPEN_SOURCE"
 redefined [-Werror]
   #define _XOPEN_SOURCE 600
   ^
 In file included from
 /usr/include/c++/4.8.2/x86_64-redhat-linux/bits/os_defines.h:39:0,
   from
 /usr/include/c++/4.8.2/x86_64-redhat-linux/bits/c++config.h:2097,
   from /usr/include/c++/4.8.2/utility:68,
   from /usr/include/c++/4.8.2/algorithm:60,
   from
 /var/tmp/gem5-current/build/X86/sim/eventq.hh:41,
   from
 /var/tmp/gem5-current/build/X86/python/swig/pyevent.hh:34,
   from
 /var/tmp/gem5-current/build/X86/python/swig/pyevent.cc:31:
 /usr/include/features.h:170:0: note: this is the location of the
 previous definition
   # define _XOPEN_SOURCE 700
   ^
 cc1plus: all warnings being treated as errors
 scons: *** [/var/tmp/gem5-current/build/X86/python/swig/pyevent.fo]
 Error 1
 scons: building terminated because of errors.
>>> My last successful build before pulling the changes was in December. I
>>> am using gcc-4.8.5 and python 2.7.5. It seems related to python and
>>> variable redefinition. As far as I know, python 2.7 is supported by
>>> gem5, only python 2.6 has been dropped few months ago. Host is CentOS
>>> 7.2. Any idea of what's going on ? Thanks.
>>>
>>>
>>>
>>> ___
>>> gem5-users mailing list
>>> gem5-us...@gem5.org
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are 

Re: [gem5-dev] [gem5-users] gem5 build failure

[Andreas Sandberg]

Hi Pierre,

I send out an email to the dev list on the 12th of January (Header order
issues) describing a similar issue we have in our CI system. I have an
updated version of the style checker that enforces that Python.h is
included first and plan to post it after lunch.

I would like to avoid including Python.h in header files unless
absolutely necessary. In general, we should try to keep dependencies
within header files as small as possible to avoid wasting time on
recompiling things.

Cheers,
Andreas


On 27/01/17 10:48, Pierre-Yves Péneau wrote:

I think I have found why this is not working. With the new refactoring
script, the header corresponding to the source file must be included
first. But, when Python.h is needed, it also must be included first to
avoid this error.

So, I think there is two workaround:
i) the refactoring script should check if Python.h is needed and if so,
include it first and then include the header file.
ii) move the Python.h inclusion in the header file. The second one is
easier as it does not need to change the refactoring script. It also
sounds better to me.

I tried the second solution and it's working. What do you think ?

On 01/26/2017 06:05 PM, Pierre-Yves Péneau wrote:

Hi all,

I am trying to build the latest gem5 version and I get the error below.


$ scons /var/tmp/gem5-current/build/X86/gem5.fast

[snip]


  [ CXX] X86/python/swig/pyevent.cc -> .fo
In file included from /usr/include/python2.7/pyconfig.h:6:0,
  from /usr/include/python2.7/Python.h:8,
  from /var/tmp/gem5-current/build/X86/sim/init.hh:34,
  from 
/var/tmp/gem5-current/build/X86/python/swig/pyevent.hh:35,
  from 
/var/tmp/gem5-current/build/X86/python/swig/pyevent.cc:31:
/usr/include/python2.7/pyconfig-64.h:1182:0: error: "_POSIX_C_SOURCE" redefined 
[-Werror]
  #define _POSIX_C_SOURCE 200112L
  ^
In file included from 
/usr/include/c++/4.8.2/x86_64-redhat-linux/bits/os_defines.h:39:0,
  from 
/usr/include/c++/4.8.2/x86_64-redhat-linux/bits/c++config.h:2097,
  from /usr/include/c++/4.8.2/utility:68,
  from /usr/include/c++/4.8.2/algorithm:60,
  from /var/tmp/gem5-current/build/X86/sim/eventq.hh:41,
  from 
/var/tmp/gem5-current/build/X86/python/swig/pyevent.hh:34,
  from 
/var/tmp/gem5-current/build/X86/python/swig/pyevent.cc:31:
/usr/include/features.h:168:0: note: this is the location of the previous 
definition
  # define _POSIX_C_SOURCE 200809L
  ^
In file included from /usr/include/python2.7/pyconfig.h:6:0,
  from /usr/include/python2.7/Python.h:8,
  from /var/tmp/gem5-current/build/X86/sim/init.hh:34,
  from 
/var/tmp/gem5-current/build/X86/python/swig/pyevent.hh:35,
  from 
/var/tmp/gem5-current/build/X86/python/swig/pyevent.cc:31:
/usr/include/python2.7/pyconfig-64.h:1204:0: error: "_XOPEN_SOURCE" redefined 
[-Werror]
  #define _XOPEN_SOURCE 600
  ^
In file included from 
/usr/include/c++/4.8.2/x86_64-redhat-linux/bits/os_defines.h:39:0,
  from 
/usr/include/c++/4.8.2/x86_64-redhat-linux/bits/c++config.h:2097,
  from /usr/include/c++/4.8.2/utility:68,
  from /usr/include/c++/4.8.2/algorithm:60,
  from /var/tmp/gem5-current/build/X86/sim/eventq.hh:41,
  from 
/var/tmp/gem5-current/build/X86/python/swig/pyevent.hh:34,
  from 
/var/tmp/gem5-current/build/X86/python/swig/pyevent.cc:31:
/usr/include/features.h:170:0: note: this is the location of the previous 
definition
  # define _XOPEN_SOURCE 700
  ^
cc1plus: all warnings being treated as errors
scons: *** [/var/tmp/gem5-current/build/X86/python/swig/pyevent.fo] Error 1
scons: building terminated because of errors.

My last successful build before pulling the changes was in December. I
am using gcc-4.8.5 and python 2.7.5. It seems related to python and
variable redefinition. As far as I know, python 2.7 is supported by
gem5, only python 2.6 has been dropped few months ago. Host is CentOS
7.2. Any idea of what's going on ? Thanks.



___
gem5-users mailing list
gem5-us...@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users



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] [gem5-users] gem5 build failure

[Pierre-Yves Péneau]

I think I have found why this is not working. With the new refactoring
script, the header corresponding to the source file must be included
first. But, when Python.h is needed, it also must be included first to
avoid this error.

So, I think there is two workaround:
i) the refactoring script should check if Python.h is needed and if so,
include it first and then include the header file.
ii) move the Python.h inclusion in the header file. The second one is
easier as it does not need to change the refactoring script. It also
sounds better to me.

I tried the second solution and it's working. What do you think ?

On 01/26/2017 06:05 PM, Pierre-Yves Péneau wrote:
> Hi all,
> 
> I am trying to build the latest gem5 version and I get the error below.
> 
>> $ scons /var/tmp/gem5-current/build/X86/gem5.fast
> 
> [snip]
> 
>>  [ CXX] X86/python/swig/pyevent.cc -> .fo
>> In file included from /usr/include/python2.7/pyconfig.h:6:0,
>>  from /usr/include/python2.7/Python.h:8,
>>  from /var/tmp/gem5-current/build/X86/sim/init.hh:34,
>>  from 
>> /var/tmp/gem5-current/build/X86/python/swig/pyevent.hh:35,
>>  from 
>> /var/tmp/gem5-current/build/X86/python/swig/pyevent.cc:31:
>> /usr/include/python2.7/pyconfig-64.h:1182:0: error: "_POSIX_C_SOURCE" 
>> redefined [-Werror]
>>  #define _POSIX_C_SOURCE 200112L
>>  ^
>> In file included from 
>> /usr/include/c++/4.8.2/x86_64-redhat-linux/bits/os_defines.h:39:0,
>>  from 
>> /usr/include/c++/4.8.2/x86_64-redhat-linux/bits/c++config.h:2097,
>>  from /usr/include/c++/4.8.2/utility:68,
>>  from /usr/include/c++/4.8.2/algorithm:60,
>>  from /var/tmp/gem5-current/build/X86/sim/eventq.hh:41,
>>  from 
>> /var/tmp/gem5-current/build/X86/python/swig/pyevent.hh:34,
>>  from 
>> /var/tmp/gem5-current/build/X86/python/swig/pyevent.cc:31:
>> /usr/include/features.h:168:0: note: this is the location of the previous 
>> definition
>>  # define _POSIX_C_SOURCE 200809L
>>  ^
>> In file included from /usr/include/python2.7/pyconfig.h:6:0,
>>  from /usr/include/python2.7/Python.h:8,
>>  from /var/tmp/gem5-current/build/X86/sim/init.hh:34,
>>  from 
>> /var/tmp/gem5-current/build/X86/python/swig/pyevent.hh:35,
>>  from 
>> /var/tmp/gem5-current/build/X86/python/swig/pyevent.cc:31:
>> /usr/include/python2.7/pyconfig-64.h:1204:0: error: "_XOPEN_SOURCE" 
>> redefined [-Werror]
>>  #define _XOPEN_SOURCE 600
>>  ^
>> In file included from 
>> /usr/include/c++/4.8.2/x86_64-redhat-linux/bits/os_defines.h:39:0,
>>  from 
>> /usr/include/c++/4.8.2/x86_64-redhat-linux/bits/c++config.h:2097,
>>  from /usr/include/c++/4.8.2/utility:68,
>>  from /usr/include/c++/4.8.2/algorithm:60,
>>  from /var/tmp/gem5-current/build/X86/sim/eventq.hh:41,
>>  from 
>> /var/tmp/gem5-current/build/X86/python/swig/pyevent.hh:34,
>>  from 
>> /var/tmp/gem5-current/build/X86/python/swig/pyevent.cc:31:
>> /usr/include/features.h:170:0: note: this is the location of the previous 
>> definition
>>  # define _XOPEN_SOURCE 700
>>  ^
>> cc1plus: all warnings being treated as errors
>> scons: *** [/var/tmp/gem5-current/build/X86/python/swig/pyevent.fo] Error 1
>> scons: building terminated because of errors.
> 
> My last successful build before pulling the changes was in December. I
> am using gcc-4.8.5 and python 2.7.5. It seems related to python and
> variable redefinition. As far as I know, python 2.7 is supported by
> gem5, only python 2.6 has been dropped few months ago. Host is CentOS
> 7.2. Any idea of what's going on ? Thanks.
> 
> 
> 
> ___
> gem5-users mailing list
> gem5-us...@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
> 

-- 
+-+
| Pierre-Yves Péneau - PhD student |  first.last at lirmm.fr  |
| LIRMM / CNRS - SYSMIC team   |+ 33 4 67 41 86 33|
| Building 4 Office H2.2   |http://walafc0.org|
+-+

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev