[gem5-dev] Re: Adding an extension object to Packet-s

[Gabe Black via gem5-dev]

This is to mimic systemc's protocol extension mechanism, where you can add
side channel info to a transaction. Sender state is more for keeping track
of information the sender needs related to a particular packet, rather than
to send additional state down the line to other consumers. For instance,
there is no identifier in a SenderState, since it is assumed when you get a
response back, your SenderState is at the top of the stack. There would be
no real way to determine which SenderState matched a particular extension
except dynamic casting everything to search for a particular type, and even
then you could have false hits from extension subclasses.

Gabe

On Mon, Apr 18, 2022 at 4:49 PM Jason Lowe-Power 
wrote:

> Hi Yan,
>
> Can you use the Packet::pushSenderState(), popSenderState(), etc
> functions? This is a stack instead of a linked-list, but it may work for
> your use case. See
> https://gem5.googlesource.com/public/gem5/+/refs/heads/stable/src/mem/packet.hh#440
> for more information.
>
> The idea with that interface is that an object can push "sender state"
> into the packet, send the packet on to some other receiver, and then when
> you get a response you can pop the sender state back off. You can also
> use findNextSenderState to get any sender state from the stack.
>
> To use it, you can extend the class SenderState to hold any state that
> you'd like.
>
> Let me know if this isn't what you're looking for. It sounds quite similar
> to what you're proposing. If we can extend that interface, it would
> probably be better than adding something totally new.
>
> Cheers,
> Jason
>
> On Thu, Apr 14, 2022 at 1:08 AM Yan Lee via gem5-dev 
> wrote:
>
>> Hi Gabe and everyone,
>>
>> Thanks Gabe for bringing this up. Currently I am making a model in AXI
>> protocol and this model will need the AxUser and AxProt fields in the AXI
>> protocol. The packet in gem5 cannot carry additional information except the
>> actual read/write data. I think we can have the extension mechanism in our
>> gem5 packet just like the way in SystemC. Therefore, we can simulate some
>> protocol-related behavior with this extension in each gem5 packet.
>>
>> I think we can have an array-based or linked-list-based extension
>> mechanism in gem5 packet. That is, we can have multiple extensions in one
>> packet and may be increased during the transaction. But we can discuss the
>> way of searching for one extension. In systemc, it uses linear search to
>> find if one extension exists or not.
>>
>> Look forward to any feedback or ideas, and thanks for your sharing.
>>
>> Yan
>>
>> On Thu, Apr 14, 2022 at 3:37 PM Gabe Black  wrote:
>>
>>> Hi folks. Yan Lee, a Google colleague of mine, is interested in adding
>>> one or more extension objects to gem5 Packet. Systemc has a mechanism like
>>> this already, and it's come up a few times where we've wanted to have
>>> something like this on the gem5 side as well.
>>>
>>> Yan, can you please talk about the problem you're trying to solve, and
>>> the mechanism you want to add to handle it?
>>>
>>> Gabe
>>>
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Adding an extension object to Packet-s

[Gabe Black via gem5-dev]

Hi folks. Yan Lee, a Google colleague of mine, is interested in adding one
or more extension objects to gem5 Packet. Systemc has a mechanism like this
already, and it's come up a few times where we've wanted to have something
like this on the gem5 side as well.

Yan, can you please talk about the problem you're trying to solve, and the
mechanism you want to add to handle it?

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #189

[Gabe Black via gem5-dev]

https://gem5-review.googlesource.com/c/public/gem5/+/58633

On Tue, Apr 5, 2022 at 7:52 PM Jason Lowe-Power  wrote:

> That sounds like a great middle ground.
>
> We could *probably* drop support for 18.04 in v22.0, but we should have a
> broader discussion and make sure that's our intention. It's probably not
> great to drop support for an OS to get the nightly tests to pass :).
>
> Cheers,
> Jason
>
> On Tue, Apr 5, 2022 at 3:43 PM Gabe Black  wrote:
>
>> Well, in that case, we could detect version 3.0.1 (there is a function to
>> get the version I believe) and do the monkey patch they suggest in the
>> email. The fix was just adding that little function they show, which did
>> not exist at all in version 3.0.1. I would have to look up exactly how you
>> monkey patch things in python, but I think that's all that should be
>> necessary. When we drop support for 3.0.1, then we can drop our hack fix
>> also.
>>
>> Gabe
>>
>> On Tue, Apr 5, 2022 at 3:12 PM Bobby Bruce  wrote:
>>
>>> I think we need to have a little discussion on this. The problem with
>>> increasing the scons version is we support Ubuntu 18.04 (Official
>>> end-of-support not until April 2023) which if you run `apt install scons`
>>> will give you v3.0.1. So, increasing this the scons version requirements
>>> will hurt these users.
>>>
>>> I think our solutions here are either:
>>>
>>> 1) Drop support for Ubuntu 18.04 in the next release.
>>> 2) Have a work-around available for Ubuntu 18.04 users.
>>> 3) Maintain v3.01 as the minimum scons dependency and work around that.
>>>
>>> Unfortunately, none of these are very appealing.
>>>
>>> In the interests of not having the compiler tests fail for another
>>> night, can we revert this commit until we figure out exactly what we want
>>> to do?
>>>
>>> --
>>> Dr. Bobby R. Bruce
>>> Room 3050,
>>> Kemper Hall, UC Davis
>>> Davis,
>>> CA, 95616
>>>
>>> web: https://www.bobbybruce.net
>>>
>>>
>>> On Tue, Apr 5, 2022 at 1:34 PM Gabe Black  wrote:
>>>
 The bug in SCons was fixed in version 3.0.2. I have a CL which updates
 the required version here:

 https://gem5-review.googlesource.com/c/public/gem5/+/58629

 I'm assuming some docker configuration something will need to be
 updated to use SCons version 3.0.2 instead of the 3.0.1 it seems to be
 using.

 Gabe

 On Tue, Apr 5, 2022 at 4:13 PM Gabe Black  wrote:

> I think this is actually a bug in SCons. This docker image seems to be
> using the minimum version of it we support, which I think is where the
> problem is coming from and not the compiler versions. There is a
> "fix"/workaround in this email thread which I haven't tried yet, and which
> is a bit of a hack.
>
> https://pairlist2.pair.net/pipermail/scons-dev/2018-October/004766.html
>
> I'm not sure when this bug would have been fixed, or what the best way
> to check if we need to monkey patch around it. If we can find the version
> of SCons where it was fixed and it's not that much more recent, bumping up
> past it may be the easiest.
>
> I think the reason this becomes visible with the change above is that
> more SCons code is run unconditionally, and so the fast model code is now
> being run in the test environment where it is disabled and just skipped
> wholesale before.
>
> Gabe
>
> On Tue, Apr 5, 2022 at 3:06 AM Gabe Black 
> wrote:
>
>> Yes, I'll take a look.
>>
>> Gabe
>>
>> On Mon, Apr 4, 2022 at 3:02 PM Bobby Bruce 
>> wrote:
>>
>>> I don't fully understand the issue, but after doing a bisect, the
>>> commit causing these issues is
>>> https://gem5-review.googlesource.com/c/public/gem5/+/58356.
>>>
>>> To reproduce locally:
>>>
>>> ```
>>> docker run -u $UID:$GID --rm -v $(pwd):$(pwd) -w $(pwd)
>>> gcr.io/gem5-test/clang-version-9 python3 /usr/bin/scons
>>> build/NULL/gem5.opt -j`nproc`
>>> ```
>>>
>>> which will return:
>>>
>>> ```
>>> scons: *** [build/RISCV/gem5.opt] TypeError `unhashable type:
>>> 'Literal'' trying to evaluate `${_concat(RPATHPREFIX, RPATH, 
>>> RPATHSUFFIX,
>>> __env__)}'
>>> ```
>>>
>>>
>>> This only appears to affect older versions of clang and gcc, though
>>> we still support these so this needs to be fixed.
>>>
>>>
>>> Reverting the offending commit, `git revert
>>> 3b6ea3dfa9055fcd7fb83738b11d00ac00f813ce`, does appear to fix this 
>>> problem
>>> on the develop branch.
>>>
>>>
>>> @Gabe: Can you have a look into this and see if there's any better
>>> fix than just reverting this change?
>>>
>>> --
>>> Kind regards,
>>> Bobby
>>> --
>>> Dr. Bobby R. Bruce
>>> Room 3050,
>>> Kemper Hall, UC Davis
>>> Davis,
>>> CA, 95616
>>>
>>> web: https://www.bobbybruce.net
>>>
>>>
>>> On Fri, Apr 1, 2022 at 

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #189

[Gabe Black via gem5-dev]

Well, in that case, we could detect version 3.0.1 (there is a function to
get the version I believe) and do the monkey patch they suggest in the
email. The fix was just adding that little function they show, which did
not exist at all in version 3.0.1. I would have to look up exactly how you
monkey patch things in python, but I think that's all that should be
necessary. When we drop support for 3.0.1, then we can drop our hack fix
also.

Gabe

On Tue, Apr 5, 2022 at 3:12 PM Bobby Bruce  wrote:

> I think we need to have a little discussion on this. The problem with
> increasing the scons version is we support Ubuntu 18.04 (Official
> end-of-support not until April 2023) which if you run `apt install scons`
> will give you v3.0.1. So, increasing this the scons version requirements
> will hurt these users.
>
> I think our solutions here are either:
>
> 1) Drop support for Ubuntu 18.04 in the next release.
> 2) Have a work-around available for Ubuntu 18.04 users.
> 3) Maintain v3.01 as the minimum scons dependency and work around that.
>
> Unfortunately, none of these are very appealing.
>
> In the interests of not having the compiler tests fail for another night,
> can we revert this commit until we figure out exactly what we want to do?
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Tue, Apr 5, 2022 at 1:34 PM Gabe Black  wrote:
>
>> The bug in SCons was fixed in version 3.0.2. I have a CL which updates
>> the required version here:
>>
>> https://gem5-review.googlesource.com/c/public/gem5/+/58629
>>
>> I'm assuming some docker configuration something will need to be updated
>> to use SCons version 3.0.2 instead of the 3.0.1 it seems to be using.
>>
>> Gabe
>>
>> On Tue, Apr 5, 2022 at 4:13 PM Gabe Black  wrote:
>>
>>> I think this is actually a bug in SCons. This docker image seems to be
>>> using the minimum version of it we support, which I think is where the
>>> problem is coming from and not the compiler versions. There is a
>>> "fix"/workaround in this email thread which I haven't tried yet, and which
>>> is a bit of a hack.
>>>
>>> https://pairlist2.pair.net/pipermail/scons-dev/2018-October/004766.html
>>>
>>> I'm not sure when this bug would have been fixed, or what the best way
>>> to check if we need to monkey patch around it. If we can find the version
>>> of SCons where it was fixed and it's not that much more recent, bumping up
>>> past it may be the easiest.
>>>
>>> I think the reason this becomes visible with the change above is that
>>> more SCons code is run unconditionally, and so the fast model code is now
>>> being run in the test environment where it is disabled and just skipped
>>> wholesale before.
>>>
>>> Gabe
>>>
>>> On Tue, Apr 5, 2022 at 3:06 AM Gabe Black  wrote:
>>>
 Yes, I'll take a look.

 Gabe

 On Mon, Apr 4, 2022 at 3:02 PM Bobby Bruce  wrote:

> I don't fully understand the issue, but after doing a bisect, the
> commit causing these issues is
> https://gem5-review.googlesource.com/c/public/gem5/+/58356.
>
> To reproduce locally:
>
> ```
> docker run -u $UID:$GID --rm -v $(pwd):$(pwd) -w $(pwd)
> gcr.io/gem5-test/clang-version-9 python3 /usr/bin/scons
> build/NULL/gem5.opt -j`nproc`
> ```
>
> which will return:
>
> ```
> scons: *** [build/RISCV/gem5.opt] TypeError `unhashable type:
> 'Literal'' trying to evaluate `${_concat(RPATHPREFIX, RPATH, RPATHSUFFIX,
> __env__)}'
> ```
>
>
> This only appears to affect older versions of clang and gcc, though we
> still support these so this needs to be fixed.
>
>
> Reverting the offending commit, `git revert
> 3b6ea3dfa9055fcd7fb83738b11d00ac00f813ce`, does appear to fix this problem
> on the develop branch.
>
>
> @Gabe: Can you have a look into this and see if there's any better fix
> than just reverting this change?
>
> --
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Fri, Apr 1, 2022 at 8:12 AM Jason Lowe-Power via gem5-dev <
> gem5-dev@gem5.org> wrote:
> >
> > Interesting errors. See
> https://jenkins.gem5.org/job/compiler-checks/189/artifact/compile-test-out/clang-version-9/
> for more info. I think this is a scons error, as it looks like python.
> >
> > scons: *** [build/RISCV/gem5.opt] TypeError `unhashable type:
> 'Literal'' trying to evaluate `${_concat(RPATHPREFIX, RPATH, RPATHSUFFIX,
> __env__)}'
> >
> >
> >
> >
> > On Fri, Apr 1, 2022 at 5:21 AM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
> >>
> >> See <
> https://jenkins.gem5.org/job/compiler-checks/189/display/redirect?page=changes
> >
> >>
> >> Changes:
> >>
> >> 

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #189

[Gabe Black via gem5-dev]

The bug in SCons was fixed in version 3.0.2. I have a CL which updates the
required version here:

https://gem5-review.googlesource.com/c/public/gem5/+/58629

I'm assuming some docker configuration something will need to be updated to
use SCons version 3.0.2 instead of the 3.0.1 it seems to be using.

Gabe

On Tue, Apr 5, 2022 at 4:13 PM Gabe Black  wrote:

> I think this is actually a bug in SCons. This docker image seems to be
> using the minimum version of it we support, which I think is where the
> problem is coming from and not the compiler versions. There is a
> "fix"/workaround in this email thread which I haven't tried yet, and which
> is a bit of a hack.
>
> https://pairlist2.pair.net/pipermail/scons-dev/2018-October/004766.html
>
> I'm not sure when this bug would have been fixed, or what the best way to
> check if we need to monkey patch around it. If we can find the version of
> SCons where it was fixed and it's not that much more recent, bumping up
> past it may be the easiest.
>
> I think the reason this becomes visible with the change above is that more
> SCons code is run unconditionally, and so the fast model code is now being
> run in the test environment where it is disabled and just skipped wholesale
> before.
>
> Gabe
>
> On Tue, Apr 5, 2022 at 3:06 AM Gabe Black  wrote:
>
>> Yes, I'll take a look.
>>
>> Gabe
>>
>> On Mon, Apr 4, 2022 at 3:02 PM Bobby Bruce  wrote:
>>
>>> I don't fully understand the issue, but after doing a bisect, the commit
>>> causing these issues is
>>> https://gem5-review.googlesource.com/c/public/gem5/+/58356.
>>>
>>> To reproduce locally:
>>>
>>> ```
>>> docker run -u $UID:$GID --rm -v $(pwd):$(pwd) -w $(pwd)
>>> gcr.io/gem5-test/clang-version-9 python3 /usr/bin/scons
>>> build/NULL/gem5.opt -j`nproc`
>>> ```
>>>
>>> which will return:
>>>
>>> ```
>>> scons: *** [build/RISCV/gem5.opt] TypeError `unhashable type: 'Literal''
>>> trying to evaluate `${_concat(RPATHPREFIX, RPATH, RPATHSUFFIX, __env__)}'
>>> ```
>>>
>>>
>>> This only appears to affect older versions of clang and gcc, though we
>>> still support these so this needs to be fixed.
>>>
>>>
>>> Reverting the offending commit, `git revert
>>> 3b6ea3dfa9055fcd7fb83738b11d00ac00f813ce`, does appear to fix this problem
>>> on the develop branch.
>>>
>>>
>>> @Gabe: Can you have a look into this and see if there's any better fix
>>> than just reverting this change?
>>>
>>> --
>>> Kind regards,
>>> Bobby
>>> --
>>> Dr. Bobby R. Bruce
>>> Room 3050,
>>> Kemper Hall, UC Davis
>>> Davis,
>>> CA, 95616
>>>
>>> web: https://www.bobbybruce.net
>>>
>>>
>>> On Fri, Apr 1, 2022 at 8:12 AM Jason Lowe-Power via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>> >
>>> > Interesting errors. See
>>> https://jenkins.gem5.org/job/compiler-checks/189/artifact/compile-test-out/clang-version-9/
>>> for more info. I think this is a scons error, as it looks like python.
>>> >
>>> > scons: *** [build/RISCV/gem5.opt] TypeError `unhashable type:
>>> 'Literal'' trying to evaluate `${_concat(RPATHPREFIX, RPATH, RPATHSUFFIX,
>>> __env__)}'
>>> >
>>> >
>>> >
>>> >
>>> > On Fri, Apr 1, 2022 at 5:21 AM jenkins-no-reply--- via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>> >>
>>> >> See <
>>> https://jenkins.gem5.org/job/compiler-checks/189/display/redirect?page=changes
>>> >
>>> >>
>>> >> Changes:
>>> >>
>>> >> [gabe.black] scons: Remove an error check from the ProtoBuf
>>> declare-er.
>>> >>
>>> >> [yenlinlai] scons: Allow sources and libs called multiple times
>>> >>
>>> >> [gabe.black] scons: Add a priority field to the SourceLib construct.
>>> >>
>>> >> [gabe.black] scons: Get rid of an unused fast model variable.
>>> >>
>>> >> [gabe.black] scons: Tone down a fast model error into a warning.
>>> >>
>>> >> [gabe.black] scons: Stop the fast model project file parser from
>>> writing files.
>>> >>
>>> >> [gabe.black] scons: Rework the fastmodel extract_var helper.
>>> >>
>>> >> [gabe.black] scons: Only warn about not finding fast model libs if
>>> it's enabled.
>>> >>
>>> >> [gabe.black] scons: Add a tag for arm fastmodel and use it.
>>> >>
>>> >>
>>> >> --
>>> >> Started by timer
>>> >> Running as SYSTEM
>>> >> Building in workspace <
>>> https://jenkins.gem5.org/job/compiler-checks/ws/>
>>> >> The recommended git tool is: NONE
>>> >> No credentials specified
>>> >>  > git rev-parse --resolve-git-dir <
>>> https://jenkins.gem5.org/job/compiler-checks/ws/.git> # timeout=10
>>> >> Fetching changes from the remote Git repository
>>> >>  > git config remote.origin.url
>>> https://gem5.googlesource.com/public/gem5 # timeout=10
>>> >> Fetching upstream changes from
>>> https://gem5.googlesource.com/public/gem5
>>> >>  > git --version # timeout=10
>>> >>  > git --version # 'git version 2.25.1'
>>> >>  > git fetch --tags --force --progress --
>>> https://gem5.googlesource.com/public/gem5
>>> +refs/heads/*:refs/remotes/origin/* # timeout=10
>>> >>  > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #189

[Gabe Black via gem5-dev]

I think this is actually a bug in SCons. This docker image seems to be
using the minimum version of it we support, which I think is where the
problem is coming from and not the compiler versions. There is a
"fix"/workaround in this email thread which I haven't tried yet, and which
is a bit of a hack.

https://pairlist2.pair.net/pipermail/scons-dev/2018-October/004766.html

I'm not sure when this bug would have been fixed, or what the best way to
check if we need to monkey patch around it. If we can find the version of
SCons where it was fixed and it's not that much more recent, bumping up
past it may be the easiest.

I think the reason this becomes visible with the change above is that more
SCons code is run unconditionally, and so the fast model code is now being
run in the test environment where it is disabled and just skipped wholesale
before.

Gabe

On Tue, Apr 5, 2022 at 3:06 AM Gabe Black  wrote:

> Yes, I'll take a look.
>
> Gabe
>
> On Mon, Apr 4, 2022 at 3:02 PM Bobby Bruce  wrote:
>
>> I don't fully understand the issue, but after doing a bisect, the commit
>> causing these issues is
>> https://gem5-review.googlesource.com/c/public/gem5/+/58356.
>>
>> To reproduce locally:
>>
>> ```
>> docker run -u $UID:$GID --rm -v $(pwd):$(pwd) -w $(pwd)
>> gcr.io/gem5-test/clang-version-9 python3 /usr/bin/scons
>> build/NULL/gem5.opt -j`nproc`
>> ```
>>
>> which will return:
>>
>> ```
>> scons: *** [build/RISCV/gem5.opt] TypeError `unhashable type: 'Literal''
>> trying to evaluate `${_concat(RPATHPREFIX, RPATH, RPATHSUFFIX, __env__)}'
>> ```
>>
>>
>> This only appears to affect older versions of clang and gcc, though we
>> still support these so this needs to be fixed.
>>
>>
>> Reverting the offending commit, `git revert
>> 3b6ea3dfa9055fcd7fb83738b11d00ac00f813ce`, does appear to fix this problem
>> on the develop branch.
>>
>>
>> @Gabe: Can you have a look into this and see if there's any better fix
>> than just reverting this change?
>>
>> --
>> Kind regards,
>> Bobby
>> --
>> Dr. Bobby R. Bruce
>> Room 3050,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>>
>>
>> On Fri, Apr 1, 2022 at 8:12 AM Jason Lowe-Power via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>> >
>> > Interesting errors. See
>> https://jenkins.gem5.org/job/compiler-checks/189/artifact/compile-test-out/clang-version-9/
>> for more info. I think this is a scons error, as it looks like python.
>> >
>> > scons: *** [build/RISCV/gem5.opt] TypeError `unhashable type:
>> 'Literal'' trying to evaluate `${_concat(RPATHPREFIX, RPATH, RPATHSUFFIX,
>> __env__)}'
>> >
>> >
>> >
>> >
>> > On Fri, Apr 1, 2022 at 5:21 AM jenkins-no-reply--- via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>> >>
>> >> See <
>> https://jenkins.gem5.org/job/compiler-checks/189/display/redirect?page=changes
>> >
>> >>
>> >> Changes:
>> >>
>> >> [gabe.black] scons: Remove an error check from the ProtoBuf declare-er.
>> >>
>> >> [yenlinlai] scons: Allow sources and libs called multiple times
>> >>
>> >> [gabe.black] scons: Add a priority field to the SourceLib construct.
>> >>
>> >> [gabe.black] scons: Get rid of an unused fast model variable.
>> >>
>> >> [gabe.black] scons: Tone down a fast model error into a warning.
>> >>
>> >> [gabe.black] scons: Stop the fast model project file parser from
>> writing files.
>> >>
>> >> [gabe.black] scons: Rework the fastmodel extract_var helper.
>> >>
>> >> [gabe.black] scons: Only warn about not finding fast model libs if
>> it's enabled.
>> >>
>> >> [gabe.black] scons: Add a tag for arm fastmodel and use it.
>> >>
>> >>
>> >> --
>> >> Started by timer
>> >> Running as SYSTEM
>> >> Building in workspace <
>> https://jenkins.gem5.org/job/compiler-checks/ws/>
>> >> The recommended git tool is: NONE
>> >> No credentials specified
>> >>  > git rev-parse --resolve-git-dir <
>> https://jenkins.gem5.org/job/compiler-checks/ws/.git> # timeout=10
>> >> Fetching changes from the remote Git repository
>> >>  > git config remote.origin.url
>> https://gem5.googlesource.com/public/gem5 # timeout=10
>> >> Fetching upstream changes from
>> https://gem5.googlesource.com/public/gem5
>> >>  > git --version # timeout=10
>> >>  > git --version # 'git version 2.25.1'
>> >>  > git fetch --tags --force --progress --
>> https://gem5.googlesource.com/public/gem5
>> +refs/heads/*:refs/remotes/origin/* # timeout=10
>> >>  > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
>> >> Checking out Revision 3b6ea3dfa9055fcd7fb83738b11d00ac00f813ce
>> (refs/remotes/origin/develop)
>> >>  > git config core.sparsecheckout # timeout=10
>> >>  > git checkout -f 3b6ea3dfa9055fcd7fb83738b11d00ac00f813ce #
>> timeout=10
>> >> Commit message: "scons: Add a tag for arm fastmodel and use it."
>> >>  > git rev-list --no-walk 118b069d5d238c68afbe29d11878137746b3c375 #
>> timeout=10
>> >> [Checks API] No suitable checks publisher found.
>> >> [compiler-checks] $ /bin/sh -xe 

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #189

[Gabe Black via gem5-dev]

Yes, I'll take a look.

Gabe

On Mon, Apr 4, 2022 at 3:02 PM Bobby Bruce  wrote:

> I don't fully understand the issue, but after doing a bisect, the commit
> causing these issues is
> https://gem5-review.googlesource.com/c/public/gem5/+/58356.
>
> To reproduce locally:
>
> ```
> docker run -u $UID:$GID --rm -v $(pwd):$(pwd) -w $(pwd)
> gcr.io/gem5-test/clang-version-9 python3 /usr/bin/scons
> build/NULL/gem5.opt -j`nproc`
> ```
>
> which will return:
>
> ```
> scons: *** [build/RISCV/gem5.opt] TypeError `unhashable type: 'Literal''
> trying to evaluate `${_concat(RPATHPREFIX, RPATH, RPATHSUFFIX, __env__)}'
> ```
>
>
> This only appears to affect older versions of clang and gcc, though we
> still support these so this needs to be fixed.
>
>
> Reverting the offending commit, `git revert
> 3b6ea3dfa9055fcd7fb83738b11d00ac00f813ce`, does appear to fix this problem
> on the develop branch.
>
>
> @Gabe: Can you have a look into this and see if there's any better fix
> than just reverting this change?
>
> --
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Fri, Apr 1, 2022 at 8:12 AM Jason Lowe-Power via gem5-dev <
> gem5-dev@gem5.org> wrote:
> >
> > Interesting errors. See
> https://jenkins.gem5.org/job/compiler-checks/189/artifact/compile-test-out/clang-version-9/
> for more info. I think this is a scons error, as it looks like python.
> >
> > scons: *** [build/RISCV/gem5.opt] TypeError `unhashable type: 'Literal''
> trying to evaluate `${_concat(RPATHPREFIX, RPATH, RPATHSUFFIX, __env__)}'
> >
> >
> >
> >
> > On Fri, Apr 1, 2022 at 5:21 AM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
> >>
> >> See <
> https://jenkins.gem5.org/job/compiler-checks/189/display/redirect?page=changes
> >
> >>
> >> Changes:
> >>
> >> [gabe.black] scons: Remove an error check from the ProtoBuf declare-er.
> >>
> >> [yenlinlai] scons: Allow sources and libs called multiple times
> >>
> >> [gabe.black] scons: Add a priority field to the SourceLib construct.
> >>
> >> [gabe.black] scons: Get rid of an unused fast model variable.
> >>
> >> [gabe.black] scons: Tone down a fast model error into a warning.
> >>
> >> [gabe.black] scons: Stop the fast model project file parser from
> writing files.
> >>
> >> [gabe.black] scons: Rework the fastmodel extract_var helper.
> >>
> >> [gabe.black] scons: Only warn about not finding fast model libs if it's
> enabled.
> >>
> >> [gabe.black] scons: Add a tag for arm fastmodel and use it.
> >>
> >>
> >> --
> >> Started by timer
> >> Running as SYSTEM
> >> Building in workspace  >
> >> The recommended git tool is: NONE
> >> No credentials specified
> >>  > git rev-parse --resolve-git-dir <
> https://jenkins.gem5.org/job/compiler-checks/ws/.git> # timeout=10
> >> Fetching changes from the remote Git repository
> >>  > git config remote.origin.url
> https://gem5.googlesource.com/public/gem5 # timeout=10
> >> Fetching upstream changes from
> https://gem5.googlesource.com/public/gem5
> >>  > git --version # timeout=10
> >>  > git --version # 'git version 2.25.1'
> >>  > git fetch --tags --force --progress --
> https://gem5.googlesource.com/public/gem5
> +refs/heads/*:refs/remotes/origin/* # timeout=10
> >>  > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
> >> Checking out Revision 3b6ea3dfa9055fcd7fb83738b11d00ac00f813ce
> (refs/remotes/origin/develop)
> >>  > git config core.sparsecheckout # timeout=10
> >>  > git checkout -f 3b6ea3dfa9055fcd7fb83738b11d00ac00f813ce # timeout=10
> >> Commit message: "scons: Add a tag for arm fastmodel and use it."
> >>  > git rev-list --no-walk 118b069d5d238c68afbe29d11878137746b3c375 #
> timeout=10
> >> [Checks API] No suitable checks publisher found.
> >> [compiler-checks] $ /bin/sh -xe /tmp/jenkins10877671131247552434.sh
> >> + ./tests/compiler-tests.sh -j 16
> >> Starting build tests with 'gcc-version-11'...
> >> 'gcc-version-11' was found in the comprehensive tests. All ISAs will be
> built.
> >>   * Building target 'X86_MI_example.opt' with 'gcc-version-11'...
> >> Done.
> >>   * Building target 'X86_MI_example.fast' with 'gcc-version-11'...
> >> Done.
> >>   * Building target 'ARM_MOESI_hammer.opt' with 'gcc-version-11'...
> >> Done.
> >>   * Building target 'ARM_MOESI_hammer.fast' with 'gcc-version-11'...
> >> Done.
> >>   * Building target 'POWER.opt' with 'gcc-version-11'...
> >> Done.
> >>   * Building target 'POWER.fast' with 'gcc-version-11'...
> >> Done.
> >>   * Building target 'RISCV.opt' with 'gcc-version-11'...
> >> Done.
> >>   * Building target 'RISCV.fast' with 'gcc-version-11'...
> >> Done.
> >>   * Building target 'ARM_MESI_Three_Level.opt' with 'gcc-version-11'...
> >> Done.
> >>   * Building target 'ARM_MESI_Three_Level.fast' with 'gcc-version-11'...
> >> Done.
> >>   * Building 

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #187

[Gabe Black via gem5-dev]

It was a little different, but still pretty simple.

https://gem5-review.googlesource.com/c/public/gem5/+/58349

Gabe

On Tue, Mar 29, 2022 at 6:00 PM Gabe Black  wrote:

> My guess is that I missed add a ['CONF'] in front of one of one of the
> uses of a configuration variable. No requirements should have changed, so
> this is likely a simple bug where some bookkeeping is getting dropped
> somewhere. I'll take a look.
>
> Gabe
>
> On Tue, Mar 29, 2022 at 8:44 PM Bobby Bruce  wrote:
>
>> Gabe,
>>
>> It seems like this patch:
>> https://gem5-review.googlesource.com/c/public/gem5/+/56892 is causing
>> the compilation failure. I've left a comment there. The TL;DR: when
>> compiling with our minimum dependencies (no optional packages), we get
>> `Error: Got protobuf to build, but lacks support!`. I assume this means
>> this patch is enforcing protobuf as a mandatory package for compilation?
>>
>> Kind regards,
>> Bobby
>> --
>> Dr. Bobby R. Bruce
>> Room 3050,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>>
>>
>> On Tue, Mar 29, 2022 at 5:26 AM jenkins-no-reply--- via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> See <
>>> https://jenkins.gem5.org/job/compiler-checks/187/display/redirect?page=changes
>>> >
>>>
>>> Changes:
>>>
>>> [fcrh] mem: Add SharedMemoryServer
>>>
>>> [gabe.black] arch-arm: Override makeRead and makeWrite in the ISA
>>> description.
>>>
>>> [gabe.black] ext: Add a cont_choice keyword to kconfiglib.
>>>
>>> [gabe.black] scons: Put all config variables in an env['CONF'] sub-dict.
>>>
>>> [gabe.black] scons: Put internal build files in a gem5.build directory.
>>>
>>> [Bobby R. Bruce] tests: Remove accidentally included "exit 0" test code
>>>
>>> [matthew.poremba] configs,gpu-compute: Support fetch from system pages
>>>
>>> [matthew.poremba] dev-hsa: Properly mask HSA packet header bits
>>>
>>> [matthew.poremba] dev-hsa: Update QCntxt readIndex in HW scheduler write
>>>
>>> [gabe.black] arch: Split up src/dest register ID creation.
>>>
>>> [srikant.bharadwaj] configs: Update memory port name in Ruby
>>>
>>>
>>> --
>>> Started by timer
>>> Running as SYSTEM
>>> Building in workspace 
>>> The recommended git tool is: NONE
>>> No credentials specified
>>>  > git rev-parse --resolve-git-dir <
>>> https://jenkins.gem5.org/job/compiler-checks/ws/.git> # timeout=10
>>> Fetching changes from the remote Git repository
>>>  > git config remote.origin.url
>>> https://gem5.googlesource.com/public/gem5 # timeout=10
>>> Fetching upstream changes from https://gem5.googlesource.com/public/gem5
>>>  > git --version # timeout=10
>>>  > git --version # 'git version 2.25.1'
>>>  > git fetch --tags --force --progress --
>>> https://gem5.googlesource.com/public/gem5
>>> +refs/heads/*:refs/remotes/origin/* # timeout=10
>>>  > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
>>> Checking out Revision 4c9084e318f5ae02af4b372e39bbb7fee3518b97
>>> (refs/remotes/origin/develop)
>>>  > git config core.sparsecheckout # timeout=10
>>>  > git checkout -f 4c9084e318f5ae02af4b372e39bbb7fee3518b97 # timeout=10
>>> Commit message: "configs: Update memory port name in Ruby"
>>>  > git rev-list --no-walk 64d00f83c4beafbe10c2217b69ccf7212063b014 #
>>> timeout=10
>>> [Checks API] No suitable checks publisher found.
>>> [compiler-checks] $ /bin/sh -xe /tmp/jenkins15341758373293734952.sh
>>> + ./tests/compiler-tests.sh -j 16
>>> Starting build tests with 'gcc-version-11'...
>>> 'gcc-version-11' was found in the comprehensive tests. All ISAs will be
>>> built.
>>>   * Building target 'NULL_MOESI_CMP_token.opt' with 'gcc-version-11'...
>>> Done.
>>>   * Building target 'NULL_MOESI_CMP_token.fast' with 'gcc-version-11'...
>>> Done.
>>>   * Building target 'SPARC.opt' with 'gcc-version-11'...
>>> Done.
>>>   * Building target 'SPARC.fast' with 'gcc-version-11'...
>>> Done.
>>>   * Building target 'POWER.opt' with 'gcc-version-11'...
>>> Done.
>>>   * Building target 'POWER.fast' with 'gcc-version-11'...
>>> Done.
>>>   * Building target 'RISCV.opt' with 'gcc-version-11'...
>>> Done.
>>>   * Building target 'RISCV.fast' with 'gcc-version-11'...
>>> Done.
>>>   * Building target 'NULL_MOESI_hammer.opt' with 'gcc-version-11'...
>>> Done.
>>>   * Building target 'NULL_MOESI_hammer.fast' with 'gcc-version-11'...
>>> Done.
>>>   * Building target 'ARM_MESI_Three_Level_HTM.opt' with
>>> 'gcc-version-11'...
>>> Done.
>>>   * Building target 'ARM_MESI_Three_Level_HTM.fast' with
>>> 'gcc-version-11'...
>>> Done.
>>>   * Building target 'ARM.opt' with 'gcc-version-11'...
>>> Done.
>>>   * Building target 'ARM.fast' with 'gcc-version-11'...
>>> Done.
>>>   * Building target 'MIPS.opt' with 'gcc-version-11'...
>>> Done.
>>>   * Building target 'MIPS.fast' with 'gcc-version-11'...
>>> Done.
>>>   * Building target 'X86.opt' with 

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #187

[Gabe Black via gem5-dev]

My guess is that I missed add a ['CONF'] in front of one of one of the uses
of a configuration variable. No requirements should have changed, so this
is likely a simple bug where some bookkeeping is getting dropped somewhere.
I'll take a look.

Gabe

On Tue, Mar 29, 2022 at 8:44 PM Bobby Bruce  wrote:

> Gabe,
>
> It seems like this patch:
> https://gem5-review.googlesource.com/c/public/gem5/+/56892 is causing the
> compilation failure. I've left a comment there. The TL;DR: when compiling
> with our minimum dependencies (no optional packages), we get `Error: Got
> protobuf to build, but lacks support!`. I assume this means this patch is
> enforcing protobuf as a mandatory package for compilation?
>
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Tue, Mar 29, 2022 at 5:26 AM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> See <
>> https://jenkins.gem5.org/job/compiler-checks/187/display/redirect?page=changes
>> >
>>
>> Changes:
>>
>> [fcrh] mem: Add SharedMemoryServer
>>
>> [gabe.black] arch-arm: Override makeRead and makeWrite in the ISA
>> description.
>>
>> [gabe.black] ext: Add a cont_choice keyword to kconfiglib.
>>
>> [gabe.black] scons: Put all config variables in an env['CONF'] sub-dict.
>>
>> [gabe.black] scons: Put internal build files in a gem5.build directory.
>>
>> [Bobby R. Bruce] tests: Remove accidentally included "exit 0" test code
>>
>> [matthew.poremba] configs,gpu-compute: Support fetch from system pages
>>
>> [matthew.poremba] dev-hsa: Properly mask HSA packet header bits
>>
>> [matthew.poremba] dev-hsa: Update QCntxt readIndex in HW scheduler write
>>
>> [gabe.black] arch: Split up src/dest register ID creation.
>>
>> [srikant.bharadwaj] configs: Update memory port name in Ruby
>>
>>
>> --
>> Started by timer
>> Running as SYSTEM
>> Building in workspace 
>> The recommended git tool is: NONE
>> No credentials specified
>>  > git rev-parse --resolve-git-dir <
>> https://jenkins.gem5.org/job/compiler-checks/ws/.git> # timeout=10
>> Fetching changes from the remote Git repository
>>  > git config remote.origin.url https://gem5.googlesource.com/public/gem5
>> # timeout=10
>> Fetching upstream changes from https://gem5.googlesource.com/public/gem5
>>  > git --version # timeout=10
>>  > git --version # 'git version 2.25.1'
>>  > git fetch --tags --force --progress --
>> https://gem5.googlesource.com/public/gem5
>> +refs/heads/*:refs/remotes/origin/* # timeout=10
>>  > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
>> Checking out Revision 4c9084e318f5ae02af4b372e39bbb7fee3518b97
>> (refs/remotes/origin/develop)
>>  > git config core.sparsecheckout # timeout=10
>>  > git checkout -f 4c9084e318f5ae02af4b372e39bbb7fee3518b97 # timeout=10
>> Commit message: "configs: Update memory port name in Ruby"
>>  > git rev-list --no-walk 64d00f83c4beafbe10c2217b69ccf7212063b014 #
>> timeout=10
>> [Checks API] No suitable checks publisher found.
>> [compiler-checks] $ /bin/sh -xe /tmp/jenkins15341758373293734952.sh
>> + ./tests/compiler-tests.sh -j 16
>> Starting build tests with 'gcc-version-11'...
>> 'gcc-version-11' was found in the comprehensive tests. All ISAs will be
>> built.
>>   * Building target 'NULL_MOESI_CMP_token.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'NULL_MOESI_CMP_token.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 'SPARC.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'SPARC.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 'POWER.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'POWER.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 'RISCV.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'RISCV.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 'NULL_MOESI_hammer.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'NULL_MOESI_hammer.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 'ARM_MESI_Three_Level_HTM.opt' with
>> 'gcc-version-11'...
>> Done.
>>   * Building target 'ARM_MESI_Three_Level_HTM.fast' with
>> 'gcc-version-11'...
>> Done.
>>   * Building target 'ARM.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'ARM.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 'MIPS.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'MIPS.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 'X86.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'X86.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 'X86_MOESI_AMD_Base.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'X86_MOESI_AMD_Base.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 

[gem5-dev] Re: Build failed in Jenkins: nightly #161

[Gabe Black via gem5-dev]

https://gem5-review.googlesource.com/c/public/gem5/+/57749

On Tue, Mar 15, 2022 at 12:59 PM Gabe Black  wrote:

> It looks like the problem is that the aapcs test calls ThreadContext which
> returns a TheISA::VecRegContainer, where since that test is for ARM it
> *should* really be working with an ARM VecRegContainer. Because this is
> being built for NULL, that uses the dummy versions which are not complete
> enough to have "as" template methods like the real classes.
>
> I think the solution is either to restrict that test to when building with
> ARM, or to add as<>() to the dummy classes. In the short term the offending
> change can be reverted, or we can wait until this evening when I'll have a
> chance to find a proper fix. This is what is right now probably a unique
> corner case where we have a unit test which is ISA dependent, and while it
> will *become* possible to run reasonably under any build once the
> ThreadContext doesn't build in what data type vector registers should be,
> in the mean time it either won't work because of this problem, or even when
> it would work, it would be operating on an inappropriate data type.
>
> Gabe
>
> On Tue, Mar 15, 2022 at 8:13 AM Jason Lowe-Power 
> wrote:
>
>> Looks like the problem is  [gabe.black] arch: Make the DummyVec... types
>> the same size as RegVal.
>>
>> Can you take a look, Gabe?
>>
>> Thanks,
>> Jason
>>
>> On Tue, Mar 15, 2022 at 1:46 AM jenkins-no-reply--- via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> See <
>>> https://jenkins.gem5.org/job/nightly/161/display/redirect?page=changes>
>>>
>>> Changes:
>>>
>>> [gabe.black] arch-x86: Fix a bug in the protected mode IRET.
>>>
>>> [gabe.black] arch-x86: Fix writing back 32 bit PTEs in the walker.
>>>
>>> [gabe.black] arch-x86: Detect when entering virtual 8086 mode.
>>>
>>> [gabe.black] arch-x86: Tidy up the page table walker stepWalk method.
>>>
>>> [gabe.black] arch-x86: Use the right bits in the page table walker.
>>>
>>> [gabe.black] arch-x86: Make the flags microops handle reserved bits
>>> better.
>>>
>>> [matthew.poremba] sim-se: Initialize shared page table base upon clone
>>>
>>> [Bobby R. Bruce] util-docker: Adding docker-compose.yaml
>>>
>>> [Bobby R. Bruce] tests,util-docker: Add clang-12 to the compiler tests
>>>
>>> [Bobby R. Bruce] util: Remove util/cloudbuild
>>>
>>> [gabe.black] dev,arch-x86: Make the I8042 reset settings more realistic.
>>>
>>> [gabe.black] dev,arch-x86: Implement some self test 8042 commands.
>>>
>>> [gabe.black] scons: Process the SConsopts files for each variant.
>>>
>>> [gabe.black] scons: Turn a lot of compiler flag vars into env vars.
>>>
>>> [gabe.black] arch-x86: Fix the SAHF and LAHF instructions.
>>>
>>> [gabe.black] arch: Make the DummyVec... types the same size as RegVal.
>>>
>>> [gabe.black] ext,scons: Make kconfiglib available for use in SCons.
>>>
>>> [gabe.black] scons: Make all sticky variables automatically exported.
>>>
>>> [gabe.black] dev: Implement PS/2 keyboard echo and set scan code
>>> commands.
>>>
>>> [gabe.black] arch-x86: Specialize some instructions for virtual 8086
>>> mode.
>>>
>>>
>>> --
>>> [...truncated 1.17 MB...]
>>> [ RUN  ] LoggingFixture.Warn
>>> [   OK ] LoggingFixture.Warn (0 ms)
>>> [ RUN  ] LoggingFixture.Inform
>>> [   OK ] LoggingFixture.Inform (0 ms)
>>> [ RUN  ] LoggingFixture.Hack
>>> [   OK ] LoggingFixture.Hack (0 ms)
>>> [ RUN  ] LoggingFixture.WarnOnce
>>> [   OK ] LoggingFixture.WarnOnce (0 ms)
>>> [ RUN  ] LoggingFixture.InformOnce
>>> [   OK ] LoggingFixture.InformOnce (0 ms)
>>> [ RUN  ] LoggingFixture.HackOnce
>>> [   OK ] LoggingFixture.HackOnce (0 ms)
>>> [ RUN  ] LoggingFixture.WarnIf
>>> [   OK ] LoggingFixture.WarnIf (0 ms)
>>> [ RUN  ] LoggingFixture.WarnIfOnce
>>> [   OK ] LoggingFixture.WarnIfOnce (0 ms)
>>> [--] 21 tests from LoggingFixture (0 ms total)
>>>
>>> [--] Global test environment tear-down
>>> [==] 34 tests from 2 test suites ran. (1638 ms total)
>>> [  PASSED  ] 34 tests.
>>>  [LINK]  -> NULL/arch/generic/vec_pred_reg.test.opt
>>> build/NULL/arch/generic/vec_reg.test.opt
>>> --gtest_output=xml:build/NULL/unittests.opt/arch/generic/vec_reg.test.xml
>>> Running main() from
>>> build/NULL/ext/googletest/googletest/src/gtest_main.cc
>>> [==] Running 8 tests from 2 test suites.
>>> [--] Global test environment set-up.
>>> [--] 2 tests from VecReg
>>> [ RUN  ] VecReg.Size
>>> [   OK ] VecReg.Size (0 ms)
>>> [ RUN  ] VecReg.Zero
>>> [   OK ] VecReg.Zero (0 ms)
>>> [--] 2 tests from VecReg (0 ms total)
>>>
>>> [--] 6 tests from TwoDifferentVecRegs
>>> [ RUN  ] TwoDifferentVecRegs.Assignment
>>> [   OK ] TwoDifferentVecRegs.Assignment (0 ms)
>>> [ RUN  ] TwoDifferentVecRegs.Equality
>>> [   OK ] TwoDifferentVecRegs.Equality (0 ms)
>>> [ RUN  ] TwoDifferentVecRegs.Inequality
>>> [   

[gem5-dev] Re: Build failed in Jenkins: nightly #161

[Gabe Black via gem5-dev]

It looks like the problem is that the aapcs test calls ThreadContext which
returns a TheISA::VecRegContainer, where since that test is for ARM it
*should* really be working with an ARM VecRegContainer. Because this is
being built for NULL, that uses the dummy versions which are not complete
enough to have "as" template methods like the real classes.

I think the solution is either to restrict that test to when building with
ARM, or to add as<>() to the dummy classes. In the short term the offending
change can be reverted, or we can wait until this evening when I'll have a
chance to find a proper fix. This is what is right now probably a unique
corner case where we have a unit test which is ISA dependent, and while it
will *become* possible to run reasonably under any build once the
ThreadContext doesn't build in what data type vector registers should be,
in the mean time it either won't work because of this problem, or even when
it would work, it would be operating on an inappropriate data type.

Gabe

On Tue, Mar 15, 2022 at 8:13 AM Jason Lowe-Power 
wrote:

> Looks like the problem is  [gabe.black] arch: Make the DummyVec... types
> the same size as RegVal.
>
> Can you take a look, Gabe?
>
> Thanks,
> Jason
>
> On Tue, Mar 15, 2022 at 1:46 AM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> See <
>> https://jenkins.gem5.org/job/nightly/161/display/redirect?page=changes>
>>
>> Changes:
>>
>> [gabe.black] arch-x86: Fix a bug in the protected mode IRET.
>>
>> [gabe.black] arch-x86: Fix writing back 32 bit PTEs in the walker.
>>
>> [gabe.black] arch-x86: Detect when entering virtual 8086 mode.
>>
>> [gabe.black] arch-x86: Tidy up the page table walker stepWalk method.
>>
>> [gabe.black] arch-x86: Use the right bits in the page table walker.
>>
>> [gabe.black] arch-x86: Make the flags microops handle reserved bits
>> better.
>>
>> [matthew.poremba] sim-se: Initialize shared page table base upon clone
>>
>> [Bobby R. Bruce] util-docker: Adding docker-compose.yaml
>>
>> [Bobby R. Bruce] tests,util-docker: Add clang-12 to the compiler tests
>>
>> [Bobby R. Bruce] util: Remove util/cloudbuild
>>
>> [gabe.black] dev,arch-x86: Make the I8042 reset settings more realistic.
>>
>> [gabe.black] dev,arch-x86: Implement some self test 8042 commands.
>>
>> [gabe.black] scons: Process the SConsopts files for each variant.
>>
>> [gabe.black] scons: Turn a lot of compiler flag vars into env vars.
>>
>> [gabe.black] arch-x86: Fix the SAHF and LAHF instructions.
>>
>> [gabe.black] arch: Make the DummyVec... types the same size as RegVal.
>>
>> [gabe.black] ext,scons: Make kconfiglib available for use in SCons.
>>
>> [gabe.black] scons: Make all sticky variables automatically exported.
>>
>> [gabe.black] dev: Implement PS/2 keyboard echo and set scan code commands.
>>
>> [gabe.black] arch-x86: Specialize some instructions for virtual 8086 mode.
>>
>>
>> --
>> [...truncated 1.17 MB...]
>> [ RUN  ] LoggingFixture.Warn
>> [   OK ] LoggingFixture.Warn (0 ms)
>> [ RUN  ] LoggingFixture.Inform
>> [   OK ] LoggingFixture.Inform (0 ms)
>> [ RUN  ] LoggingFixture.Hack
>> [   OK ] LoggingFixture.Hack (0 ms)
>> [ RUN  ] LoggingFixture.WarnOnce
>> [   OK ] LoggingFixture.WarnOnce (0 ms)
>> [ RUN  ] LoggingFixture.InformOnce
>> [   OK ] LoggingFixture.InformOnce (0 ms)
>> [ RUN  ] LoggingFixture.HackOnce
>> [   OK ] LoggingFixture.HackOnce (0 ms)
>> [ RUN  ] LoggingFixture.WarnIf
>> [   OK ] LoggingFixture.WarnIf (0 ms)
>> [ RUN  ] LoggingFixture.WarnIfOnce
>> [   OK ] LoggingFixture.WarnIfOnce (0 ms)
>> [--] 21 tests from LoggingFixture (0 ms total)
>>
>> [--] Global test environment tear-down
>> [==] 34 tests from 2 test suites ran. (1638 ms total)
>> [  PASSED  ] 34 tests.
>>  [LINK]  -> NULL/arch/generic/vec_pred_reg.test.opt
>> build/NULL/arch/generic/vec_reg.test.opt
>> --gtest_output=xml:build/NULL/unittests.opt/arch/generic/vec_reg.test.xml
>> Running main() from build/NULL/ext/googletest/googletest/src/gtest_main.cc
>> [==] Running 8 tests from 2 test suites.
>> [--] Global test environment set-up.
>> [--] 2 tests from VecReg
>> [ RUN  ] VecReg.Size
>> [   OK ] VecReg.Size (0 ms)
>> [ RUN  ] VecReg.Zero
>> [   OK ] VecReg.Zero (0 ms)
>> [--] 2 tests from VecReg (0 ms total)
>>
>> [--] 6 tests from TwoDifferentVecRegs
>> [ RUN  ] TwoDifferentVecRegs.Assignment
>> [   OK ] TwoDifferentVecRegs.Assignment (0 ms)
>> [ RUN  ] TwoDifferentVecRegs.Equality
>> [   OK ] TwoDifferentVecRegs.Equality (0 ms)
>> [ RUN  ] TwoDifferentVecRegs.Inequality
>> [   OK ] TwoDifferentVecRegs.Inequality (0 ms)
>> [ RUN  ] TwoDifferentVecRegs.Printing
>> [   OK ] TwoDifferentVecRegs.Printing (0 ms)
>> [ RUN  ] TwoDifferentVecRegs.ParseParam
>> [   OK ] TwoDifferentVecRegs.ParseParam (0 ms)
>> [ RUN  ] 

[gem5-dev] resource downloader failure

[Gabe Black via gem5-dev]

Hi folks. I've been trying to run tests locally, and I've been running into
occasional flakiness due to a problem with the resource downloader. This
reminds me somewhat of flakiness I was seeing in kokoro as well, so they
are probably related. The error output is this:

$ cat
./testing-results/SuiteUID:atomic-cpu_1-cores_classic_kvm-fork-run-test-GCN3_X86-x86_64-opt/TestUID:atomic-cpu_1-cores_classic_kvm-fork-run-test-GCN3_X86-x86_64-opt/simerr
warn: .kvm_vm already has parent not resetting parent.
Note: kvm_vm is not a parameter of X86Board
warn: (Previously declared as .processor.kvm_vm
HTTPError: HTTP Error 429: Too Many Requests

At:
  /usr/lib/python3.10/urllib/request.py(643): http_error_default
  /usr/lib/python3.10/urllib/request.py(496): _call_chain
  /usr/lib/python3.10/urllib/request.py(563): error
  /usr/lib/python3.10/urllib/request.py(634): http_response
  /usr/lib/python3.10/urllib/request.py(525): open
  /usr/lib/python3.10/urllib/request.py(216): urlopen
  build/GCN3_X86/python/gem5/resources/downloader.py(77):
_get_resources_json
  build/GCN3_X86/python/gem5/resources/downloader.py(207):
get_resources_json_obj
  build/GCN3_X86/python/gem5/resources/resource.py(162): __init__
  /home/gblack/gem5/work/tests/gem5/configs/boot_kvm_fork_run.py(205):

  build/GCN3_X86/python/m5/main.py(434): main


Is there a limit that needs to be bumped up? Some way to consolidate
requests so we're not hitting the existing limit?

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] microcode test system

[Gabe Black via gem5-dev]

Hey testing folks (primarily Bobby probably?). I'm revamping the x86
microcode to extract it from SCons itself, and also just to make it less
painful and annoying to work with.

Importantly, the microcode basically lists a sequence of microop mnemonics
and a set of arguments. The mnemonic simply selects a python class, and the
arguments are simply used verbatim to instantiate it. Once the assembler
has turned a macroop definition into a sequence of instances of python
microop classes, it goes through and turns those into essentially c++
arrays (and some other stuff) which get compiled into gem5. The arguments
passed to the microops are generally substituted into the code which
instantiates the microop instances in c++. They often don't *look* like
string constants, but that's because there are a bunch of python variables
defined like t0, dsz, cs, etc, which all actually *hold* string constants.

In any case, when we have a sequence of python objects which all represent
a complete definition of what microop to use and all its parameters, we are
just a small step away from being able to execute the *python* instances
one by one, and being able to test the behavior of a macroop, assuming the
python microops and the c++ microops do the same thing, and the macroop
spits them into the CPU as expected.

One key difference is that the arguments of the microops boil down to c++
or are explicitly c++ string constants. When the arguments are symbolic, it
would be relatively easy to substitute in a different set of variables
which are really true python variables and not secretly c++. There aren't
tons of places where there are raw string constants in the microcode, or at
least not tons of different cases where that happens, so we could avoid the
problem by just selectively defining what macroops to test, and/or by
trying to convert the remaining string constants into variables which can
have a python personality.

What I'm hoping to accomplish with this email is to, first, just get this
idea out there in case anybody has any feedback.

Second, I want to find out what provisions we have for running python based
tests. We have googletest to run c++ tests which I'm quite familiar with
using, but I don't know what we have that's equivalent to that for python.
Any pointers/docs?

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: build configuration overhaul

[Gabe Black via gem5-dev]

Hi Jason, thanks for the feedback. Replies inline.

On Fri, Jan 28, 2022 at 2:45 PM Jason Lowe-Power 
wrote:

> Hi Gabe,
>
> Thanks for writing this up. The first part of your document is the best
> documentation on the current build system I've seen to date! We should
> convert it to markdown and put it up on the website!
>
> Overall, I really like the direction you're going here. I strongly agree
> with the problems of the current build system that you enumerate. I also
> strongly back the "there is one way to do it" idea from your solution.
>
> I have a couple of small concerns:
> 1. I believe we should be able to use flat text files for configuring and
> not require something as complex as kconfig. The option of kconfig is OK,
> but flat text files give us the ability to offer defaults to users.
>

Kconfig does this. The config file is a text file, and you can provide one
which only lists the options you care about and use the defconfig target
(like menuconfig) which will non-interactively fill in the gaps with all
default settings. This is essentially the same as what the build_opts files
do.


> 2. One requirement that wasn't listed is to make the common case easy. We
> should allow users to build gem5 just as easily as they do today (i.e.,
> with a single simple command).
>

Even if starting from scratch requires two commands (set up build
directory, compile), subsequent builds will still only take one. It would
be feasible to put everything together into one, although there may be some
weird cases/interactions that make that not work for some reason. I think
there is a good chance it would work to configure and build all together.

I also think, though, that the well established pattern from other projects
is to configure and then build in two steps, and there's good reason for
that. This isn't something we'd have to worry about up front, so we can
figure it out further down the line once we have more concrete alternatives
to compare.


> 3. Backwards compatibility is important. There's a huge amount of
> documentation written about gem5 all over the internet (e.g., on class
> webpages for assignments), and we can't update all of it overnight. Keeping
> at least a symlink to build/X86/gem5.opt, etc. will be important for our
> many users.
>

Yes, I think this can be done incrementally, with backwards compatibility
minimally during a transition period.


>
> It may be feasible to do this in steps. E.g., we could update the files in
> build_opts to *require* all sticky variables and we could make all
> variables either sticky or environment variables. Similarly, we could
> remove the common build directory. These things would solve some of the
> problems you enumerate without breaking compatibility. It's definitely
> low-hanging fruit.
>

Yes, exactly, that's my plan.


>
> Cheers,
> Jason
>
>
>
> On Wed, Jan 26, 2022 at 6:45 PM Gabe Black via gem5-dev 
> wrote:
>
>> Hi folks. I have a design document here:
>>
>>
>> https://docs.google.com/document/d/11KspjOClPzGRqLUgNTfKQPrrkmsqx-2ulC71nZUJ2qA/edit?usp=sharing
>>
>> which describes my proposal to overhaul how gem5 builds are configured.
>> Please take a look and provide feedback.
>>
>> Important points to note are (optionally but recommended) collapsing the
>> global vs. variant separation in the build directory, and using a kconfig
>> like system for enabling/disabling/configuring features, individual models,
>> mixtures of ISAs, etc. Also setting up a build directory with a new config
>> would be a separate step instead of being implied by the build path. All
>> the details are in the doc, PTAL.
>>
>> Gabe
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] build configuration overhaul

[Gabe Black via gem5-dev]

Hi folks. I have a design document here:

https://docs.google.com/document/d/11KspjOClPzGRqLUgNTfKQPrrkmsqx-2ulC71nZUJ2qA/edit?usp=sharing

which describes my proposal to overhaul how gem5 builds are configured.
Please take a look and provide feedback.

Important points to note are (optionally but recommended) collapsing the
global vs. variant separation in the build directory, and using a kconfig
like system for enabling/disabling/configuring features, individual models,
mixtures of ISAs, etc. Also setting up a build directory with a new config
would be a separate step instead of being implied by the build path. All
the details are in the doc, PTAL.

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: For fun x86 bare metal CLs

[Gabe Black via gem5-dev]

BTW, I've started trying to get this test program to run to flush out bugs
in our pre-64bit x86 support. It's been very helpful and usable, and I'm
hoping once I get it working (or at least mostly working :-) we can add it
as a regression.

https://github.innominds.com/barotto/test386.asm

Gabe

On Tue, Jan 18, 2022 at 9:04 PM Gabe Black  wrote:

> It seems slow, and I had to fix a bug in SeaBIOS, but it seems to run :-)
> No video currently, since I haven't written a VGA device yet.
>
> Gabe
>
> On Tue, Jan 18, 2022 at 9:03 PM Gabe Black  wrote:
>
>> HimemX 3.34 [Sep 05 2015] (c) 1995, Till Gerken 2001-2006 Tom Ehlert
>> Always on A20 method used
>> Kernel: allocated 45 Diskbuffers = 23940 Bytes in HMA
>>
>> FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00]
>>
>> Done processing startup files C:\FDCONFIG.SYS and C:\AUTOEXEC.BAT
>>
>> Type HELP to get support on commands and navigation.
>>
>> Welcome to the FreeDOS 1.2 operating system (http://www.freedos.org)
>>
>> C:\>dir
>>  Volume in drive C is FREEDOS2016
>>  Volume Serial Number is 104F-0FE7
>>  Directory of C:\
>>
>> FDOS   02-11-2018  8:05a
>> AUTOEXEC BAT 1,319  02-11-2018  8:14a
>> COMMAND  COM66,945  08-28-2006 10:38p
>> FDCONFIG SYS   762  02-11-2018  8:14a
>> KERNEL   SYS46,685  05-11-2016  9:42p
>>  4 file(s)115,711 bytes
>>  1 dir(s) 311,771,136 bytes free
>> C:\>
>>
>> On Sun, Jan 9, 2022 at 9:39 PM Gabe Black  wrote:
>>
>>> Hey folks, I've wanted to try to get a bare metal x86 config going for a
>>> long time, since I thought it would be fun to play some old DOS games from
>>> my childhood on gem5. To that end, I decided to try to get SeaBIOS, a free
>>> implementation of a PC BIOS, to run there.
>>>
>>> While I haven't gotten that to totally work yet, and I don't want to
>>> call for special attention for something I'm just doing for fun, I have
>>> found about a dozen general x86 bugs/missing features which I've been
>>> fixing up in this CL chain.
>>>
>>> https://gem5-review.googlesource.com/c/public/gem5/+/55249
>>>
>>> PTAL if you're curious about the DOS config, and also to review the
>>> actual fixes so that we can get those checked in.
>>>
>>> Gabe
>>>
>>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: For fun x86 bare metal CLs

[Gabe Black via gem5-dev]

It seems slow, and I had to fix a bug in SeaBIOS, but it seems to run :-)
No video currently, since I haven't written a VGA device yet.

Gabe

On Tue, Jan 18, 2022 at 9:03 PM Gabe Black  wrote:

> HimemX 3.34 [Sep 05 2015] (c) 1995, Till Gerken 2001-2006 Tom Ehlert
> Always on A20 method used
> Kernel: allocated 45 Diskbuffers = 23940 Bytes in HMA
>
> FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00]
>
> Done processing startup files C:\FDCONFIG.SYS and C:\AUTOEXEC.BAT
>
> Type HELP to get support on commands and navigation.
>
> Welcome to the FreeDOS 1.2 operating system (http://www.freedos.org)
>
> C:\>dir
>  Volume in drive C is FREEDOS2016
>  Volume Serial Number is 104F-0FE7
>  Directory of C:\
>
> FDOS   02-11-2018  8:05a
> AUTOEXEC BAT 1,319  02-11-2018  8:14a
> COMMAND  COM66,945  08-28-2006 10:38p
> FDCONFIG SYS   762  02-11-2018  8:14a
> KERNEL   SYS46,685  05-11-2016  9:42p
>  4 file(s)115,711 bytes
>  1 dir(s) 311,771,136 bytes free
> C:\>
>
> On Sun, Jan 9, 2022 at 9:39 PM Gabe Black  wrote:
>
>> Hey folks, I've wanted to try to get a bare metal x86 config going for a
>> long time, since I thought it would be fun to play some old DOS games from
>> my childhood on gem5. To that end, I decided to try to get SeaBIOS, a free
>> implementation of a PC BIOS, to run there.
>>
>> While I haven't gotten that to totally work yet, and I don't want to call
>> for special attention for something I'm just doing for fun, I have found
>> about a dozen general x86 bugs/missing features which I've been fixing up
>> in this CL chain.
>>
>> https://gem5-review.googlesource.com/c/public/gem5/+/55249
>>
>> PTAL if you're curious about the DOS config, and also to review the
>> actual fixes so that we can get those checked in.
>>
>> Gabe
>>
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: For fun x86 bare metal CLs

[Gabe Black via gem5-dev]

HimemX 3.34 [Sep 05 2015] (c) 1995, Till Gerken 2001-2006 Tom Ehlert
Always on A20 method used
Kernel: allocated 45 Diskbuffers = 23940 Bytes in HMA

FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00]

Done processing startup files C:\FDCONFIG.SYS and C:\AUTOEXEC.BAT

Type HELP to get support on commands and navigation.

Welcome to the FreeDOS 1.2 operating system (http://www.freedos.org)

C:\>dir
 Volume in drive C is FREEDOS2016
 Volume Serial Number is 104F-0FE7
 Directory of C:\

FDOS   02-11-2018  8:05a
AUTOEXEC BAT 1,319  02-11-2018  8:14a
COMMAND  COM66,945  08-28-2006 10:38p
FDCONFIG SYS   762  02-11-2018  8:14a
KERNEL   SYS46,685  05-11-2016  9:42p
 4 file(s)115,711 bytes
 1 dir(s) 311,771,136 bytes free
C:\>

On Sun, Jan 9, 2022 at 9:39 PM Gabe Black  wrote:

> Hey folks, I've wanted to try to get a bare metal x86 config going for a
> long time, since I thought it would be fun to play some old DOS games from
> my childhood on gem5. To that end, I decided to try to get SeaBIOS, a free
> implementation of a PC BIOS, to run there.
>
> While I haven't gotten that to totally work yet, and I don't want to call
> for special attention for something I'm just doing for fun, I have found
> about a dozen general x86 bugs/missing features which I've been fixing up
> in this CL chain.
>
> https://gem5-review.googlesource.com/c/public/gem5/+/55249
>
> PTAL if you're curious about the DOS config, and also to review the actual
> fixes so that we can get those checked in.
>
> Gabe
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Incorrect handling of PCI interrupt configuration

[Gabe Black via gem5-dev]

Hi folks. I was looking at how our PCI system is set up in gem5, and I've
found that the way interrupts is configured is not correct. You can find a
fairly complete description of the problem over here:

https://gem5.atlassian.net/browse/GEM5-1165

My plan to fix this is to move the description of what interrupts to use
into the host controller, and remove it from the devices themselves.
They'll be oblivious to what interrupt they're actually requesting, since
it's up to the host controller to determine that in real hardware.

It doesn't look like this is likely to affect anything significantly
because the interrupt configuration I've found in our config scripts is
pretty minimal, but since it would be visible in configs, etc, I wanted to
send a heads up before I started working on it.

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] For fun x86 bare metal CLs

[Gabe Black via gem5-dev]

Hey folks, I've wanted to try to get a bare metal x86 config going for a
long time, since I thought it would be fun to play some old DOS games from
my childhood on gem5. To that end, I decided to try to get SeaBIOS, a free
implementation of a PC BIOS, to run there.

While I haven't gotten that to totally work yet, and I don't want to call
for special attention for something I'm just doing for fun, I have found
about a dozen general x86 bugs/missing features which I've been fixing up
in this CL chain.

https://gem5-review.googlesource.com/c/public/gem5/+/55249

PTAL if you're curious about the DOS config, and also to review the actual
fixes so that we can get those checked in.

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Broken SST due to python changes

[Gabe Black via gem5-dev]

I just realized I turned off my computer since I'll be traveling, and my
test run of sst can't finish if the computer is off :-P. I have not
completed a run of your example command, but it starts and I have no reason
to believe it won't finish. I would still suggest running it yourself (with
my changes) to verify that things are fixed. I need to wake up to go to the
airport in 4 hours, so I won't be able to do anything non-trivial with this
until Friday at the earliest.

Gabe

On Thu, Dec 16, 2021 at 3:29 AM Gabe Black  wrote:

> https://gem5-review.googlesource.com/c/public/gem5/+/54325/1
>
> On Wed, Dec 15, 2021 at 11:12 PM Gabe Black  wrote:
>
>> There will be a couple more patches coming, since the systemc subsystem
>> has problems when python is already running when static initializers run. I
>> had been building without systemc enabled to simplify things earlier, but I
>> need to get it running too. That should be a fairly quick fix.
>>
>> Gabe
>>
>> On Wed, Dec 15, 2021 at 10:40 PM Hoa Nguyen 
>> wrote:
>>
>>> Hi Gabe,
>>>
>>> Thanks for uploading the changes. Typically it'll take less than an hour
>>> for RISC-V.
>>>
>>> Regards,
>>> Hoa Nguyen
>>>
>>> On Wed, Dec 15, 2021 at 10:38 PM Gabe Black 
>>> wrote:
>>>
 I have it running, although it's taking a while. How long should it
 take to finish? Should it finish immediately, 15 minutes, a few hours,
 tomorrow...? I'll upload my changes in the mean time.

 Gabe

 On Wed, Dec 15, 2021 at 9:13 PM Gabe Black 
 wrote:

> Ok, I did/am doing a little more looking, and part of the problem
> seems to be that some of the python blobs executed with executePython
> assume prior blobs have done imports for them already. That was where the
> modules or their contents not being found was coming from, and then after
> that something about the error reporting was blowing up, but that wasn't
> the primary problem.
>
> With that fixed, it's still upset, but now it's because "fatal: Need
> to instantiate Root() before calling instantiate()". Also, gem5 is 
> printing
> the help blob which seems wrong, so maybe the command line arguments 
> aren't
> making it through like they should? It could be that no config script is
> run, and that's why m5.instantiate() doesn't work.
>
> It's also a little weird that there's an ordering dependency between
> the execPythonCommands invocations, considering the same set of those
> should still be happening in the same order. I suppose I'm not explicitly
> importing the m5 module into __main__.__dict__ to run m5.main(), so that
> may be where that's coming from.
>
> Anyway, I'm still chopping away at this, but I think it's pretty close.
>
> Gabe
>
> On Wed, Dec 15, 2021 at 8:29 PM Gabe Black 
> wrote:
>
>> Also, I have to say, while I'm grateful that there was a push to get
>> the SCons changes reviewed for the release, we wouldn't be in this crunch
>> if they had been reviewed a month ago. It would be best not to let things
>> bunch up and then make a herculean push right at the deadline, where
>> problems have a very limited time to get resolved.
>>
>> Gabe
>>
>> On Wed, Dec 15, 2021 at 4:38 PM Gabe Black 
>> wrote:
>>
>>> That's actually very helpful, since I was pretty sure there was a
>>> memory problem but couldn't figure out where. I think there's a good 
>>> chance
>>> this will be an easy fix.
>>>
>>> Gabe
>>>
>>> On Wed, Dec 15, 2021, 8:59 AM Jason Lowe-Power 
>>> wrote:
>>>
 Ok, I was able to get a debugger to work and I dug in a bit more...

 The problem is that the new code does not initialize the
 __main__.py module. The original SST code had the following line:
 `pythonMain = PyImport_AddModule(PyCC("__main__"));`

 This was executed before `execPythonCommands`.

 In `execPythonCommands` we use the `pythonMain` variable. However,
 in the *new* code, that variable is NULL (or unitialized, actually).

 As far as I can tell, all of the new python changes didn't come
 with any documentation on how you are supposed to interact with Python 
 from
 gem5. So, there's no good way for us to update this code.

 Gabe, if you can update the `execPythonCommands` function to work
 however you expected it to, that would be great.

 Thanks,
 Jason

 On Wed, Dec 15, 2021 at 10:45 AM Jason Lowe-Power <
 ja...@lowepower.com> wrote:

> Here's my understanding of where we are on this:
>
> As of
> https://gem5.googlesource.com/public/gem5/+/cf7ce21848ea4aeee28737823e6e768f9a14ceaf
> SST was working. (Committed Dec. 7th)
>
> Then, this large relation chain was 

[gem5-dev] Re: Broken SST due to python changes

[Gabe Black via gem5-dev]

https://gem5-review.googlesource.com/c/public/gem5/+/54325/1

On Wed, Dec 15, 2021 at 11:12 PM Gabe Black  wrote:

> There will be a couple more patches coming, since the systemc subsystem
> has problems when python is already running when static initializers run. I
> had been building without systemc enabled to simplify things earlier, but I
> need to get it running too. That should be a fairly quick fix.
>
> Gabe
>
> On Wed, Dec 15, 2021 at 10:40 PM Hoa Nguyen  wrote:
>
>> Hi Gabe,
>>
>> Thanks for uploading the changes. Typically it'll take less than an hour
>> for RISC-V.
>>
>> Regards,
>> Hoa Nguyen
>>
>> On Wed, Dec 15, 2021 at 10:38 PM Gabe Black  wrote:
>>
>>> I have it running, although it's taking a while. How long should it take
>>> to finish? Should it finish immediately, 15 minutes, a few hours,
>>> tomorrow...? I'll upload my changes in the mean time.
>>>
>>> Gabe
>>>
>>> On Wed, Dec 15, 2021 at 9:13 PM Gabe Black  wrote:
>>>
 Ok, I did/am doing a little more looking, and part of the problem seems
 to be that some of the python blobs executed with executePython assume
 prior blobs have done imports for them already. That was where the modules
 or their contents not being found was coming from, and then after that
 something about the error reporting was blowing up, but that wasn't the
 primary problem.

 With that fixed, it's still upset, but now it's because "fatal: Need to
 instantiate Root() before calling instantiate()". Also, gem5 is printing
 the help blob which seems wrong, so maybe the command line arguments aren't
 making it through like they should? It could be that no config script is
 run, and that's why m5.instantiate() doesn't work.

 It's also a little weird that there's an ordering dependency between
 the execPythonCommands invocations, considering the same set of those
 should still be happening in the same order. I suppose I'm not explicitly
 importing the m5 module into __main__.__dict__ to run m5.main(), so that
 may be where that's coming from.

 Anyway, I'm still chopping away at this, but I think it's pretty close.

 Gabe

 On Wed, Dec 15, 2021 at 8:29 PM Gabe Black 
 wrote:

> Also, I have to say, while I'm grateful that there was a push to get
> the SCons changes reviewed for the release, we wouldn't be in this crunch
> if they had been reviewed a month ago. It would be best not to let things
> bunch up and then make a herculean push right at the deadline, where
> problems have a very limited time to get resolved.
>
> Gabe
>
> On Wed, Dec 15, 2021 at 4:38 PM Gabe Black 
> wrote:
>
>> That's actually very helpful, since I was pretty sure there was a
>> memory problem but couldn't figure out where. I think there's a good 
>> chance
>> this will be an easy fix.
>>
>> Gabe
>>
>> On Wed, Dec 15, 2021, 8:59 AM Jason Lowe-Power 
>> wrote:
>>
>>> Ok, I was able to get a debugger to work and I dug in a bit more...
>>>
>>> The problem is that the new code does not initialize the __main__.py
>>> module. The original SST code had the following line:
>>> `pythonMain = PyImport_AddModule(PyCC("__main__"));`
>>>
>>> This was executed before `execPythonCommands`.
>>>
>>> In `execPythonCommands` we use the `pythonMain` variable. However,
>>> in the *new* code, that variable is NULL (or unitialized, actually).
>>>
>>> As far as I can tell, all of the new python changes didn't come with
>>> any documentation on how you are supposed to interact with Python from
>>> gem5. So, there's no good way for us to update this code.
>>>
>>> Gabe, if you can update the `execPythonCommands` function to work
>>> however you expected it to, that would be great.
>>>
>>> Thanks,
>>> Jason
>>>
>>> On Wed, Dec 15, 2021 at 10:45 AM Jason Lowe-Power <
>>> ja...@lowepower.com> wrote:
>>>
 Here's my understanding of where we are on this:

 As of
 https://gem5.googlesource.com/public/gem5/+/cf7ce21848ea4aeee28737823e6e768f9a14ceaf
 SST was working. (Committed Dec. 7th)

 Then, this large relation chain was pushed:
 https://gem5-review.googlesource.com/c/public/gem5/+/49425 ending
 with
 https://gem5.googlesource.com/public/gem5/+/4c1422e3ba780a5f152426e214b4be3d45b751e4.
 This relation chain broke SST. This was committed on Dec. 8th.

 We have two options: Either we fix this bug ASAP (as in within 6
 days so we can release on 12/22) or we revert the changesets that were
 committed on the 8th.

 SST is a *must have* feature of gem5 21.2. It is quite frustrating
 to see it broken after all of the hard work that Hoa and Giacomo put 
 into
 it.

 Let me know if 

[gem5-dev] Re: Broken SST due to python changes

[Gabe Black via gem5-dev]

There will be a couple more patches coming, since the systemc subsystem has
problems when python is already running when static initializers run. I had
been building without systemc enabled to simplify things earlier, but I
need to get it running too. That should be a fairly quick fix.

Gabe

On Wed, Dec 15, 2021 at 10:40 PM Hoa Nguyen  wrote:

> Hi Gabe,
>
> Thanks for uploading the changes. Typically it'll take less than an hour
> for RISC-V.
>
> Regards,
> Hoa Nguyen
>
> On Wed, Dec 15, 2021 at 10:38 PM Gabe Black  wrote:
>
>> I have it running, although it's taking a while. How long should it take
>> to finish? Should it finish immediately, 15 minutes, a few hours,
>> tomorrow...? I'll upload my changes in the mean time.
>>
>> Gabe
>>
>> On Wed, Dec 15, 2021 at 9:13 PM Gabe Black  wrote:
>>
>>> Ok, I did/am doing a little more looking, and part of the problem seems
>>> to be that some of the python blobs executed with executePython assume
>>> prior blobs have done imports for them already. That was where the modules
>>> or their contents not being found was coming from, and then after that
>>> something about the error reporting was blowing up, but that wasn't the
>>> primary problem.
>>>
>>> With that fixed, it's still upset, but now it's because "fatal: Need to
>>> instantiate Root() before calling instantiate()". Also, gem5 is printing
>>> the help blob which seems wrong, so maybe the command line arguments aren't
>>> making it through like they should? It could be that no config script is
>>> run, and that's why m5.instantiate() doesn't work.
>>>
>>> It's also a little weird that there's an ordering dependency between the
>>> execPythonCommands invocations, considering the same set of those should
>>> still be happening in the same order. I suppose I'm not explicitly
>>> importing the m5 module into __main__.__dict__ to run m5.main(), so that
>>> may be where that's coming from.
>>>
>>> Anyway, I'm still chopping away at this, but I think it's pretty close.
>>>
>>> Gabe
>>>
>>> On Wed, Dec 15, 2021 at 8:29 PM Gabe Black  wrote:
>>>
 Also, I have to say, while I'm grateful that there was a push to get
 the SCons changes reviewed for the release, we wouldn't be in this crunch
 if they had been reviewed a month ago. It would be best not to let things
 bunch up and then make a herculean push right at the deadline, where
 problems have a very limited time to get resolved.

 Gabe

 On Wed, Dec 15, 2021 at 4:38 PM Gabe Black 
 wrote:

> That's actually very helpful, since I was pretty sure there was a
> memory problem but couldn't figure out where. I think there's a good 
> chance
> this will be an easy fix.
>
> Gabe
>
> On Wed, Dec 15, 2021, 8:59 AM Jason Lowe-Power 
> wrote:
>
>> Ok, I was able to get a debugger to work and I dug in a bit more...
>>
>> The problem is that the new code does not initialize the __main__.py
>> module. The original SST code had the following line:
>> `pythonMain = PyImport_AddModule(PyCC("__main__"));`
>>
>> This was executed before `execPythonCommands`.
>>
>> In `execPythonCommands` we use the `pythonMain` variable. However, in
>> the *new* code, that variable is NULL (or unitialized, actually).
>>
>> As far as I can tell, all of the new python changes didn't come with
>> any documentation on how you are supposed to interact with Python from
>> gem5. So, there's no good way for us to update this code.
>>
>> Gabe, if you can update the `execPythonCommands` function to work
>> however you expected it to, that would be great.
>>
>> Thanks,
>> Jason
>>
>> On Wed, Dec 15, 2021 at 10:45 AM Jason Lowe-Power <
>> ja...@lowepower.com> wrote:
>>
>>> Here's my understanding of where we are on this:
>>>
>>> As of
>>> https://gem5.googlesource.com/public/gem5/+/cf7ce21848ea4aeee28737823e6e768f9a14ceaf
>>> SST was working. (Committed Dec. 7th)
>>>
>>> Then, this large relation chain was pushed:
>>> https://gem5-review.googlesource.com/c/public/gem5/+/49425 ending
>>> with
>>> https://gem5.googlesource.com/public/gem5/+/4c1422e3ba780a5f152426e214b4be3d45b751e4.
>>> This relation chain broke SST. This was committed on Dec. 8th.
>>>
>>> We have two options: Either we fix this bug ASAP (as in within 6
>>> days so we can release on 12/22) or we revert the changesets that were
>>> committed on the 8th.
>>>
>>> SST is a *must have* feature of gem5 21.2. It is quite frustrating
>>> to see it broken after all of the hard work that Hoa and Giacomo put 
>>> into
>>> it.
>>>
>>> Let me know if I'm missing something.
>>>
>>> Thanks,
>>> Jason
>>>
>>> On Sat, Dec 11, 2021 at 10:35 AM Gabe Black 
>>> wrote:
>>>
 https://gem5-review.googlesource.com/c/public/gem5/+/54006

 At least one 

[gem5-dev] Re: Broken SST due to python changes

[Gabe Black via gem5-dev]

I have it running, although it's taking a while. How long should it take to
finish? Should it finish immediately, 15 minutes, a few hours, tomorrow...?
I'll upload my changes in the mean time.

Gabe

On Wed, Dec 15, 2021 at 9:13 PM Gabe Black  wrote:

> Ok, I did/am doing a little more looking, and part of the problem seems to
> be that some of the python blobs executed with executePython assume prior
> blobs have done imports for them already. That was where the modules or
> their contents not being found was coming from, and then after that
> something about the error reporting was blowing up, but that wasn't the
> primary problem.
>
> With that fixed, it's still upset, but now it's because "fatal: Need to
> instantiate Root() before calling instantiate()". Also, gem5 is printing
> the help blob which seems wrong, so maybe the command line arguments aren't
> making it through like they should? It could be that no config script is
> run, and that's why m5.instantiate() doesn't work.
>
> It's also a little weird that there's an ordering dependency between the
> execPythonCommands invocations, considering the same set of those should
> still be happening in the same order. I suppose I'm not explicitly
> importing the m5 module into __main__.__dict__ to run m5.main(), so that
> may be where that's coming from.
>
> Anyway, I'm still chopping away at this, but I think it's pretty close.
>
> Gabe
>
> On Wed, Dec 15, 2021 at 8:29 PM Gabe Black  wrote:
>
>> Also, I have to say, while I'm grateful that there was a push to get the
>> SCons changes reviewed for the release, we wouldn't be in this crunch if
>> they had been reviewed a month ago. It would be best not to let things
>> bunch up and then make a herculean push right at the deadline, where
>> problems have a very limited time to get resolved.
>>
>> Gabe
>>
>> On Wed, Dec 15, 2021 at 4:38 PM Gabe Black  wrote:
>>
>>> That's actually very helpful, since I was pretty sure there was a memory
>>> problem but couldn't figure out where. I think there's a good chance this
>>> will be an easy fix.
>>>
>>> Gabe
>>>
>>> On Wed, Dec 15, 2021, 8:59 AM Jason Lowe-Power 
>>> wrote:
>>>
 Ok, I was able to get a debugger to work and I dug in a bit more...

 The problem is that the new code does not initialize the __main__.py
 module. The original SST code had the following line:
 `pythonMain = PyImport_AddModule(PyCC("__main__"));`

 This was executed before `execPythonCommands`.

 In `execPythonCommands` we use the `pythonMain` variable. However, in
 the *new* code, that variable is NULL (or unitialized, actually).

 As far as I can tell, all of the new python changes didn't come with
 any documentation on how you are supposed to interact with Python from
 gem5. So, there's no good way for us to update this code.

 Gabe, if you can update the `execPythonCommands` function to work
 however you expected it to, that would be great.

 Thanks,
 Jason

 On Wed, Dec 15, 2021 at 10:45 AM Jason Lowe-Power 
 wrote:

> Here's my understanding of where we are on this:
>
> As of
> https://gem5.googlesource.com/public/gem5/+/cf7ce21848ea4aeee28737823e6e768f9a14ceaf
> SST was working. (Committed Dec. 7th)
>
> Then, this large relation chain was pushed:
> https://gem5-review.googlesource.com/c/public/gem5/+/49425 ending
> with
> https://gem5.googlesource.com/public/gem5/+/4c1422e3ba780a5f152426e214b4be3d45b751e4.
> This relation chain broke SST. This was committed on Dec. 8th.
>
> We have two options: Either we fix this bug ASAP (as in within 6 days
> so we can release on 12/22) or we revert the changesets that were 
> committed
> on the 8th.
>
> SST is a *must have* feature of gem5 21.2. It is quite frustrating to
> see it broken after all of the hard work that Hoa and Giacomo put into it.
>
> Let me know if I'm missing something.
>
> Thanks,
> Jason
>
> On Sat, Dec 11, 2021 at 10:35 AM Gabe Black 
> wrote:
>
>> https://gem5-review.googlesource.com/c/public/gem5/+/54006
>>
>> At least one problem I ran into was that the order of static
>> initializers was not determinstic, so the structures which said what
>> embedded python modules existed might be statically constructed after the
>> thing that consumes and sets them up. That could work by coincidence if 
>> the
>> order is favorable, but it wasn't for me and so lots of things didn't 
>> exist
>> as far as the python was concerned.
>>
>> To be clear, there is some mysterious deeper issue here which is
>> probably separate from that. As far as I can tell running gem5 itself is
>> working fine, but when running as a library in sst there is some sort of
>> memory corruption or premature garbage collection or something, and it
>> leads to a segfault or incorrect behavior 

[gem5-dev] Re: Broken SST due to python changes

[Gabe Black via gem5-dev]

Ok, I did/am doing a little more looking, and part of the problem seems to
be that some of the python blobs executed with executePython assume prior
blobs have done imports for them already. That was where the modules or
their contents not being found was coming from, and then after that
something about the error reporting was blowing up, but that wasn't the
primary problem.

With that fixed, it's still upset, but now it's because "fatal: Need to
instantiate Root() before calling instantiate()". Also, gem5 is printing
the help blob which seems wrong, so maybe the command line arguments aren't
making it through like they should? It could be that no config script is
run, and that's why m5.instantiate() doesn't work.

It's also a little weird that there's an ordering dependency between the
execPythonCommands invocations, considering the same set of those should
still be happening in the same order. I suppose I'm not explicitly
importing the m5 module into __main__.__dict__ to run m5.main(), so that
may be where that's coming from.

Anyway, I'm still chopping away at this, but I think it's pretty close.

Gabe

On Wed, Dec 15, 2021 at 8:29 PM Gabe Black  wrote:

> Also, I have to say, while I'm grateful that there was a push to get the
> SCons changes reviewed for the release, we wouldn't be in this crunch if
> they had been reviewed a month ago. It would be best not to let things
> bunch up and then make a herculean push right at the deadline, where
> problems have a very limited time to get resolved.
>
> Gabe
>
> On Wed, Dec 15, 2021 at 4:38 PM Gabe Black  wrote:
>
>> That's actually very helpful, since I was pretty sure there was a memory
>> problem but couldn't figure out where. I think there's a good chance this
>> will be an easy fix.
>>
>> Gabe
>>
>> On Wed, Dec 15, 2021, 8:59 AM Jason Lowe-Power 
>> wrote:
>>
>>> Ok, I was able to get a debugger to work and I dug in a bit more...
>>>
>>> The problem is that the new code does not initialize the __main__.py
>>> module. The original SST code had the following line:
>>> `pythonMain = PyImport_AddModule(PyCC("__main__"));`
>>>
>>> This was executed before `execPythonCommands`.
>>>
>>> In `execPythonCommands` we use the `pythonMain` variable. However, in
>>> the *new* code, that variable is NULL (or unitialized, actually).
>>>
>>> As far as I can tell, all of the new python changes didn't come with any
>>> documentation on how you are supposed to interact with Python from gem5.
>>> So, there's no good way for us to update this code.
>>>
>>> Gabe, if you can update the `execPythonCommands` function to work
>>> however you expected it to, that would be great.
>>>
>>> Thanks,
>>> Jason
>>>
>>> On Wed, Dec 15, 2021 at 10:45 AM Jason Lowe-Power 
>>> wrote:
>>>
 Here's my understanding of where we are on this:

 As of
 https://gem5.googlesource.com/public/gem5/+/cf7ce21848ea4aeee28737823e6e768f9a14ceaf
 SST was working. (Committed Dec. 7th)

 Then, this large relation chain was pushed:
 https://gem5-review.googlesource.com/c/public/gem5/+/49425 ending with
 https://gem5.googlesource.com/public/gem5/+/4c1422e3ba780a5f152426e214b4be3d45b751e4.
 This relation chain broke SST. This was committed on Dec. 8th.

 We have two options: Either we fix this bug ASAP (as in within 6 days
 so we can release on 12/22) or we revert the changesets that were committed
 on the 8th.

 SST is a *must have* feature of gem5 21.2. It is quite frustrating to
 see it broken after all of the hard work that Hoa and Giacomo put into it.

 Let me know if I'm missing something.

 Thanks,
 Jason

 On Sat, Dec 11, 2021 at 10:35 AM Gabe Black 
 wrote:

> https://gem5-review.googlesource.com/c/public/gem5/+/54006
>
> At least one problem I ran into was that the order of static
> initializers was not determinstic, so the structures which said what
> embedded python modules existed might be statically constructed after the
> thing that consumes and sets them up. That could work by coincidence if 
> the
> order is favorable, but it wasn't for me and so lots of things didn't 
> exist
> as far as the python was concerned.
>
> To be clear, there is some mysterious deeper issue here which is
> probably separate from that. As far as I can tell running gem5 itself is
> working fine, but when running as a library in sst there is some sort of
> memory corruption or premature garbage collection or something, and it
> leads to a segfault or incorrect behavior (failure to import modules,
> failure to find things inside them, etc). Things were even more
> tempermental until I added what feels like an unnecessary increment of the
> reference count for the modules in the new pybind_init.hh, which seemed to
> tame things in gem5 proper at least. I'm too tired to keep looking for it
> right now, but hopefully this will give you a 

[gem5-dev] Re: Broken SST due to python changes

[Gabe Black via gem5-dev]

Also, I have to say, while I'm grateful that there was a push to get the
SCons changes reviewed for the release, we wouldn't be in this crunch if
they had been reviewed a month ago. It would be best not to let things
bunch up and then make a herculean push right at the deadline, where
problems have a very limited time to get resolved.

Gabe

On Wed, Dec 15, 2021 at 4:38 PM Gabe Black  wrote:

> That's actually very helpful, since I was pretty sure there was a memory
> problem but couldn't figure out where. I think there's a good chance this
> will be an easy fix.
>
> Gabe
>
> On Wed, Dec 15, 2021, 8:59 AM Jason Lowe-Power 
> wrote:
>
>> Ok, I was able to get a debugger to work and I dug in a bit more...
>>
>> The problem is that the new code does not initialize the __main__.py
>> module. The original SST code had the following line:
>> `pythonMain = PyImport_AddModule(PyCC("__main__"));`
>>
>> This was executed before `execPythonCommands`.
>>
>> In `execPythonCommands` we use the `pythonMain` variable. However, in the
>> *new* code, that variable is NULL (or unitialized, actually).
>>
>> As far as I can tell, all of the new python changes didn't come with any
>> documentation on how you are supposed to interact with Python from gem5.
>> So, there's no good way for us to update this code.
>>
>> Gabe, if you can update the `execPythonCommands` function to work however
>> you expected it to, that would be great.
>>
>> Thanks,
>> Jason
>>
>> On Wed, Dec 15, 2021 at 10:45 AM Jason Lowe-Power 
>> wrote:
>>
>>> Here's my understanding of where we are on this:
>>>
>>> As of
>>> https://gem5.googlesource.com/public/gem5/+/cf7ce21848ea4aeee28737823e6e768f9a14ceaf
>>> SST was working. (Committed Dec. 7th)
>>>
>>> Then, this large relation chain was pushed:
>>> https://gem5-review.googlesource.com/c/public/gem5/+/49425 ending with
>>> https://gem5.googlesource.com/public/gem5/+/4c1422e3ba780a5f152426e214b4be3d45b751e4.
>>> This relation chain broke SST. This was committed on Dec. 8th.
>>>
>>> We have two options: Either we fix this bug ASAP (as in within 6 days so
>>> we can release on 12/22) or we revert the changesets that were committed on
>>> the 8th.
>>>
>>> SST is a *must have* feature of gem5 21.2. It is quite frustrating to
>>> see it broken after all of the hard work that Hoa and Giacomo put into it.
>>>
>>> Let me know if I'm missing something.
>>>
>>> Thanks,
>>> Jason
>>>
>>> On Sat, Dec 11, 2021 at 10:35 AM Gabe Black 
>>> wrote:
>>>
 https://gem5-review.googlesource.com/c/public/gem5/+/54006

 At least one problem I ran into was that the order of static
 initializers was not determinstic, so the structures which said what
 embedded python modules existed might be statically constructed after the
 thing that consumes and sets them up. That could work by coincidence if the
 order is favorable, but it wasn't for me and so lots of things didn't exist
 as far as the python was concerned.

 To be clear, there is some mysterious deeper issue here which is
 probably separate from that. As far as I can tell running gem5 itself is
 working fine, but when running as a library in sst there is some sort of
 memory corruption or premature garbage collection or something, and it
 leads to a segfault or incorrect behavior (failure to import modules,
 failure to find things inside them, etc). Things were even more
 tempermental until I added what feels like an unnecessary increment of the
 reference count for the modules in the new pybind_init.hh, which seemed to
 tame things in gem5 proper at least. I'm too tired to keep looking for it
 right now, but hopefully this will give you a good leg up.

 Gabe

 On Sat, Dec 11, 2021 at 8:25 AM Jason Lowe-Power 
 wrote:

> Everything was working as of last week-ish, if I remember correctly.
> We were booting both Arm and RISCV full system with gem5 cores and SST
> caches/memory.
>
> Cheers,
> Jason
>
> On Sat, Dec 11, 2021, 8:23 AM Gabe Black  wrote:
>
>> Thanks, that was really helpful. I've fixed the compilation problems,
>> and then a few more that were hiding behind that, including a few ones 
>> that
>> were intrinsic to the way sst was initializing the gem5 library (with
>> dlopen). Was this working to begin with and all this breakage is new, or
>> was it just that the compilation broke and there were these other 
>> problems
>> already? I want to make sure I don't leave things in a worse state than
>> when I got here, but I also don't want to go chasing down things that
>> weren't working to begin with.
>>
>> I'm going to upload what I have so far, and hopefully someone else
>> can take a look at it too. The current problem seems to be that the 
>> modules
>> in _m5 aren't working right, either because they've been garbage 
>> collected,
>> or because they're not being 

[gem5-dev] Re: Broken SST due to python changes

[Gabe Black via gem5-dev]

That's actually very helpful, since I was pretty sure there was a memory
problem but couldn't figure out where. I think there's a good chance this
will be an easy fix.

Gabe

On Wed, Dec 15, 2021, 8:59 AM Jason Lowe-Power  wrote:

> Ok, I was able to get a debugger to work and I dug in a bit more...
>
> The problem is that the new code does not initialize the __main__.py
> module. The original SST code had the following line:
> `pythonMain = PyImport_AddModule(PyCC("__main__"));`
>
> This was executed before `execPythonCommands`.
>
> In `execPythonCommands` we use the `pythonMain` variable. However, in the
> *new* code, that variable is NULL (or unitialized, actually).
>
> As far as I can tell, all of the new python changes didn't come with any
> documentation on how you are supposed to interact with Python from gem5.
> So, there's no good way for us to update this code.
>
> Gabe, if you can update the `execPythonCommands` function to work however
> you expected it to, that would be great.
>
> Thanks,
> Jason
>
> On Wed, Dec 15, 2021 at 10:45 AM Jason Lowe-Power 
> wrote:
>
>> Here's my understanding of where we are on this:
>>
>> As of
>> https://gem5.googlesource.com/public/gem5/+/cf7ce21848ea4aeee28737823e6e768f9a14ceaf
>> SST was working. (Committed Dec. 7th)
>>
>> Then, this large relation chain was pushed:
>> https://gem5-review.googlesource.com/c/public/gem5/+/49425 ending with
>> https://gem5.googlesource.com/public/gem5/+/4c1422e3ba780a5f152426e214b4be3d45b751e4.
>> This relation chain broke SST. This was committed on Dec. 8th.
>>
>> We have two options: Either we fix this bug ASAP (as in within 6 days so
>> we can release on 12/22) or we revert the changesets that were committed on
>> the 8th.
>>
>> SST is a *must have* feature of gem5 21.2. It is quite frustrating to see
>> it broken after all of the hard work that Hoa and Giacomo put into it.
>>
>> Let me know if I'm missing something.
>>
>> Thanks,
>> Jason
>>
>> On Sat, Dec 11, 2021 at 10:35 AM Gabe Black  wrote:
>>
>>> https://gem5-review.googlesource.com/c/public/gem5/+/54006
>>>
>>> At least one problem I ran into was that the order of static
>>> initializers was not determinstic, so the structures which said what
>>> embedded python modules existed might be statically constructed after the
>>> thing that consumes and sets them up. That could work by coincidence if the
>>> order is favorable, but it wasn't for me and so lots of things didn't exist
>>> as far as the python was concerned.
>>>
>>> To be clear, there is some mysterious deeper issue here which is
>>> probably separate from that. As far as I can tell running gem5 itself is
>>> working fine, but when running as a library in sst there is some sort of
>>> memory corruption or premature garbage collection or something, and it
>>> leads to a segfault or incorrect behavior (failure to import modules,
>>> failure to find things inside them, etc). Things were even more
>>> tempermental until I added what feels like an unnecessary increment of the
>>> reference count for the modules in the new pybind_init.hh, which seemed to
>>> tame things in gem5 proper at least. I'm too tired to keep looking for it
>>> right now, but hopefully this will give you a good leg up.
>>>
>>> Gabe
>>>
>>> On Sat, Dec 11, 2021 at 8:25 AM Jason Lowe-Power 
>>> wrote:
>>>
 Everything was working as of last week-ish, if I remember correctly. We
 were booting both Arm and RISCV full system with gem5 cores and SST
 caches/memory.

 Cheers,
 Jason

 On Sat, Dec 11, 2021, 8:23 AM Gabe Black  wrote:

> Thanks, that was really helpful. I've fixed the compilation problems,
> and then a few more that were hiding behind that, including a few ones 
> that
> were intrinsic to the way sst was initializing the gem5 library (with
> dlopen). Was this working to begin with and all this breakage is new, or
> was it just that the compilation broke and there were these other problems
> already? I want to make sure I don't leave things in a worse state than
> when I got here, but I also don't want to go chasing down things that
> weren't working to begin with.
>
> I'm going to upload what I have so far, and hopefully someone else can
> take a look at it too. The current problem seems to be that the modules in
> _m5 aren't working right, either because they've been garbage collected, 
> or
> because they're not being set up properly, or...
>
> Gabe
>
> On Fri, Dec 10, 2021 at 8:17 PM Bobby Bruce 
> wrote:
>
>> Hey gabe.
>>
>> No idea if this is the _best_ solution to your problem, but my
>> solution would be to rebuild the image with this installed. Modify the
>> `util/dockerfiles/sst-11.1.0/Dockerfile` to the environment you want. 
>> Then
>> run `docker build -t  util/dockerfiles/sst-11.1.0` to 
>> build
>> an image with the name "".
>>
>> Then you can execute `docker 

[gem5-dev] Re: Broken SST due to python changes

[Gabe Black via gem5-dev]

https://gem5-review.googlesource.com/c/public/gem5/+/54006

At least one problem I ran into was that the order of static initializers
was not determinstic, so the structures which said what embedded python
modules existed might be statically constructed after the thing that
consumes and sets them up. That could work by coincidence if the order is
favorable, but it wasn't for me and so lots of things didn't exist as far
as the python was concerned.

To be clear, there is some mysterious deeper issue here which is probably
separate from that. As far as I can tell running gem5 itself is working
fine, but when running as a library in sst there is some sort of memory
corruption or premature garbage collection or something, and it leads to a
segfault or incorrect behavior (failure to import modules, failure to find
things inside them, etc). Things were even more tempermental until I added
what feels like an unnecessary increment of the reference count for the
modules in the new pybind_init.hh, which seemed to tame things in gem5
proper at least. I'm too tired to keep looking for it right now, but
hopefully this will give you a good leg up.

Gabe

On Sat, Dec 11, 2021 at 8:25 AM Jason Lowe-Power 
wrote:

> Everything was working as of last week-ish, if I remember correctly. We
> were booting both Arm and RISCV full system with gem5 cores and SST
> caches/memory.
>
> Cheers,
> Jason
>
> On Sat, Dec 11, 2021, 8:23 AM Gabe Black  wrote:
>
>> Thanks, that was really helpful. I've fixed the compilation problems, and
>> then a few more that were hiding behind that, including a few ones that
>> were intrinsic to the way sst was initializing the gem5 library (with
>> dlopen). Was this working to begin with and all this breakage is new, or
>> was it just that the compilation broke and there were these other problems
>> already? I want to make sure I don't leave things in a worse state than
>> when I got here, but I also don't want to go chasing down things that
>> weren't working to begin with.
>>
>> I'm going to upload what I have so far, and hopefully someone else can
>> take a look at it too. The current problem seems to be that the modules in
>> _m5 aren't working right, either because they've been garbage collected, or
>> because they're not being set up properly, or...
>>
>> Gabe
>>
>> On Fri, Dec 10, 2021 at 8:17 PM Bobby Bruce  wrote:
>>
>>> Hey gabe.
>>>
>>> No idea if this is the _best_ solution to your problem, but my solution
>>> would be to rebuild the image with this installed. Modify the
>>> `util/dockerfiles/sst-11.1.0/Dockerfile` to the environment you want. Then
>>> run `docker build -t  util/dockerfiles/sst-11.1.0` to build
>>> an image with the name "".
>>>
>>> Then you can execute `docker run -u $UID:$GID --volume $(pwd):$(pwd) -w
>>> $(pwd) -it ` within the gem5 directory to spin up and enter
>>> a container from the image you just built. I think you'll be able to do
>>> what you want inside the container.
>>>
>>> Kind regards,
>>> Bobby
>>> --
>>> Dr. Bobby R. Bruce
>>> Room 3050,
>>> Kemper Hall, UC Davis
>>> Davis,
>>> CA, 95616
>>>
>>> web: https://www.bobbybruce.net
>>>
>>>
>>> On Fri, Dec 10, 2021 at 7:24 PM Gabe Black  wrote:
>>> >
>>> > Dumb question: I'm trying to run gdb inside this container on the sst
>>> thing. How do I do that? It's not installed in the container now, and I
>>> can't (easily) figure out how to get it installed. I can tell docker to
>>> install it, but then it seems to throw that away as soon as the command
>>> ends.
>>> >
>>> > Gabe
>>> >
>>> > On Fri, Dec 10, 2021 at 5:09 PM Bobby Bruce 
>>> wrote:
>>> >>
>>> >> Thanks Gabe,
>>> >>
>>> >> This is very much appreciated. I'm going to create the release
>>> staging once a couple more things get in. Feel free to push any patches
>>> related to these bugs to the release staging branch.
>>> >>
>>> >> If there is an order of priority I'd say the bug affecting SST is of
>>> higher importance than that affecting the Weeklies (as far as I can see the
>>> latter is hard to trigger). That being said, we'll apply both to the new
>>> release one way or another.
>>> >>
>>> >> --
>>> >> Dr. Bobby R. Bruce
>>> >> Room 3050,
>>> >> Kemper Hall, UC Davis
>>> >> Davis,
>>> >> CA, 95616
>>> >>
>>> >> web: https://www.bobbybruce.net
>>> >>
>>> >>
>>> >> On Fri, Dec 10, 2021 at 5:02 PM Gabe Black 
>>> wrote:
>>> >>>
>>> >>> Hi Bobby, not yet, I meant to look into this for the last couple
>>> days but kept running out of time. I'm sitting down to work on it right now.
>>> >>>
>>> >>> Gabe
>>> >>>
>>> >>> On Fri, Dec 10, 2021 at 1:21 PM Bobby Bruce 
>>> wrote:
>>> 
>>>  Hey Gabe,
>>> 
>>>  Is there any update on this?
>>> 
>>>  Kind regards,
>>>  Bobby
>>>  --
>>>  Dr. Bobby R. Bruce
>>>  Room 3050,
>>>  Kemper Hall, UC Davis
>>>  Davis,
>>>  CA, 95616
>>> 
>>>  web: https://www.bobbybruce.net
>>> 
>>> 
>>>  On Wed, Dec 8, 2021 at 5:51 PM Hoa Nguyen via gem5-dev <
>>> 

[gem5-dev] Re: Broken SST due to python changes

[Gabe Black via gem5-dev]

Thanks, that was really helpful. I've fixed the compilation problems, and
then a few more that were hiding behind that, including a few ones that
were intrinsic to the way sst was initializing the gem5 library (with
dlopen). Was this working to begin with and all this breakage is new, or
was it just that the compilation broke and there were these other problems
already? I want to make sure I don't leave things in a worse state than
when I got here, but I also don't want to go chasing down things that
weren't working to begin with.

I'm going to upload what I have so far, and hopefully someone else can take
a look at it too. The current problem seems to be that the modules in _m5
aren't working right, either because they've been garbage collected, or
because they're not being set up properly, or...

Gabe

On Fri, Dec 10, 2021 at 8:17 PM Bobby Bruce  wrote:

> Hey gabe.
>
> No idea if this is the _best_ solution to your problem, but my solution
> would be to rebuild the image with this installed. Modify the
> `util/dockerfiles/sst-11.1.0/Dockerfile` to the environment you want. Then
> run `docker build -t  util/dockerfiles/sst-11.1.0` to build
> an image with the name "".
>
> Then you can execute `docker run -u $UID:$GID --volume $(pwd):$(pwd) -w
> $(pwd) -it ` within the gem5 directory to spin up and enter
> a container from the image you just built. I think you'll be able to do
> what you want inside the container.
>
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Fri, Dec 10, 2021 at 7:24 PM Gabe Black  wrote:
> >
> > Dumb question: I'm trying to run gdb inside this container on the sst
> thing. How do I do that? It's not installed in the container now, and I
> can't (easily) figure out how to get it installed. I can tell docker to
> install it, but then it seems to throw that away as soon as the command
> ends.
> >
> > Gabe
> >
> > On Fri, Dec 10, 2021 at 5:09 PM Bobby Bruce  wrote:
> >>
> >> Thanks Gabe,
> >>
> >> This is very much appreciated. I'm going to create the release staging
> once a couple more things get in. Feel free to push any patches related to
> these bugs to the release staging branch.
> >>
> >> If there is an order of priority I'd say the bug affecting SST is of
> higher importance than that affecting the Weeklies (as far as I can see the
> latter is hard to trigger). That being said, we'll apply both to the new
> release one way or another.
> >>
> >> --
> >> Dr. Bobby R. Bruce
> >> Room 3050,
> >> Kemper Hall, UC Davis
> >> Davis,
> >> CA, 95616
> >>
> >> web: https://www.bobbybruce.net
> >>
> >>
> >> On Fri, Dec 10, 2021 at 5:02 PM Gabe Black 
> wrote:
> >>>
> >>> Hi Bobby, not yet, I meant to look into this for the last couple days
> but kept running out of time. I'm sitting down to work on it right now.
> >>>
> >>> Gabe
> >>>
> >>> On Fri, Dec 10, 2021 at 1:21 PM Bobby Bruce 
> wrote:
> 
>  Hey Gabe,
> 
>  Is there any update on this?
> 
>  Kind regards,
>  Bobby
>  --
>  Dr. Bobby R. Bruce
>  Room 3050,
>  Kemper Hall, UC Davis
>  Davis,
>  CA, 95616
> 
>  web: https://www.bobbybruce.net
> 
> 
>  On Wed, Dec 8, 2021 at 5:51 PM Hoa Nguyen via gem5-dev <
> gem5-dev@gem5.org> wrote:
> >
> > Hi Gabe,
> >
> > I have more details about this. In this use case, SST initialized the
> > Python environment before adding the "gem5 object". This gem5 object
> > will add more Python stuff from gem5 to the environment.
> >
> > The function that does that is initPython()
> >
> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/ext/sst/gem5.cc#415
> >
> > The following commands will pull the docker image for SST testing
> > purposes (note that host_gem5_root and guest_gem5_root must be
> > specified),
> >
> > ```
> > docker run -u $UID:$GID --volume
> "${host_gem5_root}":"${guest_gem5_root}" -w \
> >  "${guest_gem5_root}" --rm gcr.io/gem5-test/sst-env \
> >  bash -c "\
> > scons build/RISCV/libgem5_opt.so -j${nproc} --without-tcmalloc; \
> > cd ext/sst; \
> > make clean; make; \
> > sst --add-lib-path=./ sst/example.py;
> > ```
> >
> > We appreciate your help!
> >
> > Regards,
> > Hoa Nguyen
> >
> > On 12/8/21, Jason Lowe-Power  wrote:
> > > Hey Gabe,
> > >
> > > This change breaks the SST integration. In the SST integration
> python is
> > > initialized from the SST module, not from init.cc (this is because
> SST has
> > > their own python interpreter).
> > >
> > > We would appreciate some help in fixing this. Hoa and Giacomo can
> give you
> > > an example that's breaking to help you fix it, I believe.
> > >
> > > https://gem5-review.googlesource.com/c/public/gem5/+/49413
> > >
> > > There's strong interest in having the SST integration working 

[gem5-dev] Re: Broken SST due to python changes

[Gabe Black via gem5-dev]

Dumb question: I'm trying to run gdb inside this container on the sst
thing. How do I do that? It's not installed in the container now, and I
can't (easily) figure out how to get it installed. I can tell docker to
install it, but then it seems to throw that away as soon as the command
ends.

Gabe

On Fri, Dec 10, 2021 at 5:09 PM Bobby Bruce  wrote:

> Thanks Gabe,
>
> This is very much appreciated. I'm going to create the release staging
> once a couple more things get in. Feel free to push any patches related to
> these bugs to the release staging branch.
>
> If there is an order of priority I'd say the bug affecting SST is of
> higher importance than that affecting the Weeklies (as far as I can see the
> latter is hard to trigger). That being said, we'll apply both to the new
> release one way or another.
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Fri, Dec 10, 2021 at 5:02 PM Gabe Black  wrote:
>
>> Hi Bobby, not yet, I meant to look into this for the last couple days but
>> kept running out of time. I'm sitting down to work on it right now.
>>
>> Gabe
>>
>> On Fri, Dec 10, 2021 at 1:21 PM Bobby Bruce  wrote:
>>
>>> Hey Gabe,
>>>
>>> Is there any update on this?
>>>
>>> Kind regards,
>>> Bobby
>>> --
>>> Dr. Bobby R. Bruce
>>> Room 3050,
>>> Kemper Hall, UC Davis
>>> Davis,
>>> CA, 95616
>>>
>>> web: https://www.bobbybruce.net
>>>
>>>
>>> On Wed, Dec 8, 2021 at 5:51 PM Hoa Nguyen via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
 Hi Gabe,

 I have more details about this. In this use case, SST initialized the
 Python environment before adding the "gem5 object". This gem5 object
 will add more Python stuff from gem5 to the environment.

 The function that does that is initPython()

 https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/ext/sst/gem5.cc#415

 The following commands will pull the docker image for SST testing
 purposes (note that host_gem5_root and guest_gem5_root must be
 specified),

 ```
 docker run -u $UID:$GID --volume
 "${host_gem5_root}":"${guest_gem5_root}" -w \
  "${guest_gem5_root}" --rm gcr.io/gem5-test/sst-env \
  bash -c "\
 scons build/RISCV/libgem5_opt.so -j${nproc} --without-tcmalloc; \
 cd ext/sst; \
 make clean; make; \
 sst --add-lib-path=./ sst/example.py;
 ```

 We appreciate your help!

 Regards,
 Hoa Nguyen

 On 12/8/21, Jason Lowe-Power  wrote:
 > Hey Gabe,
 >
 > This change breaks the SST integration. In the SST integration python
 is
 > initialized from the SST module, not from init.cc (this is because
 SST has
 > their own python interpreter).
 >
 > We would appreciate some help in fixing this. Hoa and Giacomo can
 give you
 > an example that's breaking to help you fix it, I believe.
 >
 > https://gem5-review.googlesource.com/c/public/gem5/+/49413
 >
 > There's strong interest in having the SST integration working in this
 > current release. We've spent a lot of time figuring out all of the
 > intricacies and would appreciate any help you can provide in these
 last few
 > days before the release!
 >
 > Thanks!
 >
 > Jason
 >
 ___
 gem5-dev mailing list -- gem5-dev@gem5.org
 To unsubscribe send an email to gem5-dev-le...@gem5.org
 %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

>>>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Broken SST due to python changes

[Gabe Black via gem5-dev]

Hi Bobby, not yet, I meant to look into this for the last couple days but
kept running out of time. I'm sitting down to work on it right now.

Gabe

On Fri, Dec 10, 2021 at 1:21 PM Bobby Bruce  wrote:

> Hey Gabe,
>
> Is there any update on this?
>
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Wed, Dec 8, 2021 at 5:51 PM Hoa Nguyen via gem5-dev 
> wrote:
>
>> Hi Gabe,
>>
>> I have more details about this. In this use case, SST initialized the
>> Python environment before adding the "gem5 object". This gem5 object
>> will add more Python stuff from gem5 to the environment.
>>
>> The function that does that is initPython()
>>
>> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/ext/sst/gem5.cc#415
>>
>> The following commands will pull the docker image for SST testing
>> purposes (note that host_gem5_root and guest_gem5_root must be
>> specified),
>>
>> ```
>> docker run -u $UID:$GID --volume "${host_gem5_root}":"${guest_gem5_root}"
>> -w \
>>  "${guest_gem5_root}" --rm gcr.io/gem5-test/sst-env \
>>  bash -c "\
>> scons build/RISCV/libgem5_opt.so -j${nproc} --without-tcmalloc; \
>> cd ext/sst; \
>> make clean; make; \
>> sst --add-lib-path=./ sst/example.py;
>> ```
>>
>> We appreciate your help!
>>
>> Regards,
>> Hoa Nguyen
>>
>> On 12/8/21, Jason Lowe-Power  wrote:
>> > Hey Gabe,
>> >
>> > This change breaks the SST integration. In the SST integration python is
>> > initialized from the SST module, not from init.cc (this is because SST
>> has
>> > their own python interpreter).
>> >
>> > We would appreciate some help in fixing this. Hoa and Giacomo can give
>> you
>> > an example that's breaking to help you fix it, I believe.
>> >
>> > https://gem5-review.googlesource.com/c/public/gem5/+/49413
>> >
>> > There's strong interest in having the SST integration working in this
>> > current release. We've spent a lot of time figuring out all of the
>> > intricacies and would appreciate any help you can provide in these last
>> few
>> > days before the release!
>> >
>> > Thanks!
>> >
>> > Jason
>> >
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: redundant builds in the long regressions

[Gabe Black via gem5-dev]

Ok, great, thanks!

On Mon, Dec 6, 2021 at 11:20 AM Bobby Bruce  wrote:

> Hey Gabe,
>
> That change is still in review:
> https://gem5-review.googlesource.com/c/public/gem5/+/53503
>
> I just wanted to get a few more eyes on it before submitting. You are
> correct, after this is merged we'll no longer need to compile
> X86_MESI_Two_Level and vanilla X86.
>
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Mon, Dec 6, 2021 at 4:42 AM Gabe Black  wrote:
>
>> And also GCN3_X86, which hadn't started yet.
>>
>> On Mon, Dec 6, 2021 at 4:27 AM Gabe Black  wrote:
>>
>>> Hi Bobby and other folks. While I'm waiting for reviews on my register
>>> related multiISA patch series, I'm running long regressions on it to try to
>>> preemptively track down any bugs that might be in it.
>>>
>>> I notice that the test framework is build both
>>> build/X86_MESI_Two_Level/gem5.opt and build/X86/gem5.opt. I think I
>>> remember Bobby changing the ruby protocol of X86 to default to
>>> MESI_Two_Level (or similar? Not yet checked in?), so having both versions
>>> of X86 seem particularly redundant.
>>>
>>> I think this is less of a problem for the long regressions, but it would
>>> still be nice/more efficient to get rid of the redundancy.
>>>
>>> Gabe
>>>
>>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: redundant builds in the long regressions

[Gabe Black via gem5-dev]

And also GCN3_X86, which hadn't started yet.

On Mon, Dec 6, 2021 at 4:27 AM Gabe Black  wrote:

> Hi Bobby and other folks. While I'm waiting for reviews on my register
> related multiISA patch series, I'm running long regressions on it to try to
> preemptively track down any bugs that might be in it.
>
> I notice that the test framework is build both
> build/X86_MESI_Two_Level/gem5.opt and build/X86/gem5.opt. I think I
> remember Bobby changing the ruby protocol of X86 to default to
> MESI_Two_Level (or similar? Not yet checked in?), so having both versions
> of X86 seem particularly redundant.
>
> I think this is less of a problem for the long regressions, but it would
> still be nice/more efficient to get rid of the redundancy.
>
> Gabe
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] redundant builds in the long regressions

[Gabe Black via gem5-dev]

Hi Bobby and other folks. While I'm waiting for reviews on my register
related multiISA patch series, I'm running long regressions on it to try to
preemptively track down any bugs that might be in it.

I notice that the test framework is build both
build/X86_MESI_Two_Level/gem5.opt and build/X86/gem5.opt. I think I
remember Bobby changing the ruby protocol of X86 to default to
MESI_Two_Level (or similar? Not yet checked in?), so having both versions
of X86 seem particularly redundant.

I think this is less of a problem for the long regressions, but it would
still be nice/more efficient to get rid of the redundancy.

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: nightly #48

[Gabe Black via gem5-dev]

I think this is the problem:

scons: `build/NULL/unittests.perf' is up to date.
scons: `build/NULL/unittests.prof' is up to date.

The prof and perf suffixes are no more. Those probably shouldn't have been
using prof or perf anyway, at least not exclusively, because we definitely
want asserts, etc, turned on when running tests, and perf/prof used fast as
a template.

Gabe

On Fri, Nov 19, 2021 at 4:39 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See  >
>
> Changes:
>
> [gabe.black] sim: Remove some old transitional code in SEWorkload.
>
> [gabe.black] cpu: Get rid of the BaseCPU UnifiedTLB parameter.
>
> [gabe.black] cpu: Remove an architecture check in addPrivateSplitL1Caches.
>
> [gabe.black] cpu: Set up _*_ports values in BaseCPU in __init__.
>
> [Bobby R. Bruce] stdlib: Fix RISCVBoard when running O3 CPU with Ruby
>
>
> --
> [...truncated 705.02 KB...]
> [   OK ] LoggingFixture.VariadicCharPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicStringPrint
> [   OK ] LoggingFixture.VariadicStringPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicCharMissingPrint
> [   OK ] LoggingFixture.VariadicCharMissingPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicStringMissingPrint
> [   OK ] LoggingFixture.VariadicStringMissingPrint (0 ms)
> [ RUN  ] LoggingFixture.DisabledPrint
> [   OK ] LoggingFixture.DisabledPrint (0 ms)
> [ RUN  ] LoggingFixture.WarnLoggerPrint
> [   OK ] LoggingFixture.WarnLoggerPrint (1 ms)
> [ RUN  ] LoggingFixture.InfoLoggerPrint
> [   OK ] LoggingFixture.InfoLoggerPrint (0 ms)
> [ RUN  ] LoggingFixture.HackLoggerPrint
> [   OK ] LoggingFixture.HackLoggerPrint (0 ms)
> [ RUN  ] LoggingFixture.FatalLoggerPrint
> [   OK ] LoggingFixture.FatalLoggerPrint (0 ms)
> [ RUN  ] LoggingFixture.PanicLoggerPrint
> [   OK ] LoggingFixture.PanicLoggerPrint (0 ms)
> [ RUN  ] LoggingFixture.BaseMessage
> [   OK ] LoggingFixture.BaseMessage (0 ms)
> [ RUN  ] LoggingFixture.BaseMessageOnce
> [   OK ] LoggingFixture.BaseMessageOnce (0 ms)
> [ RUN  ] LoggingFixture.Warn
> [   OK ] LoggingFixture.Warn (0 ms)
> [ RUN  ] LoggingFixture.Inform
> [   OK ] LoggingFixture.Inform (0 ms)
> [ RUN  ] LoggingFixture.Hack
> [   OK ] LoggingFixture.Hack (0 ms)
> [ RUN  ] LoggingFixture.WarnOnce
> [   OK ] LoggingFixture.WarnOnce (0 ms)
> [ RUN  ] LoggingFixture.InformOnce
> [   OK ] LoggingFixture.InformOnce (0 ms)
> [ RUN  ] LoggingFixture.HackOnce
> [   OK ] LoggingFixture.HackOnce (0 ms)
> [ RUN  ] LoggingFixture.WarnIf
> [   OK ] LoggingFixture.WarnIf (0 ms)
> [ RUN  ] LoggingFixture.WarnIfOnce
> [   OK ] LoggingFixture.WarnIfOnce (0 ms)
> [--] 21 tests from LoggingFixture (1 ms total)
>
> [--] Global test environment tear-down
> [==] 34 tests from 2 test suites ran. (1647 ms total)
> [  PASSED  ] 34 tests.
> scons: done building targets.
> *** Summary of Warnings ***
> Warning: Deprecated namespaces are not supported by this compiler.
>  Please make sure to check the mailing list for deprecation
>  announcements.
> + unit_test perf
> + build=perf
> + docker run -u 118: --volume
> /nobackup/jenkins/workspace/nightly/tests/..:/nobackup/jenkins/workspace/nightly/tests/..
> -w /nobackup/jenkins/workspace/nightly/tests/.. --rm
> gcr.io/gem5-test/ubuntu-20.04_all-dependencies scons
> build/NULL/unittests.perf -j16
> scons: Reading SConscript files ...
> Checking for linker -Wl,--as-needed support... (cached) yes
> Checking for compiler -Wno-free-nonheap-object support... (cached) yes
> Checking for compiler -gz support... (cached) yes
> Checking for linker -gz support... (cached) yes
> Info: Using Python config: python3-config
> Checking for C header file Python.h... (cached) yes
> Checking Python version... (cached) 3.8.10
> Checking for accept(0,0,0) in C++ library None... (cached) yes
> Checking for zlibVersion() in C++ library z... (cached) yes
> Checking for C library tcmalloc... (cached) yes
> Checking for C header file fenv.h... (cached) yes
> Checking for C header file png.h... (cached) yes
> Checking for clock_nanosleep(0,0,NULL,NULL) in C library None... (cached)
> yes
> Checking for C header file valgrind/valgrind.h... (cached) no
> Warning: Deprecated namespaces are not supported by this compiler.
>  Please make sure to check the mailing list for deprecation
>  announcements.
> Checking for pkg-config package hdf5-serial... (cached) yes
> Checking for H5Fcreate("", 0, 0, 0) in C library hdf5... (cached) yes
> Checking for H5::H5File("", 0) in C++ library hdf5_cpp... (cached) yes
> Checking for C header file linux/kvm.h... (cached) yes
> Checking for timer_create(CLOCK_MONOTONIC, NULL, NULL) in C library
> None... (cached) no
> Checking for timer_create(CLOCK_MONOTONIC, NULL, NULL) 

[gem5-dev] Re: Gem5 on MacOS/clang --as-needed flag detection

[Gabe Black via gem5-dev]

Hi Arun, thanks for letting us know about this. Would you mind creating a
bug on Jira? https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues

I'll have to look at this more closely, but I think this is a bug in the
CheckLinkFlag check, where it should not set SHLINKFLAGS even if
set_for_shared is enabled if ret is False. I don't think we want to disable
set_for_shared, even though in this case it has the effect of also
disabling that "if", which compensates for the fact that it's not checking
ret.

Like I said I'll look at the history of this code to see if I'm missing
something, but I think working "ret" into the check for SHLINKFLAGS is
probably what the fix should be. Could you try that? And if that works for
you, would you mind uploading a fix? https://www.gem5.org/contributing
Please add me as a reviewer if you do.

Gabe

On Thu, Nov 18, 2021 at 3:53 PM Rodrigues, Arun F via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hello,
>
>
>
> I’m running into some issues building libgem5 on MacOS using clang. The
> build compiles correctly, but fails during linking because the LLVM linker
> doesn’t understand the –as-needed flag. It seems that gem5 is incorrectly
> passing this flag.
>
>
>
> Buildline:
>
> scons build/RISCV/libgem5_opt.dylib -j 8 --without-tcmalloc
>
>
>
> Failure:
>
> [  SHLINK]  -> RISCV/libgem5_opt.dylib
>
> ld: unknown option: --as-needed
>
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> scons: *** [build/RISCV/libgem5_opt.dylib] Error 1
>
>
>
> The toplevel SConstruct file, line 343 has:
>
>
>
> conf.CheckLinkFlag('-Wl,--as-needed')
>
>
>
> On MacOS with clang, this check returns ‘no’ since the clang linker
> doesn’t take the –as-needed flag. But, it seems that CheckLinkFlag()’s
> default behavior (set_for_shared=True) seems to be to append the flag, even
> if the config test fails.
>
>
>
> Configure.py:
>
>
>
> def CheckLinkFlag(context, flag, autoadd=True, set_for_shared=True):
>
> context.Message("Checking for linker %s support... " % flag)
>
> last_linkflags = context.env['LINKFLAGS']
>
> context.env.Append(LINKFLAGS=[flag])
>
> ret = context.TryLink('int main(int, char *[]) { return 0; }', '.cc')
>
> if not (ret and autoadd):
>
> context.env['LINKFLAGS'] = last_linkflags
>
> if set_for_shared:
>
> assert(autoadd)
>
> context.env.Append(SHLINKFLAGS=[flag])
>
> context.Result(ret)
>
> return ret
>
>
>
> This results in the linking phase failing on MacOS.
>
>
>
> I was able to get it to build by changing the toplevel SConstruct to:
>
>conf.CheckLinkFlag('-Wl,--as-needed', True, False)
>
>
>
> I’m not too familiar with the –as-needed flag and why it is needed, so I’m
> wondering:
>
>- Does this fix seem reasonable?
>- Is the CheckLinkFlag() behavior correct? Should the flag be appended
>to SHLINKFLAGS even if the test fails?
>
>
>
> Additional info:
>
>- Clang/clang++ Apple clang version 11.0.0 (clang-1100.0.33.17)
>- Uname -a: Darwin s1033894 19.6.0 Darwin Kernel Version 19.6.0: Sun
>Jul  5 00:43:10 PDT 2020; root:xnu-6153.141.1~9/RELEASE_X86_64 x86_64
>
>
>
> Thanks,
>
>
>
> arun
>
>
>
>
>
>
>
> Thanks,
>
>
>
> arun
>
>
>
>
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: failing kvm tests

[Gabe Black via gem5-dev]

On this topic, I commented on the already merged CL, but this change breaks
the quick KVM regressions:

https://gem5-review.googlesource.com/c/public/gem5/+/52183

On Mon, Nov 8, 2021 at 11:46 AM Bobby Bruce  wrote:

> Yip, I accidentally added some X86 tests to the quick/Kokoro tests. Thanks
> for pointing that out. The fix can be found here:
> https://gem5-review.googlesource.com/c/public/gem5/+/52563
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Mon, Nov 8, 2021 at 5:03 AM Gabe Black  wrote:
>
>> Just a quick note, I noticed when running quick regressions now that it
>> builds both GC_X86 and X86. I'm assuming that's because the KVM tests are
>> still set up to use X86? It would be nice to fix that to avoid building for
>> an additional target.
>>
>> Gabe
>>
>> On Wed, Nov 3, 2021 at 10:55 AM Bobby Bruce  wrote:
>>
>>> Hey Gabe,
>>>
>>> At present our Jenkins doesn't have KVM enabled so I believe no tests
>>> that use KVM were being run regularly. I intend to get KVM enabled on the
>>> Jenkins server over the next few days. I also found the bugs you were
>>> referring to when running the long (nightly) and very-long (weekly) tests
>>> on my local machine (where I have KVM). The long tests are fixed with this
>>> patch: https://gem5-review.googlesource.com/c/public/gem5/+/52384, and
>>> I'm currently looking into the bugs in the very-long tests.
>>>
>>> Kind regards,
>>> Bobby
>>> --
>>> Dr. Bobby R. Bruce
>>> Room 3050,
>>> Kemper Hall, UC Davis
>>> Davis,
>>> CA, 95616
>>>
>>> web: https://www.bobbybruce.net
>>>
>>>
>>> On Wed, Nov 3, 2021 at 4:22 AM Gabe Black via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
>>>> Hey folks, I recently discovered KVM wasn't set up on my desktop, which
>>>> I just corrected. Now that it's enabled, the KVM tests have started
>>>> running, and they are also failing. This could be sort of weird issue on my
>>>> machine, and I'm currently looking into the failure itself.
>>>>
>>>> The thing I wanted to ask was, do we have any KVM tests that run
>>>> anywhere? Do we have them in the quick regressions but not the long
>>>> regressions? Do we have KVM enabled on the nightly server? I can imagine it
>>>> (KVM) not being enabled on kokoro, but hopefully we can run those on the
>>>> nightlies?
>>>>
>>>> Gabe
>>>> ___
>>>> gem5-dev mailing list -- gem5-dev@gem5.org
>>>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>
>>>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: multi-ISA gem5 proof of concept

[Gabe Black via gem5-dev]

On Mon, Nov 8, 2021 at 2:13 PM Gabe Black  wrote:

>
>
> On Mon, Nov 8, 2021 at 8:40 AM Jason Lowe-Power 
> wrote:
>
>> This looks quite promising! Uploading a branch to gerrit is a good idea.
>>
>
> Ok, I'll do that. All but 4 of the changes in this composite branch are
> uploaded for review, and these few extras are because they depend on all of
> the switching header files being gone.
>
>

https://gem5.googlesource.com/public/gem5/+/refs/heads/multi-isa
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: multi-ISA gem5 proof of concept

[Gabe Black via gem5-dev]

This is discussed here:

https://gem5.atlassian.net/browse/GEM5-1058

The CPUs are ISA specific as used, and this makes that more explicit. It
also makes it clear whether a CPU is supported with a particular ISA, since
if it isn't, it's not possible to put it into a config without adding the
plumbing.

By having those ISA specific CPU variants, they just show up as options for
--cpu-type which makes se.py usable without modification. It would be
possible to make configs work with an option like --isa, but there are at
least three problems with that sort of approach.

First, we should move away from this swiss army knife approach to writing
configs where it can do anything, and we try to figure out how to make it
work with complicated logic in the config. It's not likely that someone
doing research would need to be able to transparently switch from using X86
to using RISCV without changing their config.

Second, while many of our existing configs are single ISA, that is not
required. On this branch, you could write a config which uses all 6 ISAs
simultaneously as different machines in the same simulation, or even as a
single frankenstein machine. Practically speaking, that can be useful (or
even necessary) if there are different types of devices talking to each
other in a network, or if the main SOC or application processor uses one
architecture, but then subcomponents like accelerators, peripherals,
management processors, etc, use some other architecture. On modern systems,
there are usually many additional CPUs tucked into all kinds of places
running various firmwares, and they don't always use the same ISA as the
user sees.

Third, that perpetuates having a big drop down box with ISAs on it, as if
ISAs were paint that could be applied to a system after it was constructed,
and as if ISAs were single, well defined options which were completely
defined by this one choice. There are many variations of ARM CPUs, x86
CPUs, etc, and in RISCV there are even supposedly many variations of the
ISA itself, depending on what extensions are enabled. Which ISA you pick is
more integral and more specific than we've treated it in our configs, and
using a --isa option would continue to bake that in.

That said, while I think having a --isa option has a lot of problems and is
not a good practice, exactly how a config script decides what components to
use is really up to that script. If we want to build some mechanism which
uses tables or long if-then trees in functions to figure out how to build
up a system with a given ISA, nothing here would stop that.

Gabe

On Mon, Nov 8, 2021 at 11:03 AM Bobby Bruce  wrote:

> Looks good to me.
>
> Perhaps this is explained elsewhere, but what's the logic in coupling the
> CPU Type (Timing, Atomic, o3) with the ISA? Why do we interact with this
> like `--cpu-type=X86AtomicSimpleCPU` and not `--cpu-type AtomicSimpleCPU
> --isa=X86`? Current CPU types are switchable during a simulation, so they
> are a parameter that can change, but the simulation's ISA, I assume, will
> always fixed for the entirety of a run.
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Mon, Nov 8, 2021 at 8:40 AM Jason Lowe-Power via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> This looks quite promising! Uploading a branch to gerrit is a good idea.
>>
>> A couple of notes:
>> 1. We are going to have to be very careful with when/how we merge this
>> and its effect on users. For instance, changing the CPU from
>> "AtomicSimpleCPU" to "ArmAtomicSimpleCPU" will break many users' use cases.
>> 2. I just noticed that there's something wrong with the Arm hello
>> application: "Simulated exit code not 0! Exit code is 13" It looks like
>> current develop also has this problem, but it's a bit worrying. I can't
>> figure out why the hello application wouldn't exit with code 0...
>>
>> Cheers,
>> Jason
>>
>> On Sun, Nov 7, 2021 at 5:38 PM Gabe Black via gem5-dev 
>> wrote:
>>
>>> Build performance improvements:
>>>
>>>
>>> Building all 6 ISAs separately.
>>>
>>> $ time scons build/ARM/gem5.opt build/MIPS/gem5.opt build/POWER/gem5.opt
>>> build/RISCV/gem5.opt build/SPARC/gem5.opt build/X86/gem5.opt
>>>
>>> real37m0.210s
>>> user764m20.963s
>>> sys 46m18.113s
>>>
>>> $ du -sh build
>>> 16G build
>>>
>>>
>>> Building "ALL" which has all 6 ISAs enabled together.
>>>
>>> $ time scons build/ALL/gem5.opt
>>>
>>> real10m28.289s
>>> user194m31.505s
>>> sys 9m36.281s
>>>
>>> $ du -sh build
>&

[gem5-dev] Re: multi-ISA gem5 proof of concept

[Gabe Black via gem5-dev]

On Mon, Nov 8, 2021 at 8:40 AM Jason Lowe-Power  wrote:

> This looks quite promising! Uploading a branch to gerrit is a good idea.
>

Ok, I'll do that. All but 4 of the changes in this composite branch are
uploaded for review, and these few extras are because they depend on all of
the switching header files being gone.


>
> A couple of notes:
> 1. We are going to have to be very careful with when/how we merge this and
> its effect on users. For instance, changing the CPU from "AtomicSimpleCPU"
> to "ArmAtomicSimpleCPU" will break many users' use cases.
>

As written, are compatibility aliases which are enabled if there is exactly
one ISA enabled, so existing users will be able to keep using their
existing build configuration and config scripts, as will we as we
transition things over.


> 2. I just noticed that there's something wrong with the Arm hello
> application: "Simulated exit code not 0! Exit code is 13" It looks like
> current develop also has this problem, but it's a bit worrying. I can't
> figure out why the hello application wouldn't exit with code 0...
>
>
This is a known issue. I think it was because we don't explicitly return
anything from main, and so the return value from printf is still in the
return value register, which is the number of characters printed.


> Cheers,
> Jason
>
> On Sun, Nov 7, 2021 at 5:38 PM Gabe Black via gem5-dev 
> wrote:
>
>> Build performance improvements:
>>
>>
>> Building all 6 ISAs separately.
>>
>> $ time scons build/ARM/gem5.opt build/MIPS/gem5.opt build/POWER/gem5.opt
>> build/RISCV/gem5.opt build/SPARC/gem5.opt build/X86/gem5.opt
>>
>> real37m0.210s
>> user764m20.963s
>> sys 46m18.113s
>>
>> $ du -sh build
>> 16G build
>>
>>
>> Building "ALL" which has all 6 ISAs enabled together.
>>
>> $ time scons build/ALL/gem5.opt
>>
>> real10m28.289s
>> user194m31.505s
>> sys 9m36.281s
>>
>> $ du -sh build
>> 4.2Gbuild
>>
>>
>> Which is a build time reduction of about 72% on my system, and a build
>> directory size reduction of about 73%.
>>
>> Gabe
>>
>> On Sat, Nov 6, 2021 at 12:29 AM Gabe Black  wrote:
>>
>>> As mentioned in the other thread, I can upload this hash as a branch on
>>> gerrit if people want to try it out.
>>>
>>> Gabe
>>>
>>> $ git log --oneline origin/develop..multiarch | wc -l
>>> 203
>>>
>>> $ build/ALL/gem5.opt configs/example/se.py --cpu-type=ArmAtomicSimpleCPU
>>> -c tests/test-progs/hello/bin/arm/linux/hello
>>> build/ALL/base/statistics.hh:280: warn: One of the stats is a legacy
>>> stat. Legacy stat is a stat that does not belong to any statistics::Group.
>>> Legacy stat is deprecated.
>>> gem5 Simulator System.  http://gem5.org
>>> gem5 is copyrighted software; use the --copyright option for details.
>>>
>>> gem5 version [DEVELOP-FOR-V21.2]
>>> gem5 compiled Nov  6 2021 00:23:55
>>> gem5 started Nov  6 2021 00:25:58
>>> gem5 executing on cake, pid 999191
>>> command line: build/ALL/gem5.opt configs/example/se.py
>>> --cpu-type=ArmAtomicSimpleCPU -c tests/test-progs/hello/bin/arm/linux/hello
>>>
>>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
>>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
>>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
>>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
>>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
>>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
>>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
>>> Global frequency set at 1 ticks per second
>>> build/ALL/mem/mem_interface.cc:791: warn: DRAM device capacity (8192
>>> Mbytes) does not match the address range assigned (512 Mbytes)
>>> 0: system.remote_gdb: listening for remote gdb on port 7000
>>>  REAL SIMULATION 
>>> build/ALL/sim/simulate.cc:194: info: Entering event queue @ 0.  Starting
>>> simulation...
>>> Hello world!
>>> Exiting @ tick 2916500 because exiting with last active thread context
>>> Simulated exit code not 0! Exit code is 13
>>>
>>>
>>>
>>> [gblack@cake work]$ build/ALL/gem5.opt configs/example/se.py
>>> --cpu-type=X86AtomicSimpleCPU -c tests/test-progs/hello/bin/x86/linux/hello
>>

[gem5-dev] Re: failing kvm tests

[Gabe Black via gem5-dev]

Just a quick note, I noticed when running quick regressions now that it
builds both GC_X86 and X86. I'm assuming that's because the KVM tests are
still set up to use X86? It would be nice to fix that to avoid building for
an additional target.

Gabe

On Wed, Nov 3, 2021 at 10:55 AM Bobby Bruce  wrote:

> Hey Gabe,
>
> At present our Jenkins doesn't have KVM enabled so I believe no tests
> that use KVM were being run regularly. I intend to get KVM enabled on the
> Jenkins server over the next few days. I also found the bugs you were
> referring to when running the long (nightly) and very-long (weekly) tests
> on my local machine (where I have KVM). The long tests are fixed with this
> patch: https://gem5-review.googlesource.com/c/public/gem5/+/52384, and
> I'm currently looking into the bugs in the very-long tests.
>
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Wed, Nov 3, 2021 at 4:22 AM Gabe Black via gem5-dev 
> wrote:
>
>> Hey folks, I recently discovered KVM wasn't set up on my desktop, which I
>> just corrected. Now that it's enabled, the KVM tests have started running,
>> and they are also failing. This could be sort of weird issue on my machine,
>> and I'm currently looking into the failure itself.
>>
>> The thing I wanted to ask was, do we have any KVM tests that run
>> anywhere? Do we have them in the quick regressions but not the long
>> regressions? Do we have KVM enabled on the nightly server? I can imagine it
>> (KVM) not being enabled on kokoro, but hopefully we can run those on the
>> nightlies?
>>
>> Gabe
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: multi-ISA gem5 proof of concept

[Gabe Black via gem5-dev]

Build performance improvements:


Building all 6 ISAs separately.

$ time scons build/ARM/gem5.opt build/MIPS/gem5.opt build/POWER/gem5.opt
build/RISCV/gem5.opt build/SPARC/gem5.opt build/X86/gem5.opt

real37m0.210s
user764m20.963s
sys 46m18.113s

$ du -sh build
16G build


Building "ALL" which has all 6 ISAs enabled together.

$ time scons build/ALL/gem5.opt

real10m28.289s
user194m31.505s
sys 9m36.281s

$ du -sh build
4.2Gbuild


Which is a build time reduction of about 72% on my system, and a build
directory size reduction of about 73%.

Gabe

On Sat, Nov 6, 2021 at 12:29 AM Gabe Black  wrote:

> As mentioned in the other thread, I can upload this hash as a branch on
> gerrit if people want to try it out.
>
> Gabe
>
> $ git log --oneline origin/develop..multiarch | wc -l
> 203
>
> $ build/ALL/gem5.opt configs/example/se.py --cpu-type=ArmAtomicSimpleCPU
> -c tests/test-progs/hello/bin/arm/linux/hello
> build/ALL/base/statistics.hh:280: warn: One of the stats is a legacy stat.
> Legacy stat is a stat that does not belong to any statistics::Group. Legacy
> stat is deprecated.
> gem5 Simulator System.  http://gem5.org
> gem5 is copyrighted software; use the --copyright option for details.
>
> gem5 version [DEVELOP-FOR-V21.2]
> gem5 compiled Nov  6 2021 00:23:55
> gem5 started Nov  6 2021 00:25:58
> gem5 executing on cake, pid 999191
> command line: build/ALL/gem5.opt configs/example/se.py
> --cpu-type=ArmAtomicSimpleCPU -c tests/test-progs/hello/bin/arm/linux/hello
>
> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
> Global frequency set at 1 ticks per second
> build/ALL/mem/mem_interface.cc:791: warn: DRAM device capacity (8192
> Mbytes) does not match the address range assigned (512 Mbytes)
> 0: system.remote_gdb: listening for remote gdb on port 7000
>  REAL SIMULATION 
> build/ALL/sim/simulate.cc:194: info: Entering event queue @ 0.  Starting
> simulation...
> Hello world!
> Exiting @ tick 2916500 because exiting with last active thread context
> Simulated exit code not 0! Exit code is 13
>
>
>
> [gblack@cake work]$ build/ALL/gem5.opt configs/example/se.py
> --cpu-type=X86AtomicSimpleCPU -c tests/test-progs/hello/bin/x86/linux/hello
> build/ALL/base/statistics.hh:280: warn: One of the stats is a legacy stat.
> Legacy stat is a stat that does not belong to any statistics::Group. Legacy
> stat is deprecated.
> gem5 Simulator System.  http://gem5.org
> gem5 is copyrighted software; use the --copyright option for details.
>
> gem5 version [DEVELOP-FOR-V21.2]
> gem5 compiled Nov  6 2021 00:23:55
> gem5 started Nov  6 2021 00:26:10
> gem5 executing on cake, pid 999224
> command line: build/ALL/gem5.opt configs/example/se.py
> --cpu-type=X86AtomicSimpleCPU -c tests/test-progs/hello/bin/x86/linux/hello
>
> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
> warn: membus.master is deprecated. `master` is now called `mem_side_ports`
> warn: membus.master is deprecated. `master` is now called `mem_side_ports`
> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
> Global frequency set at 1 ticks per second
> build/ALL/mem/mem_interface.cc:791: warn: DRAM device capacity (8192
> Mbytes) does not match the address range assigned (512 Mbytes)
> 0: system.remote_gdb: listening for remote gdb on port 7000
>  REAL SIMULATION 
> build/ALL/sim/simulate.cc:194: info: Entering event queue @ 0.  Starting
> simulation...
> Hello world!
> Exiting @ tick 5943000 because exiting with last active thread context
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] multi-ISA gem5 proof of concept

[Gabe Black via gem5-dev]

As mentioned in the other thread, I can upload this hash as a branch on
gerrit if people want to try it out.

Gabe

$ git log --oneline origin/develop..multiarch | wc -l
203

$ build/ALL/gem5.opt configs/example/se.py --cpu-type=ArmAtomicSimpleCPU -c
tests/test-progs/hello/bin/arm/linux/hello
build/ALL/base/statistics.hh:280: warn: One of the stats is a legacy stat.
Legacy stat is a stat that does not belong to any statistics::Group. Legacy
stat is deprecated.
gem5 Simulator System.  http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.

gem5 version [DEVELOP-FOR-V21.2]
gem5 compiled Nov  6 2021 00:23:55
gem5 started Nov  6 2021 00:25:58
gem5 executing on cake, pid 999191
command line: build/ALL/gem5.opt configs/example/se.py
--cpu-type=ArmAtomicSimpleCPU -c tests/test-progs/hello/bin/arm/linux/hello

warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
Global frequency set at 1 ticks per second
build/ALL/mem/mem_interface.cc:791: warn: DRAM device capacity (8192
Mbytes) does not match the address range assigned (512 Mbytes)
0: system.remote_gdb: listening for remote gdb on port 7000
 REAL SIMULATION 
build/ALL/sim/simulate.cc:194: info: Entering event queue @ 0.  Starting
simulation...
Hello world!
Exiting @ tick 2916500 because exiting with last active thread context
Simulated exit code not 0! Exit code is 13



[gblack@cake work]$ build/ALL/gem5.opt configs/example/se.py
--cpu-type=X86AtomicSimpleCPU -c tests/test-progs/hello/bin/x86/linux/hello
build/ALL/base/statistics.hh:280: warn: One of the stats is a legacy stat.
Legacy stat is a stat that does not belong to any statistics::Group. Legacy
stat is deprecated.
gem5 Simulator System.  http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.

gem5 version [DEVELOP-FOR-V21.2]
gem5 compiled Nov  6 2021 00:23:55
gem5 started Nov  6 2021 00:26:10
gem5 executing on cake, pid 999224
command line: build/ALL/gem5.opt configs/example/se.py
--cpu-type=X86AtomicSimpleCPU -c tests/test-progs/hello/bin/x86/linux/hello

warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
warn: membus.master is deprecated. `master` is now called `mem_side_ports`
warn: membus.master is deprecated. `master` is now called `mem_side_ports`
warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
Global frequency set at 1 ticks per second
build/ALL/mem/mem_interface.cc:791: warn: DRAM device capacity (8192
Mbytes) does not match the address range assigned (512 Mbytes)
0: system.remote_gdb: listening for remote gdb on port 7000
 REAL SIMULATION 
build/ALL/sim/simulate.cc:194: info: Entering event queue @ 0.  Starting
simulation...
Hello world!
Exiting @ tick 5943000 because exiting with last active thread context
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

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

[Gabe Black via gem5-dev]

;>>>>> Gabe
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Nov 3, 2021 at 12:45 PM Jason Lowe-Power <
>>>>>>>>>>>>>> ja...@lowepower.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here's my data:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> BAD * 4fe56ff72 - (3 months ago) arch-arm,cpu: Replace
>>>>>>>>>>>>>>> rename modes with split reg/elem register files. - Gabe Black
>>>>>>>>>>>>>>> GOOD * 25138cbb7 - (4 weeks ago) arch: Simplify and tidy up
>>>>>>>>>>>>>>> PCState classes. - Gabe Black
>>>>>>>>>>>>>>> * 930986332 - (7 days ago) mem: Fix whitespace in
>>>>>>>>>>>>>>> mem/ruby/system/Sequencer.py. - Gabe Black
>>>>>>>>>>>>>>> GOOD * 69e6ea485 - (3 months ago) arch-arm: Add walkBits
>>>>>>>>>>>>>>> method to PageTableOps - Giacomo Travaglini
>>>>>>>>>>>>>>> * 1268c6ec3 - (2 weeks ago) arch-arm: Expose LookupLevel
>>>>>>>>>>>>>>> enum to the python world - Giacomo Travaglini
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've tested this a number of times and tested commits before
>>>>>>>>>>>>>>> and after these commits. I have increasing confidence (though 
>>>>>>>>>>>>>>> no certainty)
>>>>>>>>>>>>>>> that 4fe56ff72 is the culprit.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm running a UBSAN now to see if that will help at all.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>> Jason
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Nov 2, 2021 at 5:28 PM Gabe Black <
>>>>>>>>>>>>>>> gabe.bl...@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm going to kill it now, and restart it with
>>>>>>>>>>>>>>>> --track-origins=yes and in a separate tree so I can keep 
>>>>>>>>>>>>>>>> working on other
>>>>>>>>>>>>>>>> things while it runs.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Gabe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Nov 2, 2021 at 5:11 PM Gabe Black <
>>>>>>>>>>>>>>>> gabe.bl...@gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It's still running, but here's what it's found so far.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Gabe
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tue, Nov 2, 2021 at 7:48 AM Jason Lowe-Power <
>>>>>>>>>>>>>>>>> ja...@lowepower.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks! I tried a bisect but, tbh, it wasn't helpful
>>>>>>>>>>>>>>>>>> since the error doesn't seem to be deterministic.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> As more evidence that it's a memory issue, the backtrace
>>>>>>>>>>>>>>>>>> that I saw with GDB was something a bit different.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Cheers,
>>>>

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

[Gabe Black via gem5-dev]

ublic/gem5/+/52406
>>>>>>>>>>>
>>>>>>>>>>> Gabe
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Nov 3, 2021 at 12:45 PM Jason Lowe-Power <
>>>>>>>>>>> ja...@lowepower.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Here's my data:
>>>>>>>>>>>>
>>>>>>>>>>>> BAD * 4fe56ff72 - (3 months ago) arch-arm,cpu: Replace rename
>>>>>>>>>>>> modes with split reg/elem register files. - Gabe Black
>>>>>>>>>>>> GOOD * 25138cbb7 - (4 weeks ago) arch: Simplify and tidy up
>>>>>>>>>>>> PCState classes. - Gabe Black
>>>>>>>>>>>> * 930986332 - (7 days ago) mem: Fix whitespace in
>>>>>>>>>>>> mem/ruby/system/Sequencer.py. - Gabe Black
>>>>>>>>>>>> GOOD * 69e6ea485 - (3 months ago) arch-arm: Add walkBits method
>>>>>>>>>>>> to PageTableOps - Giacomo Travaglini
>>>>>>>>>>>> * 1268c6ec3 - (2 weeks ago) arch-arm: Expose LookupLevel enum
>>>>>>>>>>>> to the python world - Giacomo Travaglini
>>>>>>>>>>>>
>>>>>>>>>>>> I've tested this a number of times and tested commits before
>>>>>>>>>>>> and after these commits. I have increasing confidence (though no 
>>>>>>>>>>>> certainty)
>>>>>>>>>>>> that 4fe56ff72 is the culprit.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm running a UBSAN now to see if that will help at all.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Jason
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Nov 2, 2021 at 5:28 PM Gabe Black 
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I'm going to kill it now, and restart it with
>>>>>>>>>>>>> --track-origins=yes and in a separate tree so I can keep working 
>>>>>>>>>>>>> on other
>>>>>>>>>>>>> things while it runs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Gabe
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Nov 2, 2021 at 5:11 PM Gabe Black <
>>>>>>>>>>>>> gabe.bl...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> It's still running, but here's what it's found so far.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Gabe
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Nov 2, 2021 at 7:48 AM Jason Lowe-Power <
>>>>>>>>>>>>>> ja...@lowepower.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks! I tried a bisect but, tbh, it wasn't helpful since
>>>>>>>>>>>>>>> the error doesn't seem to be deterministic.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As more evidence that it's a memory issue, the backtrace
>>>>>>>>>>>>>>> that I saw with GDB was something a bit different.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>> Jason
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Nov 2, 2021 at 5:07 AM Gabe Black <
>>>>>>>>>>>>>>> gabe.bl...@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm running it under valgrind to see if that tells me
>>>>>>>>>>>>>>>> anything, which is going t

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

[Gabe Black via gem5-dev]

>>>>>>>>>>>> if/when it
>>>>>>>>>>>>> finishes.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Gabe
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Nov 2, 2021 at 4:36 AM Gabe Black <
>>>>>>>>>>>>> gabe.bl...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Attached is a log of a failing run, and backtrace of the
>>>>>>>>>>>>>> segfault.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Gabe
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Nov 2, 2021 at 4:17 AM Gabe Black <
>>>>>>>>>>>>>> gabe.bl...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ok, I reproduced the segfault once, but then running again
>>>>>>>>>>>>>>> in gdb it exited normally. I'm pretty confident it's something 
>>>>>>>>>>>>>>> to do with
>>>>>>>>>>>>>>> things getting cleaned up and/or destructed at the end of the 
>>>>>>>>>>>>>>> simulation,
>>>>>>>>>>>>>>> but until I catch something in the act of exploding I won't be 
>>>>>>>>>>>>>>> able to nail
>>>>>>>>>>>>>>> down specifically what's doing it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Gabe
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Nov 2, 2021 at 3:46 AM Gabe Black <
>>>>>>>>>>>>>>> gabe.bl...@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A clean build seems to have fixed the IdeDisk problem.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Nov 2, 2021 at 3:35 AM Gabe Black <
>>>>>>>>>>>>>>>> gabe.bl...@gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Can you get a backtrace from it? Or run it in valgrind?
>>>>>>>>>>>>>>>>> I'm trying to use the command line you provided locally, but 
>>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>> complaining about not being able to find IdeDisk which is 
>>>>>>>>>>>>>>>>> very strange... I
>>>>>>>>>>>>>>>>> don't think I have an account on the machine where this ran, 
>>>>>>>>>>>>>>>>> but ideally
>>>>>>>>>>>>>>>>> I'll be able to reproduce it locally where it will be easier 
>>>>>>>>>>>>>>>>> to work with.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Gabe
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power <
>>>>>>>>>>>>>>>>> ja...@lowepower.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> After spending some time on this, there is definitely a
>>>>>>>>>>>>>>>>>> segfault at the end of execution. It's odd that the testing 
>>>>>>>>>>>>>>>>>> scripts
>>>>>>>>>>>>>>>>>> sometimes reports that it works.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If you run the following, you should see a segfault at
>>>>>>&

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

[Gabe Black via gem5-dev]

t.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Jason
>>>>>>>>>>
>>>>>>>>>> On Tue, Nov 2, 2021 at 5:07 AM Gabe Black 
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I'm running it under valgrind to see if that tells me anything,
>>>>>>>>>>> which is going to take a while. I'll let you know if/when it 
>>>>>>>>>>> finishes.
>>>>>>>>>>>
>>>>>>>>>>> Gabe
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Nov 2, 2021 at 4:36 AM Gabe Black 
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Attached is a log of a failing run, and backtrace of the
>>>>>>>>>>>> segfault.
>>>>>>>>>>>>
>>>>>>>>>>>> Gabe
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Nov 2, 2021 at 4:17 AM Gabe Black 
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Ok, I reproduced the segfault once, but then running again in
>>>>>>>>>>>>> gdb it exited normally. I'm pretty confident it's something to do 
>>>>>>>>>>>>> with
>>>>>>>>>>>>> things getting cleaned up and/or destructed at the end of the 
>>>>>>>>>>>>> simulation,
>>>>>>>>>>>>> but until I catch something in the act of exploding I won't be 
>>>>>>>>>>>>> able to nail
>>>>>>>>>>>>> down specifically what's doing it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Gabe
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Nov 2, 2021 at 3:46 AM Gabe Black <
>>>>>>>>>>>>> gabe.bl...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> A clean build seems to have fixed the IdeDisk problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Nov 2, 2021 at 3:35 AM Gabe Black <
>>>>>>>>>>>>>> gabe.bl...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Can you get a backtrace from it? Or run it in valgrind? I'm
>>>>>>>>>>>>>>> trying to use the command line you provided locally, but it's 
>>>>>>>>>>>>>>> complaining
>>>>>>>>>>>>>>> about not being able to find IdeDisk which is very strange... I 
>>>>>>>>>>>>>>> don't think
>>>>>>>>>>>>>>> I have an account on the machine where this ran, but ideally 
>>>>>>>>>>>>>>> I'll be able
>>>>>>>>>>>>>>> to reproduce it locally where it will be easier to work with.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Gabe
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power <
>>>>>>>>>>>>>>> ja...@lowepower.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> After spending some time on this, there is definitely a
>>>>>>>>>>>>>>>> segfault at the end of execution. It's odd that the testing 
>>>>>>>>>>>>>>>> scripts
>>>>>>>>>>>>>>>> sometimes reports that it works.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If you run the following, you should see a segfault at the
>>>>>>>>>>>>>>>

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

[Gabe Black via gem5-dev]

>>>>>> Gabe
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Nov 2, 2021 at 4:17 AM Gabe Black 
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Ok, I reproduced the segfault once, but then running again in
>>>>>>>>>>>> gdb it exited normally. I'm pretty confident it's something to do 
>>>>>>>>>>>> with
>>>>>>>>>>>> things getting cleaned up and/or destructed at the end of the 
>>>>>>>>>>>> simulation,
>>>>>>>>>>>> but until I catch something in the act of exploding I won't be 
>>>>>>>>>>>> able to nail
>>>>>>>>>>>> down specifically what's doing it.
>>>>>>>>>>>>
>>>>>>>>>>>> Gabe
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Nov 2, 2021 at 3:46 AM Gabe Black 
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> A clean build seems to have fixed the IdeDisk problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Nov 2, 2021 at 3:35 AM Gabe Black <
>>>>>>>>>>>>> gabe.bl...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Can you get a backtrace from it? Or run it in valgrind? I'm
>>>>>>>>>>>>>> trying to use the command line you provided locally, but it's 
>>>>>>>>>>>>>> complaining
>>>>>>>>>>>>>> about not being able to find IdeDisk which is very strange... I 
>>>>>>>>>>>>>> don't think
>>>>>>>>>>>>>> I have an account on the machine where this ran, but ideally 
>>>>>>>>>>>>>> I'll be able
>>>>>>>>>>>>>> to reproduce it locally where it will be easier to work with.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Gabe
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power <
>>>>>>>>>>>>>> ja...@lowepower.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> After spending some time on this, there is definitely a
>>>>>>>>>>>>>>> segfault at the end of execution. It's odd that the testing 
>>>>>>>>>>>>>>> scripts
>>>>>>>>>>>>>>> sometimes reports that it works.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If you run the following, you should see a segfault at the
>>>>>>>>>>>>>>> end and no stats are generated:
>>>>>>>>>>>>>>> ../gem5/> build/ARM/gem5.opt tests/gem5/fs/linux/arm/run.py
>>>>>>>>>>>>>>> tests/gem5/configs/realview-o3.py tests/gem5/resources/arm .
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I also notice that when it doesn't fail the following is
>>>>>>>>>>>>>>> printed:
>>>>>>>>>>>>>>> "build/ARM/arch/arm/isa.hh:650: warn: User mode does not
>>>>>>>>>>>>>>> have SPSR
>>>>>>>>>>>>>>> build/ARM/arch/arm/isa.hh:650: warn: User mode does not have
>>>>>>>>>>>>>>> SPSR"
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But it's not printed when it fails.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>> Jason
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>&g

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

[Gabe Black via gem5-dev]

 run, and backtrace of the segfault.
>>>>>>>>>
>>>>>>>>> Gabe
>>>>>>>>>
>>>>>>>>> On Tue, Nov 2, 2021 at 4:17 AM Gabe Black 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Ok, I reproduced the segfault once, but then running again in gdb
>>>>>>>>>> it exited normally. I'm pretty confident it's something to do with 
>>>>>>>>>> things
>>>>>>>>>> getting cleaned up and/or destructed at the end of the simulation, 
>>>>>>>>>> but
>>>>>>>>>> until I catch something in the act of exploding I won't be able to 
>>>>>>>>>> nail
>>>>>>>>>> down specifically what's doing it.
>>>>>>>>>>
>>>>>>>>>> Gabe
>>>>>>>>>>
>>>>>>>>>> On Tue, Nov 2, 2021 at 3:46 AM Gabe Black 
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> A clean build seems to have fixed the IdeDisk problem.
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Nov 2, 2021 at 3:35 AM Gabe Black 
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Can you get a backtrace from it? Or run it in valgrind? I'm
>>>>>>>>>>>> trying to use the command line you provided locally, but it's 
>>>>>>>>>>>> complaining
>>>>>>>>>>>> about not being able to find IdeDisk which is very strange... I 
>>>>>>>>>>>> don't think
>>>>>>>>>>>> I have an account on the machine where this ran, but ideally I'll 
>>>>>>>>>>>> be able
>>>>>>>>>>>> to reproduce it locally where it will be easier to work with.
>>>>>>>>>>>>
>>>>>>>>>>>> Gabe
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power <
>>>>>>>>>>>> ja...@lowepower.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> After spending some time on this, there is definitely a
>>>>>>>>>>>>> segfault at the end of execution. It's odd that the testing 
>>>>>>>>>>>>> scripts
>>>>>>>>>>>>> sometimes reports that it works.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you run the following, you should see a segfault at the end
>>>>>>>>>>>>> and no stats are generated:
>>>>>>>>>>>>> ../gem5/> build/ARM/gem5.opt tests/gem5/fs/linux/arm/run.py
>>>>>>>>>>>>> tests/gem5/configs/realview-o3.py tests/gem5/resources/arm .
>>>>>>>>>>>>>
>>>>>>>>>>>>> I also notice that when it doesn't fail the following is
>>>>>>>>>>>>> printed:
>>>>>>>>>>>>> "build/ARM/arch/arm/isa.hh:650: warn: User mode does not have
>>>>>>>>>>>>> SPSR
>>>>>>>>>>>>> build/ARM/arch/arm/isa.hh:650: warn: User mode does not have
>>>>>>>>>>>>> SPSR"
>>>>>>>>>>>>>
>>>>>>>>>>>>> But it's not printed when it fails.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Jason
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Nov 1, 2021 at 8:29 AM Jason Lowe-Power <
>>>>>>>>>>>>> ja...@lowepower.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't think so. The binaries haven't been updated since
>>>>>>>>>>>>>> April ('aarch-system-20210904.tar.bz2'). Well, the blame says 
>>

[gem5-dev] default m5ops_base to off on x86

[Gabe Black via gem5-dev]

Hey folks. One of the last things to sort out before I'd consider the gem5
mutli-ISA support at least usable is that the m5ops_base config parameter
defaults to zero, except if you're on x86 where it defaults to 0x.

I think it would make sense to instead default it to 0 all the time,
effectively disabled, and to expect a config to enable it even on x86 to
something that makes sense on that platform. Even though 0x may be
a typical address to use for x86, even there it might not be appropriate,
since that's where the BIOS would be if doing a bare metal boot. I think if
it's reasonable to expect other ISAs to have to set this address, x86
should be able to manage as well. There is already special handling in
se.py for the x86/kvm/se mode combination, so there is an easy place to
slot this setting in to at least that config.

I think this change makes sense, but before I changed behavior like that
(as opposed to just changing implementation), I wanted to check to see if
there are any strong opinions out there, or other suggestions for how to
handle this.

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

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

[Gabe Black via gem5-dev]

gt; things
>>>>>>>>> getting cleaned up and/or destructed at the end of the simulation, but
>>>>>>>>> until I catch something in the act of exploding I won't be able to 
>>>>>>>>> nail
>>>>>>>>> down specifically what's doing it.
>>>>>>>>>
>>>>>>>>> Gabe
>>>>>>>>>
>>>>>>>>> On Tue, Nov 2, 2021 at 3:46 AM Gabe Black 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> A clean build seems to have fixed the IdeDisk problem.
>>>>>>>>>>
>>>>>>>>>> On Tue, Nov 2, 2021 at 3:35 AM Gabe Black 
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Can you get a backtrace from it? Or run it in valgrind? I'm
>>>>>>>>>>> trying to use the command line you provided locally, but it's 
>>>>>>>>>>> complaining
>>>>>>>>>>> about not being able to find IdeDisk which is very strange... I 
>>>>>>>>>>> don't think
>>>>>>>>>>> I have an account on the machine where this ran, but ideally I'll 
>>>>>>>>>>> be able
>>>>>>>>>>> to reproduce it locally where it will be easier to work with.
>>>>>>>>>>>
>>>>>>>>>>> Gabe
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power <
>>>>>>>>>>> ja...@lowepower.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> After spending some time on this, there is definitely a
>>>>>>>>>>>> segfault at the end of execution. It's odd that the testing scripts
>>>>>>>>>>>> sometimes reports that it works.
>>>>>>>>>>>>
>>>>>>>>>>>> If you run the following, you should see a segfault at the end
>>>>>>>>>>>> and no stats are generated:
>>>>>>>>>>>> ../gem5/> build/ARM/gem5.opt tests/gem5/fs/linux/arm/run.py
>>>>>>>>>>>> tests/gem5/configs/realview-o3.py tests/gem5/resources/arm .
>>>>>>>>>>>>
>>>>>>>>>>>> I also notice that when it doesn't fail the following is
>>>>>>>>>>>> printed:
>>>>>>>>>>>> "build/ARM/arch/arm/isa.hh:650: warn: User mode does not have
>>>>>>>>>>>> SPSR
>>>>>>>>>>>> build/ARM/arch/arm/isa.hh:650: warn: User mode does not have
>>>>>>>>>>>> SPSR"
>>>>>>>>>>>>
>>>>>>>>>>>> But it's not printed when it fails.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Jason
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Nov 1, 2021 at 8:29 AM Jason Lowe-Power <
>>>>>>>>>>>> ja...@lowepower.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I don't think so. The binaries haven't been updated since
>>>>>>>>>>>>> April ('aarch-system-20210904.tar.bz2'). Well, the blame says 
>>>>>>>>>>>>> April even if
>>>>>>>>>>>>> the filename is confusing (DDMM?).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here's the failure:
>>>>>>>>>>>>> https://jenkins.gem5.org/job/nightly/ws/tests/testing-results/SuiteUID%3Arealview-o3-ARM-x86_64-opt/TestUID%3Arealview-o3-ARM-x86_64-opt/simerr
>>>>>>>>>>>>>
>>>>>>>>>>>>> build/ARM/arch/arm/insts/pseudo.cc:173: warn: instruction
>>>>>>>>>>>>> 'csdb' unimplemented
>>>>>>>>>>>>> build/ARM/arch/arm/generated/decoder-ns.cc.inc:100643: warn:
>>>>>>>>>>

[gem5-dev] Re: preview branch for mutli-ISA gem5?

[Gabe Black via gem5-dev]

To be clear, I'm not suggesting a branch that gets merged with develop at
some intersection point, I'm just suggesting a branch where the changes are
all stacked together so they're easy to try out. There are too many
interactions between these changes and the rest of gem5 to expect there not
to be disaster when trying to merge things if they've had time to stew
apart from each other. Trust me, it's been a pain to keep things working as
I've been rebasing them over time.

I just want people to be able to see what the end goal is, and that it's
working. Also there are people who are very interested in this capability,
and I want to make it easy for them to use it without having to wait for a
few months for the reviews to trickle through.

Gabe

On Thu, Nov 4, 2021 at 11:41 AM Bobby Bruce  wrote:

> I think it's a great idea and we should probably do it more often for this
> big long changes we don't want to straddle a release.
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Thu, Nov 4, 2021 at 7:42 AM Jason Lowe-Power via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Seems like a good idea to me! I like the idea of having more feature
>> branches for long-lived relation chains.
>>
>> Given the timing, it seems like it would be a good idea to hold off
>> integrating this until gem5 22.0. If we have a branch we can test for a
>> while, it will be less likely to break our users use cases.
>>
>> Cheers,
>> Jason
>>
>> On Wed, Nov 3, 2021 at 11:51 PM Gabe Black via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> Hey folks, I'm not quite ready for it yet, but I'm getting close to
>>> having everything at least written for a multi-ISA version of gem5. What do
>>> you think about having a preview branch on gerrit? I can create one pretty
>>> easily, I just want to make sure that's appropriate and something other
>>> people might be interested in before I do so. Like I said, I haven't gotten
>>> *quite* to the point where I have something useable, but I think I'm down
>>> to the last few things.
>>>
>>> Gabe
>>> ___
>>> gem5-dev mailing list -- gem5-dev@gem5.org
>>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

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

[Gabe Black via gem5-dev]

After spending some time on this, there is definitely a segfault
>>>>>>>>>> at the end of execution. It's odd that the testing scripts sometimes
>>>>>>>>>> reports that it works.
>>>>>>>>>>
>>>>>>>>>> If you run the following, you should see a segfault at the end
>>>>>>>>>> and no stats are generated:
>>>>>>>>>> ../gem5/> build/ARM/gem5.opt tests/gem5/fs/linux/arm/run.py
>>>>>>>>>> tests/gem5/configs/realview-o3.py tests/gem5/resources/arm .
>>>>>>>>>>
>>>>>>>>>> I also notice that when it doesn't fail the following is printed:
>>>>>>>>>> "build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR
>>>>>>>>>> build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR"
>>>>>>>>>>
>>>>>>>>>> But it's not printed when it fails.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Jason
>>>>>>>>>>
>>>>>>>>>> On Mon, Nov 1, 2021 at 8:29 AM Jason Lowe-Power <
>>>>>>>>>> ja...@lowepower.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I don't think so. The binaries haven't been updated since April
>>>>>>>>>>> ('aarch-system-20210904.tar.bz2'). Well, the blame says April even 
>>>>>>>>>>> if the
>>>>>>>>>>> filename is confusing (DDMM?).
>>>>>>>>>>>
>>>>>>>>>>> Here's the failure:
>>>>>>>>>>> https://jenkins.gem5.org/job/nightly/ws/tests/testing-results/SuiteUID%3Arealview-o3-ARM-x86_64-opt/TestUID%3Arealview-o3-ARM-x86_64-opt/simerr
>>>>>>>>>>>
>>>>>>>>>>> build/ARM/arch/arm/insts/pseudo.cc:173: warn: instruction 'csdb'
>>>>>>>>>>> unimplemented
>>>>>>>>>>> build/ARM/arch/arm/generated/decoder-ns.cc.inc:100643: warn:
>>>>>>>>>>> instruction 'mcr bpiall' unimplemented
>>>>>>>>>>> gem5 has encountered a segmentation fault!
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Jason
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Oct 30, 2021 at 4:11 AM Gabe Black via gem5-dev <
>>>>>>>>>>> gem5-dev@gem5.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Maybe you need to re-download the resources?
>>>>>>>>>>>>
>>>>>>>>>>>> Gabe
>>>>>>>>>>>>
>>>>>>>>>>>> On Sat, Oct 30, 2021 at 3:50 AM jenkins-no-reply--- via
>>>>>>>>>>>> gem5-dev  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> See <https://jenkins.gem5.org/job/nightly/27/display/redirect>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Changes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> [...truncated 809.58 KB...]
>>>>>>>>>>>>> [--] 4 tests from CheckpointInFixture
>>>>>>>>>>>>> [ RUN  ] CheckpointInFixture.FindSections
>>>>>>>>>>>>> [   OK ] CheckpointInFixture.FindSections (1 ms)
>>>>>>>>>>>>> [ RUN  ] CheckpointInFixture.FindEntries
>>>>>>>>>>>>> [   OK ] CheckpointInFixture.FindEntries (0 ms)
>>>>>>>>>>>>> [ RUN  ] CheckpointInFixture.ExtractEntries
>>>>>>>>>>>>> [   OK ] CheckpointInFixture.ExtractEntries (0 ms)
>>>>>>>>>>>>> [ RUN  ] CheckpointInFixture.SCSCptInPathScoped
>>>>>>>>>>>>> [  

[gem5-dev] preview branch for mutli-ISA gem5?

[Gabe Black via gem5-dev]

Hey folks, I'm not quite ready for it yet, but I'm getting close to having
everything at least written for a multi-ISA version of gem5. What do you
think about having a preview branch on gerrit? I can create one pretty
easily, I just want to make sure that's appropriate and something other
people might be interested in before I do so. Like I said, I haven't gotten
*quite* to the point where I have something useable, but I think I'm down
to the last few things.

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] failing kvm tests

[Gabe Black via gem5-dev]

Hey folks, I recently discovered KVM wasn't set up on my desktop, which I
just corrected. Now that it's enabled, the KVM tests have started running,
and they are also failing. This could be sort of weird issue on my machine,
and I'm currently looking into the failure itself.

The thing I wanted to ask was, do we have any KVM tests that run anywhere?
Do we have them in the quick regressions but not the long regressions? Do
we have KVM enabled on the nightly server? I can imagine it (KVM) not being
enabled on kokoro, but hopefully we can run those on the nightlies?

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

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

[Gabe Black via gem5-dev]

I'm running it under valgrind to see if that tells me anything, which is
going to take a while. I'll let you know if/when it finishes.

Gabe

On Tue, Nov 2, 2021 at 4:36 AM Gabe Black  wrote:

> Attached is a log of a failing run, and backtrace of the segfault.
>
> Gabe
>
> On Tue, Nov 2, 2021 at 4:17 AM Gabe Black  wrote:
>
>> Ok, I reproduced the segfault once, but then running again in gdb it
>> exited normally. I'm pretty confident it's something to do with things
>> getting cleaned up and/or destructed at the end of the simulation, but
>> until I catch something in the act of exploding I won't be able to nail
>> down specifically what's doing it.
>>
>> Gabe
>>
>> On Tue, Nov 2, 2021 at 3:46 AM Gabe Black  wrote:
>>
>>> A clean build seems to have fixed the IdeDisk problem.
>>>
>>> On Tue, Nov 2, 2021 at 3:35 AM Gabe Black  wrote:
>>>
>>>> Can you get a backtrace from it? Or run it in valgrind? I'm trying to
>>>> use the command line you provided locally, but it's complaining about not
>>>> being able to find IdeDisk which is very strange... I don't think I have an
>>>> account on the machine where this ran, but ideally I'll be able to
>>>> reproduce it locally where it will be easier to work with.
>>>>
>>>> Gabe
>>>>
>>>> On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power 
>>>> wrote:
>>>>
>>>>> After spending some time on this, there is definitely a segfault at
>>>>> the end of execution. It's odd that the testing scripts sometimes reports
>>>>> that it works.
>>>>>
>>>>> If you run the following, you should see a segfault at the end and no
>>>>> stats are generated:
>>>>> ../gem5/> build/ARM/gem5.opt tests/gem5/fs/linux/arm/run.py
>>>>> tests/gem5/configs/realview-o3.py tests/gem5/resources/arm .
>>>>>
>>>>> I also notice that when it doesn't fail the following is printed:
>>>>> "build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR
>>>>> build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR"
>>>>>
>>>>> But it's not printed when it fails.
>>>>>
>>>>> Cheers,
>>>>> Jason
>>>>>
>>>>> On Mon, Nov 1, 2021 at 8:29 AM Jason Lowe-Power 
>>>>> wrote:
>>>>>
>>>>>> I don't think so. The binaries haven't been updated since April
>>>>>> ('aarch-system-20210904.tar.bz2'). Well, the blame says April even if the
>>>>>> filename is confusing (DDMM?).
>>>>>>
>>>>>> Here's the failure:
>>>>>> https://jenkins.gem5.org/job/nightly/ws/tests/testing-results/SuiteUID%3Arealview-o3-ARM-x86_64-opt/TestUID%3Arealview-o3-ARM-x86_64-opt/simerr
>>>>>>
>>>>>> build/ARM/arch/arm/insts/pseudo.cc:173: warn: instruction 'csdb'
>>>>>> unimplemented
>>>>>> build/ARM/arch/arm/generated/decoder-ns.cc.inc:100643: warn:
>>>>>> instruction 'mcr bpiall' unimplemented
>>>>>> gem5 has encountered a segmentation fault!
>>>>>>
>>>>>> Cheers,
>>>>>> Jason
>>>>>>
>>>>>> On Sat, Oct 30, 2021 at 4:11 AM Gabe Black via gem5-dev <
>>>>>> gem5-dev@gem5.org> wrote:
>>>>>>
>>>>>>> Maybe you need to re-download the resources?
>>>>>>>
>>>>>>> Gabe
>>>>>>>
>>>>>>> On Sat, Oct 30, 2021 at 3:50 AM jenkins-no-reply--- via gem5-dev <
>>>>>>> gem5-dev@gem5.org> wrote:
>>>>>>>
>>>>>>>> See <https://jenkins.gem5.org/job/nightly/27/display/redirect>
>>>>>>>>
>>>>>>>> Changes:
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> [...truncated 809.58 KB...]
>>>>>>>> [--] 4 tests from CheckpointInFixture
>>>>>>>> [ RUN  ] CheckpointInFixture.FindSections
>>>>>>>> [   OK ] CheckpointInFixture.FindSections (1 ms)
>>>>>>>> [ RUN  ] CheckpointInFixture.FindEntries
>>>>>>>> [   OK ] CheckpointInFixture.FindEntries (0 ms)
>>>>>>

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

[Gabe Black via gem5-dev]

Attached is a log of a failing run, and backtrace of the segfault.

Gabe

On Tue, Nov 2, 2021 at 4:17 AM Gabe Black  wrote:

> Ok, I reproduced the segfault once, but then running again in gdb it
> exited normally. I'm pretty confident it's something to do with things
> getting cleaned up and/or destructed at the end of the simulation, but
> until I catch something in the act of exploding I won't be able to nail
> down specifically what's doing it.
>
> Gabe
>
> On Tue, Nov 2, 2021 at 3:46 AM Gabe Black  wrote:
>
>> A clean build seems to have fixed the IdeDisk problem.
>>
>> On Tue, Nov 2, 2021 at 3:35 AM Gabe Black  wrote:
>>
>>> Can you get a backtrace from it? Or run it in valgrind? I'm trying to
>>> use the command line you provided locally, but it's complaining about not
>>> being able to find IdeDisk which is very strange... I don't think I have an
>>> account on the machine where this ran, but ideally I'll be able to
>>> reproduce it locally where it will be easier to work with.
>>>
>>> Gabe
>>>
>>> On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power 
>>> wrote:
>>>
>>>> After spending some time on this, there is definitely a segfault at the
>>>> end of execution. It's odd that the testing scripts sometimes reports that
>>>> it works.
>>>>
>>>> If you run the following, you should see a segfault at the end and no
>>>> stats are generated:
>>>> ../gem5/> build/ARM/gem5.opt tests/gem5/fs/linux/arm/run.py
>>>> tests/gem5/configs/realview-o3.py tests/gem5/resources/arm .
>>>>
>>>> I also notice that when it doesn't fail the following is printed:
>>>> "build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR
>>>> build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR"
>>>>
>>>> But it's not printed when it fails.
>>>>
>>>> Cheers,
>>>> Jason
>>>>
>>>> On Mon, Nov 1, 2021 at 8:29 AM Jason Lowe-Power 
>>>> wrote:
>>>>
>>>>> I don't think so. The binaries haven't been updated since April
>>>>> ('aarch-system-20210904.tar.bz2'). Well, the blame says April even if the
>>>>> filename is confusing (DDMM?).
>>>>>
>>>>> Here's the failure:
>>>>> https://jenkins.gem5.org/job/nightly/ws/tests/testing-results/SuiteUID%3Arealview-o3-ARM-x86_64-opt/TestUID%3Arealview-o3-ARM-x86_64-opt/simerr
>>>>>
>>>>> build/ARM/arch/arm/insts/pseudo.cc:173: warn: instruction 'csdb'
>>>>> unimplemented
>>>>> build/ARM/arch/arm/generated/decoder-ns.cc.inc:100643: warn:
>>>>> instruction 'mcr bpiall' unimplemented
>>>>> gem5 has encountered a segmentation fault!
>>>>>
>>>>> Cheers,
>>>>> Jason
>>>>>
>>>>> On Sat, Oct 30, 2021 at 4:11 AM Gabe Black via gem5-dev <
>>>>> gem5-dev@gem5.org> wrote:
>>>>>
>>>>>> Maybe you need to re-download the resources?
>>>>>>
>>>>>> Gabe
>>>>>>
>>>>>> On Sat, Oct 30, 2021 at 3:50 AM jenkins-no-reply--- via gem5-dev <
>>>>>> gem5-dev@gem5.org> wrote:
>>>>>>
>>>>>>> See <https://jenkins.gem5.org/job/nightly/27/display/redirect>
>>>>>>>
>>>>>>> Changes:
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> [...truncated 809.58 KB...]
>>>>>>> [--] 4 tests from CheckpointInFixture
>>>>>>> [ RUN  ] CheckpointInFixture.FindSections
>>>>>>> [   OK ] CheckpointInFixture.FindSections (1 ms)
>>>>>>> [ RUN  ] CheckpointInFixture.FindEntries
>>>>>>> [   OK ] CheckpointInFixture.FindEntries (0 ms)
>>>>>>> [ RUN  ] CheckpointInFixture.ExtractEntries
>>>>>>> [   OK ] CheckpointInFixture.ExtractEntries (0 ms)
>>>>>>> [ RUN  ] CheckpointInFixture.SCSCptInPathScoped
>>>>>>> [   OK ] CheckpointInFixture.SCSCptInPathScoped (0 ms)
>>>>>>> [--] 4 tests from CheckpointInFixture (1 ms total)
>>>>>>>
>>>>>>> [--] 6 tests from SerializableFixture
>>>>>>> [ RUN  ] Serializable

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

[Gabe Black via gem5-dev]

Ok, I reproduced the segfault once, but then running again in gdb it exited
normally. I'm pretty confident it's something to do with things getting
cleaned up and/or destructed at the end of the simulation, but until I
catch something in the act of exploding I won't be able to nail down
specifically what's doing it.

Gabe

On Tue, Nov 2, 2021 at 3:46 AM Gabe Black  wrote:

> A clean build seems to have fixed the IdeDisk problem.
>
> On Tue, Nov 2, 2021 at 3:35 AM Gabe Black  wrote:
>
>> Can you get a backtrace from it? Or run it in valgrind? I'm trying to use
>> the command line you provided locally, but it's complaining about not being
>> able to find IdeDisk which is very strange... I don't think I have an
>> account on the machine where this ran, but ideally I'll be able to
>> reproduce it locally where it will be easier to work with.
>>
>> Gabe
>>
>> On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power 
>> wrote:
>>
>>> After spending some time on this, there is definitely a segfault at the
>>> end of execution. It's odd that the testing scripts sometimes reports that
>>> it works.
>>>
>>> If you run the following, you should see a segfault at the end and no
>>> stats are generated:
>>> ../gem5/> build/ARM/gem5.opt tests/gem5/fs/linux/arm/run.py
>>> tests/gem5/configs/realview-o3.py tests/gem5/resources/arm .
>>>
>>> I also notice that when it doesn't fail the following is printed:
>>> "build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR
>>> build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR"
>>>
>>> But it's not printed when it fails.
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Mon, Nov 1, 2021 at 8:29 AM Jason Lowe-Power 
>>> wrote:
>>>
>>>> I don't think so. The binaries haven't been updated since April
>>>> ('aarch-system-20210904.tar.bz2'). Well, the blame says April even if the
>>>> filename is confusing (DDMM?).
>>>>
>>>> Here's the failure:
>>>> https://jenkins.gem5.org/job/nightly/ws/tests/testing-results/SuiteUID%3Arealview-o3-ARM-x86_64-opt/TestUID%3Arealview-o3-ARM-x86_64-opt/simerr
>>>>
>>>> build/ARM/arch/arm/insts/pseudo.cc:173: warn: instruction 'csdb'
>>>> unimplemented
>>>> build/ARM/arch/arm/generated/decoder-ns.cc.inc:100643: warn:
>>>> instruction 'mcr bpiall' unimplemented
>>>> gem5 has encountered a segmentation fault!
>>>>
>>>> Cheers,
>>>> Jason
>>>>
>>>> On Sat, Oct 30, 2021 at 4:11 AM Gabe Black via gem5-dev <
>>>> gem5-dev@gem5.org> wrote:
>>>>
>>>>> Maybe you need to re-download the resources?
>>>>>
>>>>> Gabe
>>>>>
>>>>> On Sat, Oct 30, 2021 at 3:50 AM jenkins-no-reply--- via gem5-dev <
>>>>> gem5-dev@gem5.org> wrote:
>>>>>
>>>>>> See <https://jenkins.gem5.org/job/nightly/27/display/redirect>
>>>>>>
>>>>>> Changes:
>>>>>>
>>>>>>
>>>>>> --
>>>>>> [...truncated 809.58 KB...]
>>>>>> [--] 4 tests from CheckpointInFixture
>>>>>> [ RUN  ] CheckpointInFixture.FindSections
>>>>>> [   OK ] CheckpointInFixture.FindSections (1 ms)
>>>>>> [ RUN  ] CheckpointInFixture.FindEntries
>>>>>> [   OK ] CheckpointInFixture.FindEntries (0 ms)
>>>>>> [ RUN  ] CheckpointInFixture.ExtractEntries
>>>>>> [   OK ] CheckpointInFixture.ExtractEntries (0 ms)
>>>>>> [ RUN  ] CheckpointInFixture.SCSCptInPathScoped
>>>>>> [   OK ] CheckpointInFixture.SCSCptInPathScoped (0 ms)
>>>>>> [--] 4 tests from CheckpointInFixture (1 ms total)
>>>>>>
>>>>>> [--] 6 tests from SerializableFixture
>>>>>> [ RUN  ] SerializableFixture.SCSChangeCptOutSingle
>>>>>> [   OK ] SerializableFixture.SCSChangeCptOutSingle (0 ms)
>>>>>> [ RUN  ] SerializableFixture.SCSChangeCptOutMultiple
>>>>>> [   OK ] SerializableFixture.SCSChangeCptOutMultiple (1 ms)
>>>>>> [ RUN  ] SerializableFixture.SCSChangeCptOutLarge
>>>>>> [   OK ] SerializableFixture.SCSChangeCptOutLarge (0 ms)
>>>>>> [ RUN  ] SerializableFixture

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

[Gabe Black via gem5-dev]

A clean build seems to have fixed the IdeDisk problem.

On Tue, Nov 2, 2021 at 3:35 AM Gabe Black  wrote:

> Can you get a backtrace from it? Or run it in valgrind? I'm trying to use
> the command line you provided locally, but it's complaining about not being
> able to find IdeDisk which is very strange... I don't think I have an
> account on the machine where this ran, but ideally I'll be able to
> reproduce it locally where it will be easier to work with.
>
> Gabe
>
> On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power 
> wrote:
>
>> After spending some time on this, there is definitely a segfault at the
>> end of execution. It's odd that the testing scripts sometimes reports that
>> it works.
>>
>> If you run the following, you should see a segfault at the end and no
>> stats are generated:
>> ../gem5/> build/ARM/gem5.opt tests/gem5/fs/linux/arm/run.py
>> tests/gem5/configs/realview-o3.py tests/gem5/resources/arm .
>>
>> I also notice that when it doesn't fail the following is printed:
>> "build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR
>> build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR"
>>
>> But it's not printed when it fails.
>>
>> Cheers,
>> Jason
>>
>> On Mon, Nov 1, 2021 at 8:29 AM Jason Lowe-Power 
>> wrote:
>>
>>> I don't think so. The binaries haven't been updated since April
>>> ('aarch-system-20210904.tar.bz2'). Well, the blame says April even if the
>>> filename is confusing (DDMM?).
>>>
>>> Here's the failure:
>>> https://jenkins.gem5.org/job/nightly/ws/tests/testing-results/SuiteUID%3Arealview-o3-ARM-x86_64-opt/TestUID%3Arealview-o3-ARM-x86_64-opt/simerr
>>>
>>> build/ARM/arch/arm/insts/pseudo.cc:173: warn: instruction 'csdb'
>>> unimplemented
>>> build/ARM/arch/arm/generated/decoder-ns.cc.inc:100643: warn: instruction
>>> 'mcr bpiall' unimplemented
>>> gem5 has encountered a segmentation fault!
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Sat, Oct 30, 2021 at 4:11 AM Gabe Black via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
>>>> Maybe you need to re-download the resources?
>>>>
>>>> Gabe
>>>>
>>>> On Sat, Oct 30, 2021 at 3:50 AM jenkins-no-reply--- via gem5-dev <
>>>> gem5-dev@gem5.org> wrote:
>>>>
>>>>> See <https://jenkins.gem5.org/job/nightly/27/display/redirect>
>>>>>
>>>>> Changes:
>>>>>
>>>>>
>>>>> --
>>>>> [...truncated 809.58 KB...]
>>>>> [--] 4 tests from CheckpointInFixture
>>>>> [ RUN  ] CheckpointInFixture.FindSections
>>>>> [   OK ] CheckpointInFixture.FindSections (1 ms)
>>>>> [ RUN  ] CheckpointInFixture.FindEntries
>>>>> [   OK ] CheckpointInFixture.FindEntries (0 ms)
>>>>> [ RUN  ] CheckpointInFixture.ExtractEntries
>>>>> [   OK ] CheckpointInFixture.ExtractEntries (0 ms)
>>>>> [ RUN  ] CheckpointInFixture.SCSCptInPathScoped
>>>>> [   OK ] CheckpointInFixture.SCSCptInPathScoped (0 ms)
>>>>> [--] 4 tests from CheckpointInFixture (1 ms total)
>>>>>
>>>>> [--] 6 tests from SerializableFixture
>>>>> [ RUN  ] SerializableFixture.SCSChangeCptOutSingle
>>>>> [   OK ] SerializableFixture.SCSChangeCptOutSingle (0 ms)
>>>>> [ RUN  ] SerializableFixture.SCSChangeCptOutMultiple
>>>>> [   OK ] SerializableFixture.SCSChangeCptOutMultiple (1 ms)
>>>>> [ RUN  ] SerializableFixture.SCSChangeCptOutLarge
>>>>> [   OK ] SerializableFixture.SCSChangeCptOutLarge (0 ms)
>>>>> [ RUN  ] SerializableFixture.SectionSerializationSimple
>>>>> [   OK ] SerializableFixture.SectionSerializationSimple (0 ms)
>>>>> [ RUN  ] SerializableFixture.ParamOutIn
>>>>> [   OK ] SerializableFixture.ParamOutIn (0 ms)
>>>>> [ RUN  ] SerializableFixture.ParamOutInMultipleSections
>>>>> [   OK ] SerializableFixture.ParamOutInMultipleSections (0 ms)
>>>>> [--] 6 tests from SerializableFixture (2 ms total)
>>>>>
>>>>> [--] Global test environment tear-down
>>>>> [==] 33 tests from 8 test suites ran. (171 ms total)
>>>>> [  PASSED  ] 33 t

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

[Gabe Black via gem5-dev]

Can you get a backtrace from it? Or run it in valgrind? I'm trying to use
the command line you provided locally, but it's complaining about not being
able to find IdeDisk which is very strange... I don't think I have an
account on the machine where this ran, but ideally I'll be able to
reproduce it locally where it will be easier to work with.

Gabe

On Mon, Nov 1, 2021 at 3:03 PM Jason Lowe-Power  wrote:

> After spending some time on this, there is definitely a segfault at the
> end of execution. It's odd that the testing scripts sometimes reports that
> it works.
>
> If you run the following, you should see a segfault at the end and no
> stats are generated:
> ../gem5/> build/ARM/gem5.opt tests/gem5/fs/linux/arm/run.py
> tests/gem5/configs/realview-o3.py tests/gem5/resources/arm .
>
> I also notice that when it doesn't fail the following is printed:
> "build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR
> build/ARM/arch/arm/isa.hh:650: warn: User mode does not have SPSR"
>
> But it's not printed when it fails.
>
> Cheers,
> Jason
>
> On Mon, Nov 1, 2021 at 8:29 AM Jason Lowe-Power 
> wrote:
>
>> I don't think so. The binaries haven't been updated since April
>> ('aarch-system-20210904.tar.bz2'). Well, the blame says April even if the
>> filename is confusing (DDMM?).
>>
>> Here's the failure:
>> https://jenkins.gem5.org/job/nightly/ws/tests/testing-results/SuiteUID%3Arealview-o3-ARM-x86_64-opt/TestUID%3Arealview-o3-ARM-x86_64-opt/simerr
>>
>> build/ARM/arch/arm/insts/pseudo.cc:173: warn: instruction 'csdb'
>> unimplemented
>> build/ARM/arch/arm/generated/decoder-ns.cc.inc:100643: warn: instruction
>> 'mcr bpiall' unimplemented
>> gem5 has encountered a segmentation fault!
>>
>> Cheers,
>> Jason
>>
>> On Sat, Oct 30, 2021 at 4:11 AM Gabe Black via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> Maybe you need to re-download the resources?
>>>
>>> Gabe
>>>
>>> On Sat, Oct 30, 2021 at 3:50 AM jenkins-no-reply--- via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
>>>> See <https://jenkins.gem5.org/job/nightly/27/display/redirect>
>>>>
>>>> Changes:
>>>>
>>>>
>>>> --
>>>> [...truncated 809.58 KB...]
>>>> [--] 4 tests from CheckpointInFixture
>>>> [ RUN  ] CheckpointInFixture.FindSections
>>>> [   OK ] CheckpointInFixture.FindSections (1 ms)
>>>> [ RUN  ] CheckpointInFixture.FindEntries
>>>> [   OK ] CheckpointInFixture.FindEntries (0 ms)
>>>> [ RUN  ] CheckpointInFixture.ExtractEntries
>>>> [   OK ] CheckpointInFixture.ExtractEntries (0 ms)
>>>> [ RUN  ] CheckpointInFixture.SCSCptInPathScoped
>>>> [   OK ] CheckpointInFixture.SCSCptInPathScoped (0 ms)
>>>> [--] 4 tests from CheckpointInFixture (1 ms total)
>>>>
>>>> [--] 6 tests from SerializableFixture
>>>> [ RUN  ] SerializableFixture.SCSChangeCptOutSingle
>>>> [   OK ] SerializableFixture.SCSChangeCptOutSingle (0 ms)
>>>> [ RUN  ] SerializableFixture.SCSChangeCptOutMultiple
>>>> [   OK ] SerializableFixture.SCSChangeCptOutMultiple (1 ms)
>>>> [ RUN  ] SerializableFixture.SCSChangeCptOutLarge
>>>> [   OK ] SerializableFixture.SCSChangeCptOutLarge (0 ms)
>>>> [ RUN  ] SerializableFixture.SectionSerializationSimple
>>>> [   OK ] SerializableFixture.SectionSerializationSimple (0 ms)
>>>> [ RUN  ] SerializableFixture.ParamOutIn
>>>> [   OK ] SerializableFixture.ParamOutIn (0 ms)
>>>> [ RUN  ] SerializableFixture.ParamOutInMultipleSections
>>>> [   OK ] SerializableFixture.ParamOutInMultipleSections (0 ms)
>>>> [--] 6 tests from SerializableFixture (2 ms total)
>>>>
>>>> [--] Global test environment tear-down
>>>> [==] 33 tests from 8 test suites ran. (171 ms total)
>>>> [  PASSED  ] 33 tests.
>>>>
>>>>   YOU HAVE 1 DISABLED TEST
>>>>
>>>> [   OK ] LoggingDeathTest.PanicLoggerExitHelper (149 ms)
>>>> [ RUN  ] LoggingDeathTest.ExitMessage
>>>> [   OK ] LoggingDeathTest.ExitMessage (152 ms)
>>>> [ RUN  ] LoggingDeathTest.Panic
>>>> [   OK ] LoggingDeathTest.Panic (151 ms)
>>>> [ RUN  ] LoggingDeathTest.Fatal
>>>> [   OK ] L

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

[Gabe Black via gem5-dev]

Maybe you need to re-download the resources?

Gabe

On Sat, Oct 30, 2021 at 3:50 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See 
>
> Changes:
>
>
> --
> [...truncated 809.58 KB...]
> [--] 4 tests from CheckpointInFixture
> [ RUN  ] CheckpointInFixture.FindSections
> [   OK ] CheckpointInFixture.FindSections (1 ms)
> [ RUN  ] CheckpointInFixture.FindEntries
> [   OK ] CheckpointInFixture.FindEntries (0 ms)
> [ RUN  ] CheckpointInFixture.ExtractEntries
> [   OK ] CheckpointInFixture.ExtractEntries (0 ms)
> [ RUN  ] CheckpointInFixture.SCSCptInPathScoped
> [   OK ] CheckpointInFixture.SCSCptInPathScoped (0 ms)
> [--] 4 tests from CheckpointInFixture (1 ms total)
>
> [--] 6 tests from SerializableFixture
> [ RUN  ] SerializableFixture.SCSChangeCptOutSingle
> [   OK ] SerializableFixture.SCSChangeCptOutSingle (0 ms)
> [ RUN  ] SerializableFixture.SCSChangeCptOutMultiple
> [   OK ] SerializableFixture.SCSChangeCptOutMultiple (1 ms)
> [ RUN  ] SerializableFixture.SCSChangeCptOutLarge
> [   OK ] SerializableFixture.SCSChangeCptOutLarge (0 ms)
> [ RUN  ] SerializableFixture.SectionSerializationSimple
> [   OK ] SerializableFixture.SectionSerializationSimple (0 ms)
> [ RUN  ] SerializableFixture.ParamOutIn
> [   OK ] SerializableFixture.ParamOutIn (0 ms)
> [ RUN  ] SerializableFixture.ParamOutInMultipleSections
> [   OK ] SerializableFixture.ParamOutInMultipleSections (0 ms)
> [--] 6 tests from SerializableFixture (2 ms total)
>
> [--] Global test environment tear-down
> [==] 33 tests from 8 test suites ran. (171 ms total)
> [  PASSED  ] 33 tests.
>
>   YOU HAVE 1 DISABLED TEST
>
> [   OK ] LoggingDeathTest.PanicLoggerExitHelper (149 ms)
> [ RUN  ] LoggingDeathTest.ExitMessage
> [   OK ] LoggingDeathTest.ExitMessage (152 ms)
> [ RUN  ] LoggingDeathTest.Panic
> [   OK ] LoggingDeathTest.Panic (151 ms)
> [ RUN  ] LoggingDeathTest.Fatal
> [   OK ] LoggingDeathTest.Fatal (2 ms)
> [ RUN  ] LoggingDeathTest.PanicIf
> [   OK ] LoggingDeathTest.PanicIf (150 ms)
> [ RUN  ] LoggingDeathTest.FatalIf
> [   OK ] LoggingDeathTest.FatalIf (3 ms)
> [ RUN  ] LoggingDeathTest.gem5Assert
> [  SKIPPED ] LoggingDeathTest.gem5Assert (0 ms)
> [--] 13 tests from LoggingDeathTest (1216 ms total)
>
> [--] 21 tests from LoggingFixture
> [ RUN  ] LoggingFixture.BasicPrint
> [   OK ] LoggingFixture.BasicPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicCharPrint
> [   OK ] LoggingFixture.VariadicCharPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicStringPrint
> [   OK ] LoggingFixture.VariadicStringPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicCharMissingPrint
> [   OK ] LoggingFixture.VariadicCharMissingPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicStringMissingPrint
> [   OK ] LoggingFixture.VariadicStringMissingPrint (0 ms)
> [ RUN  ] LoggingFixture.DisabledPrint
> [   OK ] LoggingFixture.DisabledPrint (0 ms)
> [ RUN  ] LoggingFixture.WarnLoggerPrint
> [   OK ] LoggingFixture.WarnLoggerPrint (0 ms)
> [ RUN  ] LoggingFixture.InfoLoggerPrint
> [   OK ] LoggingFixture.InfoLoggerPrint (0 ms)
> [ RUN  ] LoggingFixture.HackLoggerPrint
> [   OK ] LoggingFixture.HackLoggerPrint (0 ms)
> [ RUN  ] LoggingFixture.FatalLoggerPrint
> [   OK ] LoggingFixture.FatalLoggerPrint (0 ms)
> [ RUN  ] LoggingFixture.PanicLoggerPrint
> [   OK ] LoggingFixture.PanicLoggerPrint (0 ms)
> [ RUN  ] LoggingFixture.BaseMessage
> [   OK ] LoggingFixture.BaseMessage (0 ms)
> [ RUN  ] LoggingFixture.BaseMessageOnce
> [   OK ] LoggingFixture.BaseMessageOnce (0 ms)
> [ RUN  ] LoggingFixture.Warn
> [   OK ] LoggingFixture.Warn (0 ms)
> [ RUN  ] LoggingFixture.Inform
> [   OK ] LoggingFixture.Inform (0 ms)
> [ RUN  ] LoggingFixture.Hack
> [   OK ] LoggingFixture.Hack (0 ms)
> [ RUN  ] LoggingFixture.WarnOnce
> [   OK ] LoggingFixture.WarnOnce (0 ms)
> [ RUN  ] LoggingFixture.InformOnce
> [   OK ] LoggingFixture.InformOnce (0 ms)
> [ RUN  ] LoggingFixture.HackOnce
> [   OK ] LoggingFixture.HackOnce (0 ms)
> [ RUN  ] LoggingFixture.WarnIf
> [   OK ] LoggingFixture.WarnIf (0 ms)
> [ RUN  ] LoggingFixture.WarnIfOnce
> [   OK ] LoggingFixture.WarnIfOnce (0 ms)
> [--] 21 tests from LoggingFixture (0 ms total)
>
> [--] Global test environment tear-down
> [==] 34 tests from 2 test suites ran. (1216 ms total)
> [  PASSED  ] 32 tests.
> [  SKIPPED ] 2 tests, listed below:
> [  SKIPPED ] LoggingDeathTest.EmptyPrefix
> [  SKIPPED ] LoggingDeathTest.gem5Assert
> scons: done building targets.
> *** Summary of Warnings ***
> Warning: Deprecated namespaces are not supported by this compiler.
>

[gem5-dev] Re: Build failed in Jenkins: nightly #25

[Gabe Black via gem5-dev]

I just ran the long regressions on ToT, and everything passed for me:

$ docker run --volume ${PWD}:${PWD} -w ${PWD}/tests --rm
gcr.io/gem5-test/ubuntu-20.04_all-dependencies ./main.py run --length long
-j24 -t12

[...]
Test: realview-o3-ARM-x86_64-opt Passed
[...]

$ git log -n 1 --oneline
996f0ce168 (HEAD, origin/develop) dev: Separate generateDeviceTree into a
RiscvUart8250 SimObject.

On Fri, Oct 29, 2021 at 5:19 PM Gabe Black  wrote:

> Also, how do I run these (ideally just the failing test) locally?
>
> Gabe
>
> On Fri, Oct 29, 2021 at 5:17 PM Gabe Black  wrote:
>
>> Oh, I didn't see this until now. I'll take a look.
>>
>> Gabe
>>
>> On Fri, Oct 29, 2021 at 7:45 AM Jason Lowe-Power 
>> wrote:
>>
>>> Have you had a chance to look into this, Gabe?
>>>
>>> On Thu, Oct 28, 2021 at 7:35 AM Jason Lowe-Power 
>>> wrote:
>>>
 The realview ARM O3 test is failing. I would guess that it's not the
 translation changes as the timing simple CPU tests passed. I would guess
 it's the O3 rename change.
 https://gem5-review.googlesource.com/c/public/gem5/+/49147

 [gabe.black] arch-arm,cpu: Replace rename modes with split reg/elem
 register files.

 Gabe, can you run a quick bisect to find out?

 Thanks!
 Jason

 On Thu, Oct 28, 2021 at 4:08 AM jenkins-no-reply--- via gem5-dev <
 gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/25/display/redirect?page=changes>
>
> Changes:
>
> [gabe.black] cpu-o3: Don't update stats in (read|set)Arch*Reg methods.
>
> [giacomo.travaglini] arch-arm: Expose LookupLevel enum to the python
> world
>
> [giacomo.travaglini] arch-arm: Add walkBits method to PageTableOps
>
> [gabe.black] mem: Fix whitespace in mem/ruby/system/Sequencer.py.
>
> [gabe.black] arch: Simplify and tidy up PCState classes.
>
> [gabe.black] arch-arm,cpu: Replace rename modes with split reg/elem
> register files.
>
>
> --
> [...truncated 839.40 KB...]
> [ RUN  ] SerializableFixture.SectionSerializationSimple
> [   OK ] SerializableFixture.SectionSerializationSimple (0 ms)
> [ RUN  ] SerializableFixture.ParamOutIn
> [   OK ] SerializableFixture.ParamOutIn (1 ms)
> [ RUN  ] SerializableFixture.ParamOutInMultipleSections
> [   OK ] SerializableFixture.ParamOutInMultipleSections (0 ms)
> [--] 6 tests from SerializableFixture (2 ms total)
>
> [--] Global test environment tear-down
> [==] 33 tests from 8 test suites ran. (155 ms total)
> [  PASSED  ] 33 tests.
>
>   YOU HAVE 1 DISABLED TEST
>
> [   OK ] LoggingDeathTest.PanicLoggerExitHelper (181 ms)
> [ RUN  ] LoggingDeathTest.ExitMessage
> build/NULL/arch/arm/aapcs64.test.prof
> --gtest_output=xml:build/NULL/unittests.prof/arch/arm/aapcs64.test.xml
> Running main() from build/googletest/googletest/src/gtest_main.cc
> [==] Running 4 tests from 1 test suite.
> [--] Global test environment set-up.
> [--] 4 tests from Aapcs64
> [ RUN  ] Aapcs64.IsAapcs64ShortVector
> [   OK ] Aapcs64.IsAapcs64ShortVector (0 ms)
> [ RUN  ] Aapcs64.IsAapcs64Hfa
> [   OK ] Aapcs64.IsAapcs64Hfa (0 ms)
> [ RUN  ] Aapcs64.IsAapcs64Hva
> [   OK ] Aapcs64.IsAapcs64Hva (0 ms)
> [ RUN  ] Aapcs64.IsAapcs64Hxa
> [   OK ] Aapcs64.IsAapcs64Hxa (0 ms)
> [--] 4 tests from Aapcs64 (0 ms total)
>
> [--] Global test environment tear-down
> [==] 4 tests from 1 test suite ran. (0 ms total)
> [  PASSED  ] 4 tests.
> [   OK ] LoggingDeathTest.ExitMessage (155 ms)
> [ RUN  ] LoggingDeathTest.Panic
> [   OK ] LoggingDeathTest.Panic (149 ms)
> [ RUN  ] LoggingDeathTest.Fatal
> [   OK ] LoggingDeathTest.Fatal (3 ms)
> [ RUN  ] LoggingDeathTest.PanicIf
> [   OK ] LoggingDeathTest.PanicIf (153 ms)
> [ RUN  ] LoggingDeathTest.FatalIf
> [   OK ] LoggingDeathTest.FatalIf (2 ms)
> [ RUN  ] LoggingDeathTest.gem5Assert
> [  SKIPPED ] LoggingDeathTest.gem5Assert (0 ms)
> [--] 13 tests from LoggingDeathTest (1248 ms total)
>
> [--] 21 tests from LoggingFixture
> [ RUN  ] LoggingFixture.BasicPrint
> [   OK ] LoggingFixture.BasicPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicCharPrint
> [   OK ] LoggingFixture.VariadicCharPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicStringPrint
> [   OK ] LoggingFixture.VariadicStringPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicCharMissingPrint
> [   OK ] LoggingFixture.VariadicCharMissingPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicStringMissingPrint
> [   OK ] LoggingFixture.VariadicStringMissingPrint (0 ms)
> [ 

[gem5-dev] Re: Build failed in Jenkins: nightly #25

[Gabe Black via gem5-dev]

Also, how do I run these (ideally just the failing test) locally?

Gabe

On Fri, Oct 29, 2021 at 5:17 PM Gabe Black  wrote:

> Oh, I didn't see this until now. I'll take a look.
>
> Gabe
>
> On Fri, Oct 29, 2021 at 7:45 AM Jason Lowe-Power 
> wrote:
>
>> Have you had a chance to look into this, Gabe?
>>
>> On Thu, Oct 28, 2021 at 7:35 AM Jason Lowe-Power 
>> wrote:
>>
>>> The realview ARM O3 test is failing. I would guess that it's not the
>>> translation changes as the timing simple CPU tests passed. I would guess
>>> it's the O3 rename change.
>>> https://gem5-review.googlesource.com/c/public/gem5/+/49147
>>>
>>> [gabe.black] arch-arm,cpu: Replace rename modes with split reg/elem
>>> register files.
>>>
>>> Gabe, can you run a quick bisect to find out?
>>>
>>> Thanks!
>>> Jason
>>>
>>> On Thu, Oct 28, 2021 at 4:08 AM jenkins-no-reply--- via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
 See <
 https://jenkins.gem5.org/job/nightly/25/display/redirect?page=changes>

 Changes:

 [gabe.black] cpu-o3: Don't update stats in (read|set)Arch*Reg methods.

 [giacomo.travaglini] arch-arm: Expose LookupLevel enum to the python
 world

 [giacomo.travaglini] arch-arm: Add walkBits method to PageTableOps

 [gabe.black] mem: Fix whitespace in mem/ruby/system/Sequencer.py.

 [gabe.black] arch: Simplify and tidy up PCState classes.

 [gabe.black] arch-arm,cpu: Replace rename modes with split reg/elem
 register files.


 --
 [...truncated 839.40 KB...]
 [ RUN  ] SerializableFixture.SectionSerializationSimple
 [   OK ] SerializableFixture.SectionSerializationSimple (0 ms)
 [ RUN  ] SerializableFixture.ParamOutIn
 [   OK ] SerializableFixture.ParamOutIn (1 ms)
 [ RUN  ] SerializableFixture.ParamOutInMultipleSections
 [   OK ] SerializableFixture.ParamOutInMultipleSections (0 ms)
 [--] 6 tests from SerializableFixture (2 ms total)

 [--] Global test environment tear-down
 [==] 33 tests from 8 test suites ran. (155 ms total)
 [  PASSED  ] 33 tests.

   YOU HAVE 1 DISABLED TEST

 [   OK ] LoggingDeathTest.PanicLoggerExitHelper (181 ms)
 [ RUN  ] LoggingDeathTest.ExitMessage
 build/NULL/arch/arm/aapcs64.test.prof
 --gtest_output=xml:build/NULL/unittests.prof/arch/arm/aapcs64.test.xml
 Running main() from build/googletest/googletest/src/gtest_main.cc
 [==] Running 4 tests from 1 test suite.
 [--] Global test environment set-up.
 [--] 4 tests from Aapcs64
 [ RUN  ] Aapcs64.IsAapcs64ShortVector
 [   OK ] Aapcs64.IsAapcs64ShortVector (0 ms)
 [ RUN  ] Aapcs64.IsAapcs64Hfa
 [   OK ] Aapcs64.IsAapcs64Hfa (0 ms)
 [ RUN  ] Aapcs64.IsAapcs64Hva
 [   OK ] Aapcs64.IsAapcs64Hva (0 ms)
 [ RUN  ] Aapcs64.IsAapcs64Hxa
 [   OK ] Aapcs64.IsAapcs64Hxa (0 ms)
 [--] 4 tests from Aapcs64 (0 ms total)

 [--] Global test environment tear-down
 [==] 4 tests from 1 test suite ran. (0 ms total)
 [  PASSED  ] 4 tests.
 [   OK ] LoggingDeathTest.ExitMessage (155 ms)
 [ RUN  ] LoggingDeathTest.Panic
 [   OK ] LoggingDeathTest.Panic (149 ms)
 [ RUN  ] LoggingDeathTest.Fatal
 [   OK ] LoggingDeathTest.Fatal (3 ms)
 [ RUN  ] LoggingDeathTest.PanicIf
 [   OK ] LoggingDeathTest.PanicIf (153 ms)
 [ RUN  ] LoggingDeathTest.FatalIf
 [   OK ] LoggingDeathTest.FatalIf (2 ms)
 [ RUN  ] LoggingDeathTest.gem5Assert
 [  SKIPPED ] LoggingDeathTest.gem5Assert (0 ms)
 [--] 13 tests from LoggingDeathTest (1248 ms total)

 [--] 21 tests from LoggingFixture
 [ RUN  ] LoggingFixture.BasicPrint
 [   OK ] LoggingFixture.BasicPrint (0 ms)
 [ RUN  ] LoggingFixture.VariadicCharPrint
 [   OK ] LoggingFixture.VariadicCharPrint (0 ms)
 [ RUN  ] LoggingFixture.VariadicStringPrint
 [   OK ] LoggingFixture.VariadicStringPrint (0 ms)
 [ RUN  ] LoggingFixture.VariadicCharMissingPrint
 [   OK ] LoggingFixture.VariadicCharMissingPrint (0 ms)
 [ RUN  ] LoggingFixture.VariadicStringMissingPrint
 [   OK ] LoggingFixture.VariadicStringMissingPrint (0 ms)
 [ RUN  ] LoggingFixture.DisabledPrint
 [   OK ] LoggingFixture.DisabledPrint (0 ms)
 [ RUN  ] LoggingFixture.WarnLoggerPrint
 [   OK ] LoggingFixture.WarnLoggerPrint (0 ms)
 [ RUN  ] LoggingFixture.InfoLoggerPrint
 [   OK ] LoggingFixture.InfoLoggerPrint (0 ms)
 [ RUN  ] LoggingFixture.HackLoggerPrint
 [   OK ] LoggingFixture.HackLoggerPrint (0 ms)
 [ RUN  ] LoggingFixture.FatalLoggerPrint
 [   OK ] LoggingFixture.FatalLoggerPrint (0 ms)
 [ RUN  ] 

[gem5-dev] Re: Build failed in Jenkins: nightly #25

[Gabe Black via gem5-dev]

Oh, I didn't see this until now. I'll take a look.

Gabe

On Fri, Oct 29, 2021 at 7:45 AM Jason Lowe-Power 
wrote:

> Have you had a chance to look into this, Gabe?
>
> On Thu, Oct 28, 2021 at 7:35 AM Jason Lowe-Power 
> wrote:
>
>> The realview ARM O3 test is failing. I would guess that it's not the
>> translation changes as the timing simple CPU tests passed. I would guess
>> it's the O3 rename change.
>> https://gem5-review.googlesource.com/c/public/gem5/+/49147
>>
>> [gabe.black] arch-arm,cpu: Replace rename modes with split reg/elem
>> register files.
>>
>> Gabe, can you run a quick bisect to find out?
>>
>> Thanks!
>> Jason
>>
>> On Thu, Oct 28, 2021 at 4:08 AM jenkins-no-reply--- via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> See <
>>> https://jenkins.gem5.org/job/nightly/25/display/redirect?page=changes>
>>>
>>> Changes:
>>>
>>> [gabe.black] cpu-o3: Don't update stats in (read|set)Arch*Reg methods.
>>>
>>> [giacomo.travaglini] arch-arm: Expose LookupLevel enum to the python
>>> world
>>>
>>> [giacomo.travaglini] arch-arm: Add walkBits method to PageTableOps
>>>
>>> [gabe.black] mem: Fix whitespace in mem/ruby/system/Sequencer.py.
>>>
>>> [gabe.black] arch: Simplify and tidy up PCState classes.
>>>
>>> [gabe.black] arch-arm,cpu: Replace rename modes with split reg/elem
>>> register files.
>>>
>>>
>>> --
>>> [...truncated 839.40 KB...]
>>> [ RUN  ] SerializableFixture.SectionSerializationSimple
>>> [   OK ] SerializableFixture.SectionSerializationSimple (0 ms)
>>> [ RUN  ] SerializableFixture.ParamOutIn
>>> [   OK ] SerializableFixture.ParamOutIn (1 ms)
>>> [ RUN  ] SerializableFixture.ParamOutInMultipleSections
>>> [   OK ] SerializableFixture.ParamOutInMultipleSections (0 ms)
>>> [--] 6 tests from SerializableFixture (2 ms total)
>>>
>>> [--] Global test environment tear-down
>>> [==] 33 tests from 8 test suites ran. (155 ms total)
>>> [  PASSED  ] 33 tests.
>>>
>>>   YOU HAVE 1 DISABLED TEST
>>>
>>> [   OK ] LoggingDeathTest.PanicLoggerExitHelper (181 ms)
>>> [ RUN  ] LoggingDeathTest.ExitMessage
>>> build/NULL/arch/arm/aapcs64.test.prof
>>> --gtest_output=xml:build/NULL/unittests.prof/arch/arm/aapcs64.test.xml
>>> Running main() from build/googletest/googletest/src/gtest_main.cc
>>> [==] Running 4 tests from 1 test suite.
>>> [--] Global test environment set-up.
>>> [--] 4 tests from Aapcs64
>>> [ RUN  ] Aapcs64.IsAapcs64ShortVector
>>> [   OK ] Aapcs64.IsAapcs64ShortVector (0 ms)
>>> [ RUN  ] Aapcs64.IsAapcs64Hfa
>>> [   OK ] Aapcs64.IsAapcs64Hfa (0 ms)
>>> [ RUN  ] Aapcs64.IsAapcs64Hva
>>> [   OK ] Aapcs64.IsAapcs64Hva (0 ms)
>>> [ RUN  ] Aapcs64.IsAapcs64Hxa
>>> [   OK ] Aapcs64.IsAapcs64Hxa (0 ms)
>>> [--] 4 tests from Aapcs64 (0 ms total)
>>>
>>> [--] Global test environment tear-down
>>> [==] 4 tests from 1 test suite ran. (0 ms total)
>>> [  PASSED  ] 4 tests.
>>> [   OK ] LoggingDeathTest.ExitMessage (155 ms)
>>> [ RUN  ] LoggingDeathTest.Panic
>>> [   OK ] LoggingDeathTest.Panic (149 ms)
>>> [ RUN  ] LoggingDeathTest.Fatal
>>> [   OK ] LoggingDeathTest.Fatal (3 ms)
>>> [ RUN  ] LoggingDeathTest.PanicIf
>>> [   OK ] LoggingDeathTest.PanicIf (153 ms)
>>> [ RUN  ] LoggingDeathTest.FatalIf
>>> [   OK ] LoggingDeathTest.FatalIf (2 ms)
>>> [ RUN  ] LoggingDeathTest.gem5Assert
>>> [  SKIPPED ] LoggingDeathTest.gem5Assert (0 ms)
>>> [--] 13 tests from LoggingDeathTest (1248 ms total)
>>>
>>> [--] 21 tests from LoggingFixture
>>> [ RUN  ] LoggingFixture.BasicPrint
>>> [   OK ] LoggingFixture.BasicPrint (0 ms)
>>> [ RUN  ] LoggingFixture.VariadicCharPrint
>>> [   OK ] LoggingFixture.VariadicCharPrint (0 ms)
>>> [ RUN  ] LoggingFixture.VariadicStringPrint
>>> [   OK ] LoggingFixture.VariadicStringPrint (0 ms)
>>> [ RUN  ] LoggingFixture.VariadicCharMissingPrint
>>> [   OK ] LoggingFixture.VariadicCharMissingPrint (0 ms)
>>> [ RUN  ] LoggingFixture.VariadicStringMissingPrint
>>> [   OK ] LoggingFixture.VariadicStringMissingPrint (0 ms)
>>> [ RUN  ] LoggingFixture.DisabledPrint
>>> [   OK ] LoggingFixture.DisabledPrint (0 ms)
>>> [ RUN  ] LoggingFixture.WarnLoggerPrint
>>> [   OK ] LoggingFixture.WarnLoggerPrint (0 ms)
>>> [ RUN  ] LoggingFixture.InfoLoggerPrint
>>> [   OK ] LoggingFixture.InfoLoggerPrint (0 ms)
>>> [ RUN  ] LoggingFixture.HackLoggerPrint
>>> [   OK ] LoggingFixture.HackLoggerPrint (0 ms)
>>> [ RUN  ] LoggingFixture.FatalLoggerPrint
>>> [   OK ] LoggingFixture.FatalLoggerPrint (0 ms)
>>> [ RUN  ] LoggingFixture.PanicLoggerPrint
>>> [   OK ] LoggingFixture.PanicLoggerPrint (0 ms)
>>> [ RUN  ] LoggingFixture.BaseMessage
>>> [   OK ] LoggingFixture.BaseMessage (1 ms)
>>> [ RUN  ] LoggingFixture.BaseMessageOnce
>>> [   OK ] 

[gem5-dev] Re: CPU complex wrapper

[Gabe Black via gem5-dev]

Well, I definitely don't think the generic scripts like se.py and fs.py are
something to preserve, but unless we're prepared to break them and throw
them out, then we have to figure out some way to maintain compatibility.
I'm trying to figure out a way to keep things compatible at least for now,
but get rid of the "if x86 do this, if arm do that" constructs that are
tucked into little corners around gem5, particularly in the CPUs.

I also agree that this really shouldn't be tied to the SimObjects. I would
like to see the SimObjects as bare as possible, and put all this helper
functionality somewhere else. Removing it outright would again break
compatibility, which I'm trying to avoid at least for now. These wrappers
would *not* be new SimObjects in the sense that they would not have C++
representations, they would just be grease to help the python code work in
a more generic way which would disappear when things were really
instantiated.

Again, I don't think these super generic mechanisms are something we should
strive to maintain or support in the long term, I'm just trying to figure
out a way to not break the world while I get rid of TARGET_ISA and the
single ISA assumptions in gem5.

Gabe

On Thu, Oct 28, 2021 at 7:45 AM Jason Lowe-Power 
wrote:

> Hi Gabe,
>
> This is one of the main use cases for the components in the component
> library. The idea behind the component library is to have the SimObjects be
> *models* which only have parameters and no instantiated objects. Then, the
> *components* would tie together specific instances of SimObjects into
> larger systems. For CPUs, we have a few examples so far, and they are
> working with x86 and RISC-V in SE and FS mode with classic and Ruby caches.
> We haven't tested Arm full system, yet, but it's our intention that the
> component library support this. I would encourage you to take a look at the
> AbstractProcessor and AbstractCore classes.
>
> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/python/gem5/components/processors/abstract_core.py
>
>
> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/python/gem5/components/processors/abstract_processor.py
>
> To support things like core complexes which contain multiple cores and
> caches, this interface won't work. My opinion is that these more complex
> cases are impossible to create a generalized interface for, and we will
> have to provide our users with "prebuilt systems" which implement these
> kinds of architectures with tightly coupled caches and processors.
>
> IMO, this kind of complexity should not be in the SimObject itself, but
> separated out into the component definition. I would prefer to not add more
> complexity to the parameters and to the SimObject description files.
> However, if you want to take this a different direction, we would
> appreciate it to be fully compatible with the component library and require
> the minimum changes to the (hopefully soon to be deprecated) se/fs.py
> config scripts.
>
> Cheers,
> Jason
>
> On Wed, Oct 27, 2021 at 9:40 PM Gabe Black via gem5-dev 
> wrote:
>
>> Hi folks. There are some helper functions in BaseCPU which help set up
>> ancillary structures like caches, and tries to keep track of the frontier
>> of ports that need to be connected so that a CPU + caches can be
>> generically hooked into a system.
>>
>> This code is a bit clunky and complex, and makes it more difficult to
>> delay setting up ISA specific components like MMUs and interrupt
>> controllers which may need to connect to the memory system as well.
>>
>> I'm thinking that one way to clean this up could be to make a wrapper
>> which represents the CPU complex as a whole, which can be nested to add new
>> layers and which would provide a consistent interface no matter how much
>> extra stuff got layered on.
>>
>> Importantly, these layers would be set up so that their ports were just a
>> layer of indirection, and they would not represent extra levels of stuff to
>> traverse in c++. I think systemc has a concept *roughly* analogous to this
>> called exports (ex-ports, as opposed to ports? get it?) which let you poke
>> ports from internal components out of the external interface.
>>
>> I'm thinking these port repeaters, or port proxies (overloaded term) or
>> exports, or whatever they're called could be added to the existing
>> SubSystem container to make a more generic and useful config level wrapper.
>>
>> class CpuComplex(SubSystem):
>> inst_ports = VectorPortProxy
>> data_ports = VectorPortProxy
>> uncached_ports = VectorPortProxy
>>
>> class AtomicSimpleCpuComplex(CpuComplex):
>> cpu = AtomicSimpleCPU
>>

[gem5-dev] CPU complex wrapper

[Gabe Black via gem5-dev]

Hi folks. There are some helper functions in BaseCPU which help set up
ancillary structures like caches, and tries to keep track of the frontier
of ports that need to be connected so that a CPU + caches can be
generically hooked into a system.

This code is a bit clunky and complex, and makes it more difficult to delay
setting up ISA specific components like MMUs and interrupt controllers
which may need to connect to the memory system as well.

I'm thinking that one way to clean this up could be to make a wrapper which
represents the CPU complex as a whole, which can be nested to add new
layers and which would provide a consistent interface no matter how much
extra stuff got layered on.

Importantly, these layers would be set up so that their ports were just a
layer of indirection, and they would not represent extra levels of stuff to
traverse in c++. I think systemc has a concept *roughly* analogous to this
called exports (ex-ports, as opposed to ports? get it?) which let you poke
ports from internal components out of the external interface.

I'm thinking these port repeaters, or port proxies (overloaded term) or
exports, or whatever they're called could be added to the existing
SubSystem container to make a more generic and useful config level wrapper.

class CpuComplex(SubSystem):
inst_ports = VectorPortProxy
data_ports = VectorPortProxy
uncached_ports = VectorPortProxy

class AtomicSimpleCpuComplex(CpuComplex):
cpu = AtomicSimpleCPU
inst_ports = cpu.icache_port
data_ports = cpu.dcache_port

class WithCaches(CpuComplex):
cpu = AtomicSimpleCpuComplex
inst_ports = cpu.inst_ports
data_ports = cpu.data_ports
uncached_ports = cpu.uncached_ports


Something similar to this could generically hold the interrupts object,
etc, which may or may not have certain ports connected, and then if a proxy
has nothing on the other side of it, it could just not actually connect?

There would be some python/config/SimObject/param hacking necessary to make
this work, but I think it would generalize these different sorts of
connections and make this easier to work with.

Ideally in the long run we might not want to have these scripts which
generically support x86, arm, etc, etc, but unless we're prepared to break
all those scripts, we're going to need to keep that working somehow.

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Presentation about multi ISA gem5

[Gabe Black via gem5-dev]

Hi folks. I wrote a presentation about my work to make gem5 able to support
more than one ISA at a time. It's *slightly* out of date now, since more
work has been finished since it was last updated. The structure of it
seemed like a good idea initially, but I think it may have made the
presentation a little more repetitive than would be ideal. Please take a
look if you're curious, or if you want more insight into what I'm doing and
how.

https://docs.google.com/presentation/d/1PmyLLBYO1wjpGE6vVLeADsw_JWgN8uB967pp-dthZmw/edit?usp=sharing

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: nightly #17

[Gabe Black via gem5-dev]

I think this is from my change which switched from "if env['TARGET_ISA'] ==
'foo'" to using tags. I saw this a while ago, but I've been up literally
all night trying to fix problem after problem rebasing my changes on top of
ToT, and I haven't had a chance to look at it yet. When I finally get some
sleep, I'm going to have to finish a presentation I have to give
tomorrow/today, and so may not have a chance to look at it until later in
the day.

Probably that unit test just needs an 'arm isa' tag so that it doesn't get
pulled into NULL, the black sheep of the ISAs.

Gabe

On Wed, Oct 20, 2021 at 7:44 AM Jason Lowe-Power 
wrote:

> Hey Gabe,
>
> It looks like either the debug flag changes or the changes to scons caused
> the build error.
>
> *00:53:31*  [ CXX] NULL/arch/arm/aapcs64.test.cc -> .to*00:53:31* In file 
> included from build/NULL/cpu/static_inst.hh:54,*00:53:32*  
> from build/NULL/arch/arm/utility.hh:52,*00:53:32*  from 
> build/NULL/arch/arm/aapcs64.hh:37,*00:53:32*  from 
> build/NULL/arch/arm/aapcs64.test.cc:30:*00:53:32* 
> build/NULL/cpu/op_class.hh:44:10: fatal error: enums/OpClass.hh: No such file 
> or directory
>
>
> On Wed, Oct 20, 2021 at 12:53 AM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> See <
>> https://jenkins.gem5.org/job/nightly/17/display/redirect?page=changes>
>>
>> Changes:
>>
>> [giacomo.travaglini] sim-se: Implement mkdirat syscall
>>
>> [giacomo.travaglini] arch-arm: Add mkdirat implementation to the Syscall
>> Table
>>
>> [giacomo.travaglini] arch-arm: Add mknod implementation to the Syscall
>> Table
>>
>> [gabe.black] scons: Use unions to prevent debug flag destruction.
>>
>> [gabe.black] scons: Make debug flags respect tags.
>>
>> [gabe.black] arch: Consolidate common debug flags.
>>
>> [Bobby R. Bruce] configs,tests: Add "Hello world" example for the gem5
>> library
>>
>> [Bobby R. Bruce] configs,tests: Add Ubuntu boot example for the gem5
>> library
>>
>> [gabe.black] configs,dev: Rename the riscv version of VirtIOMMIO with a
>> Riscv prefix.
>>
>> [gabe.black] scons: Use tags to gate ISA files and not env['TARGET_ISA'].
>>
>> [mattdsinclair] tests: add HACC to weekly regression
>>
>>
>> --
>> [...truncated 645.00 KB...]
>> [ RUN  ] AddrRangeTest.LegacyConstructorTwoBitMaskWithXOR
>> [   OK ] AddrRangeTest.LegacyConstructorTwoBitMaskWithXOR (1 ms)
>> [ RUN  ] AddrRangeTest.RangeExConstruction
>> [   OK ] AddrRangeTest.RangeExConstruction (0 ms)
>> [ RUN  ] AddrRangeTest.RangeInConstruction
>> [   OK ] AddrRangeTest.RangeInConstruction (0 ms)
>> [ RUN  ] AddrRangeTest.RangeSizeConstruction
>> [   OK ] AddrRangeTest.RangeSizeConstruction (0 ms)
>> [ RUN  ] AddrRangeTest.ExcludeAll
>> [   OK ] AddrRangeTest.ExcludeAll (0 ms)
>> [ RUN  ] AddrRangeTest.ExcludeAllEqual
>> [   OK ] AddrRangeTest.ExcludeAllEqual (0 ms)
>> [ RUN  ] AddrRangeTest.ExcludeAllMultiple
>> [   OK ] AddrRangeTest.ExcludeAllMultiple (0 ms)
>> [ RUN  ] AddrRangeTest.ExcludeAllOverlapping
>> [   OK ] AddrRangeTest.ExcludeAllOverlapping (0 ms)
>> [ RUN  ] AddrRangeTest.ExcludeEmpty
>> [   OK ] AddrRangeTest.ExcludeEmpty (0 ms)
>> [ RUN  ] AddrRangeTest.NoExclusion
>> [   OK ] AddrRangeTest.NoExclusion (0 ms)
>> [ RUN  ] AddrRangeTest.DoubleExclusion
>> [   OK ] AddrRangeTest.DoubleExclusion (0 ms)
>> [ RUN  ] AddrRangeTest.MultipleExclusion
>> [   OK ] AddrRangeTest.MultipleExclusion (0 ms)
>> [ RUN  ] AddrRangeTest.MultipleExclusionOverlapping
>> [   OK ] AddrRangeTest.MultipleExclusionOverlapping (0 ms)
>> [ RUN  ] AddrRangeTest.ExclusionOverlapping
>> [   OK ] AddrRangeTest.ExclusionOverlapping (0 ms)
>> [ RUN  ] AddrRangeTest.MultipleExclusionUnsorted
>> [   OK ] AddrRangeTest.MultipleExclusionUnsorted (0 ms)
>> [ RUN  ] AddrRangeTest.ExclusionOfSingleRange
>> [   OK ] AddrRangeTest.ExclusionOfSingleRange (0 ms)
>> [ RUN  ] AddrRangeTest.ExclusionOfRangeFromRangeList
>> [   OK ] AddrRangeTest.ExclusionOfRangeFromRangeList (0 ms)
>> [ RUN  ] AddrRangeTest.ExclusionOfRangeListFromRangeList
>> [   OK ] AddrRangeTest.ExclusionOfRangeListFromRangeList (0 ms)
>> [ RUN  ] AddrRangeTest.SubtractionOperatorRange
>> [   OK ] AddrRangeTest.SubtractionOperatorRange (0 ms)
>> [ RUN  ] AddrRangeTest.SubtractionOperatorRangeList
>> [   OK ] AddrRangeTest.SubtractionOperatorRangeList (0 ms)
>> [ RUN  ] AddrRangeTest.SubtractionOfRangeFromRangeList
>> [   OK ] AddrRangeTest.SubtractionOfRangeFromRangeList (0 ms)
>> [ RUN  ] AddrRangeTest.SubtractionOfRangeListFromRangeList
>> [   OK ] AddrRangeTest.SubtractionOfRangeListFromRangeList (0 ms)
>> [ RUN  ] AddrRangeTest.SubtractionAssignmentOfRangeFromRangeList
>> [   OK ] AddrRangeTest.SubtractionAssignmentOfRangeFromRangeList (0
>> ms)
>> [ RUN  ] 

[gem5-dev] Re: gem5 gui tool?

[Gabe Black via gem5-dev]

Yeah, I saw that branch, but the commits at the end of it didn't look like
they were related to the gui, and browsing around in it in gerrit I
couldn't find any files related to it. Do you know what/where the files are
on that branch?

Gabe

On Tue, Oct 19, 2021 at 9:57 AM Bobby Bruce  wrote:

> Hey Gabe,
>
> The gem5 GUI code is still around, it's on a separate branch in the repo,
> `feature-gui`: `git clone -b feature-gui
> https://gem5.googlesource.com/public/gem5`
> <https://gem5.googlesource.com/public/gem5>.
>
> We at UC Davis tried to get some students to continue working on this, but
> we were never able to. Hopefully we can get someone to jump in and clean it
> up at some point.
>
> Anyway, that's where the code lives if you want to look at it.
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Mon, Oct 18, 2021 at 10:47 PM Gabe Black via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> If you want to try my script, or even improve it (probably not hard!),
>> it's attached.
>>
>> You can run it by first collecting a log of timestamps, which I did with
>> a clean build:
>>
>> scons --debug=action-timestamps -j48 build/ARM/gem5.opt | tee log.txt
>>
>> and then run the script:
>>
>> ./scons_timeline.py log.txt
>>
>> I would be curious how that looks on our big compile test machine!
>>
>> Gabe
>>
>> On Mon, Oct 18, 2021 at 10:20 PM Gabe Black  wrote:
>>
>>> Wow, now I remember why I don't like GUI programming :-/
>>>
>>> Well, I sort of got some results, and the upshot is that linking gem5
>>> takes a long time :-P. And I am able to at least superficially have 48
>>> things going during the build, although it is not necessarily 48 times
>>> faster than doing things one at a time.
>>>
>>> Gabe
>>>
>>> On Mon, Oct 18, 2021 at 5:45 PM Gabe Black  wrote:
>>>
>>>> Hey folks, a while ago some students developed a GUI tool for gem5.
>>>> While I think that was great and really hasn't gotten the attention (or
>>>> adoption?) that a tool like that should, I was looking for it for a more
>>>> practical reason but haven't been able to find it.
>>>>
>>>> Does anybody know where it ended up? And additionally/alternatively,
>>>> does anybody know what guil toolkit that used? I want to write up a quick
>>>> SCons build performance visualizer and (assuming it goes into util?) I
>>>> wouldn't want to add a second gui toolkit dependency.
>>>>
>>>> Thanks!
>>>> Gabe
>>>>
>>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: gem5 gui tool?

[Gabe Black via gem5-dev]

If you want to try my script, or even improve it (probably not hard!), it's
attached.

You can run it by first collecting a log of timestamps, which I did with a
clean build:

scons --debug=action-timestamps -j48 build/ARM/gem5.opt | tee log.txt

and then run the script:

./scons_timeline.py log.txt

I would be curious how that looks on our big compile test machine!

Gabe

On Mon, Oct 18, 2021 at 10:20 PM Gabe Black  wrote:

> Wow, now I remember why I don't like GUI programming :-/
>
> Well, I sort of got some results, and the upshot is that linking gem5
> takes a long time :-P. And I am able to at least superficially have 48
> things going during the build, although it is not necessarily 48 times
> faster than doing things one at a time.
>
> Gabe
>
> On Mon, Oct 18, 2021 at 5:45 PM Gabe Black  wrote:
>
>> Hey folks, a while ago some students developed a GUI tool for gem5. While
>> I think that was great and really hasn't gotten the attention (or
>> adoption?) that a tool like that should, I was looking for it for a more
>> practical reason but haven't been able to find it.
>>
>> Does anybody know where it ended up? And additionally/alternatively, does
>> anybody know what guil toolkit that used? I want to write up a quick SCons
>> build performance visualizer and (assuming it goes into util?) I wouldn't
>> want to add a second gui toolkit dependency.
>>
>> Thanks!
>> Gabe
>>
>
#! /usr/bin/env python3
#
# Copyright 2021 Google, Inc.
#
# 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.

import argparse
import collections
import re
import wx
import wx.lib.plot

parser = argparse.ArgumentParser(
description='Visualize SCons action timestamps')
parser.add_argument('log_file',
help="file with SCon's log output when run with --debug-action-timestamps")

args = parser.parse_args()

class Bound:
def __init__(self, target, name, value):
self.target = target
self.is_start = (name == 'start')
self.value = float(value)

class Target:
def __init__(self):
self.name = None
self._start = None
self._end = None

@property
def start(self):
assert(self._start is not None)
return self._start

@property
def end(self):
assert(self._end is not None)
return self._end

@start.setter
def start(self, bound):
assert(self._start is None)
self._start = bound

@end.setter
def end(self, bound):
assert(self._end is None)
self._end = bound

targets = collections.defaultdict(Target)

timestamp_re = re.compile(r'Command execution (?Pstart|end) '
  r'timestamp: (?P[^:]*): '
  r'(?P[\d\.]*)')

skipped = 0
with open(args.log_file) as log:
lines = log.readlines()
for line in lines:
match = timestamp_re.match(line)
if not match:
skipped = skipped + 1
continue
name = match.group('name')
target = targets[name]
target.name = name
bound = Bound(target, match.group('ttype'), match.group('seconds'))
if bound.is_start:
target.start = bound
else:
target.end = bound

# Find the bounds for the times for all the targets.

min_start = min(target.start.value for target in targets.values())
max_end = max(target.end.value for target in targets.values())

bounds = []
for target in targets.values():
bounds.extend([target.start, target.end])

bounds = sorted(bounds, key=lambda b: b.value)

class Timeline(wx.Frame):
def __init__(self):

[gem5-dev] Re: gem5 gui tool?

[Gabe Black via gem5-dev]

Wow, now I remember why I don't like GUI programming :-/

Well, I sort of got some results, and the upshot is that linking gem5 takes
a long time :-P. And I am able to at least superficially have 48 things
going during the build, although it is not necessarily 48 times faster than
doing things one at a time.

Gabe

On Mon, Oct 18, 2021 at 5:45 PM Gabe Black  wrote:

> Hey folks, a while ago some students developed a GUI tool for gem5. While
> I think that was great and really hasn't gotten the attention (or
> adoption?) that a tool like that should, I was looking for it for a more
> practical reason but haven't been able to find it.
>
> Does anybody know where it ended up? And additionally/alternatively, does
> anybody know what guil toolkit that used? I want to write up a quick SCons
> build performance visualizer and (assuming it goes into util?) I wouldn't
> want to add a second gui toolkit dependency.
>
> Thanks!
> Gabe
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] gem5 gui tool?

[Gabe Black via gem5-dev]

Hey folks, a while ago some students developed a GUI tool for gem5. While I
think that was great and really hasn't gotten the attention (or adoption?)
that a tool like that should, I was looking for it for a more practical
reason but haven't been able to find it.

Does anybody know where it ended up? And additionally/alternatively, does
anybody know what guil toolkit that used? I want to write up a quick SCons
build performance visualizer and (assuming it goes into util?) I wouldn't
want to add a second gui toolkit dependency.

Thanks!
Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #9

[Gabe Black via gem5-dev]

Yep, I'll take a look.

Gabe

On Thu, Oct 14, 2021 at 12:41 PM Bobby Bruce  wrote:

> Hey Gabe,
>
> It seems like both the Nightly and Compiler tests are failing because
> SPARC no longer compilers. This appears to be due to this change:
> https://gem5-review.googlesource.com/c/public/gem5/+/48717. It looks like
> you changed "checkFpEnableFault" to "checkFpEnabled" and didn't update this
> everywhere in the codebase. Could you fix this?
>
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Thu, Oct 14, 2021 at 1:17 AM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> See <
>> https://jenkins.gem5.org/job/compiler-checks/9/display/redirect?page=changes
>> >
>>
>> Changes:
>>
>> [giacomo.travaglini] arch-arm: Add sendto and recvfrom implementations to
>> the Syscall Table
>>
>> [giacomo.travaglini] arch-arm: Add ftruncate implementation to the
>> Syscall Table
>>
>> [giacomo.travaglini] misc: Using OS::size_t in syscall signature
>>
>> [giacomo.travaglini] misc: Using OS::off_t in syscall signature
>>
>> [gabe.black] arch,sparc: Get rid of the unused checkVecEnableFault
>> mechanism.
>>
>> [gabe.black] sparc: Stop special casing FP enable checks for full system.
>>
>> [gabe.black] sparc: Stop using fp_enable_check.
>>
>> [giacomo.travaglini] mem: Make ruby AbstractController compatible with
>> XBar
>>
>> [gabe.black] scons: Add tag support to GdbXml.
>>
>> [gabe.black] scons: Add tag support to ISADesc.
>>
>> [gabe.black] scons,arch: Make the gem5 lib tag imply the current arch tag.
>>
>> [gabe.black] scons: Make the SimObject list from the 'gem5 lib' tag.
>>
>> [gabe.black] cpu: Stop excluding the protobuf tracer for x86.
>>
>> [gabe.black] mem: Stop using SlavePort as a base class.
>>
>> [gabe.black] base,arch-arm: Replace Stats namespace with statistics.
>>
>> [gabe.black] arch-power: Replace the Loader namespace with loader.
>>
>> [mattdsinclair] tests: fix LULESH weekly regression command
>>
>> [mattdsinclair] tests: add additional space in weekly DNNMark tests
>>
>> [msamani] cpu: Adding GUPSGen ClockedObject.
>>
>> [Bobby R. Bruce] tests: Fix the nightly GPU tests
>>
>> [gabe.black] mem: Replace SatCounter with SatCounter8 in the SHiP
>> replacement policy.
>>
>> [mattdsinclair] tests: convert all nightly GPU tests from GUID to GID
>>
>> [gabe.black] scons: Don't explicitly list include dependencies for the
>> cxx config.
>>
>>
>> --
>> Started by timer
>> Running as SYSTEM
>> Building in workspace 
>> The recommended git tool is: NONE
>> No credentials specified
>>  > git rev-parse --resolve-git-dir <
>> https://jenkins.gem5.org/job/compiler-checks/ws/.git> # timeout=10
>> Fetching changes from the remote Git repository
>>  > git config remote.origin.url https://gem5.googlesource.com/public/gem5
>> # timeout=10
>> Fetching upstream changes from https://gem5.googlesource.com/public/gem5
>>  > git --version # timeout=10
>>  > git --version # 'git version 2.25.1'
>>  > git fetch --tags --force --progress --
>> https://gem5.googlesource.com/public/gem5
>> +refs/heads/*:refs/remotes/origin/* # timeout=10
>>  > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
>> Checking out Revision bad6fa679d8d6e22872b69e6008c0d14474e8d13
>> (refs/remotes/origin/develop)
>>  > git config core.sparsecheckout # timeout=10
>>  > git checkout -f bad6fa679d8d6e22872b69e6008c0d14474e8d13 # timeout=10
>> Commit message: "scons: Don't explicitly list include dependencies for
>> the cxx config."
>>  > git rev-list --no-walk 058e4699d8bf4ae78b94de245e3cefe72e7bc702 #
>> timeout=10
>> [compiler-checks] $ /bin/sh -xe /tmp/jenkins17961737912055094198.sh
>> + ./tests/compiler-tests.sh -j 24
>> Starting build tests with 'gcc-version-11'...
>> 'gcc-version-11' was found in the comprehensive tests. All ISAs will be
>> built.
>>   * Building target 'POWER.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'POWER.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 'Garnet_standalone.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'Garnet_standalone.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 'NULL_MOESI_hammer.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'NULL_MOESI_hammer.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 'GCN3_X86.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'GCN3_X86.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 'X86.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'X86.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 'SPARC.opt' with 'gcc-version-11'...
>>   ! Failed with exit code 2.
>>   * Building target 'SPARC.fast' with 'gcc-version-11'...
>>   ! Failed with exit code 2.
>>   * Building target 

[gem5-dev] Re: reduce the number of checkpoints in the ARM checkpoint test?

[Gabe Black via gem5-dev]

Hi Giacomo. it's definitely minutes, probably between 5 and 10 per
checkpoint.

Another thing I noticed is that often, the test infrastructure will
schedule the typically two final and longer running tests (I think both ARM
boot tests) at the same time, but sometimes I'll wait and wait for the
checkpoint one to run, and then it will start the other ARM test serially
after it, even though I passed in -t 6 (run 6 tests in parallel). It's just
a guess, but is the framework setting up 6 static schedules of tests and
then feeding them to 6 threads to run? Or is it dynamically scheduling them
based on when different threads finish their current task? If it's the
first, I think the second would be a great improvement as well, since that
will save the occasional unnecessary serialization of long running tests.

Gabe

On Tue, Oct 12, 2021 at 2:10 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:

> Hi Gabe, are we talking about seconds or minutes (per run)?
> In the latter case I agree we could reduce the max_number to 3.
>
> If it is just saving us few seconds then it is probably not worth it IMHO
>
> Kind Regards
>
> Giacomo
>
> > -----Original Message-
> > From: Gabe Black via gem5-dev 
> > Sent: 12 October 2021 09:18
> > To: gem5 Developer List 
> > Cc: Gabe Black 
> > Subject: [gem5-dev] reduce the number of checkpoints in the ARM
> > checkpoint test?
> >
> > I notice that the long pole in running the quick regressions seems to be
> the
> > tests/gem5/configs/realview64-simple-atomic-checkpoint.py test which
> > does some sort of ARM linux boot (I assume) and checkpoints 5 times as it
> > comes up. Would it make sense to reduce that down to 3 or even 2? I think
> > that would get largely the same test coverage but hopefully take
> > substantially less time to run.
> >
> > Alternatively we could increase the interval and decrease the max number
> of
> > checkpoints to get more separate (and more different?) state for
> > checkpoints.
> >
> > Longer term, we should look at why taking (and restoring?) checkpoints
> is so
> > slow and try to fix that, but nearer term, when I have to run lots of
> these in a
> > row, it would be really nice to trim them down by a good number of
> minutes
> > a time.
> >
> > Gabe
> 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
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] reduce the number of checkpoints in the ARM checkpoint test?

[Gabe Black via gem5-dev]

I notice that the long pole in running the quick regressions seems to be
the tests/gem5/configs/realview64-simple-atomic-checkpoint.py test which
does some sort of ARM linux boot (I assume) and checkpoints 5 times as it
comes up. Would it make sense to reduce that down to 3 or even 2? I think
that would get largely the same test coverage but hopefully take
substantially less time to run.

Alternatively we could increase the interval and decrease the max number of
checkpoints to get more separate (and more different?) state for
checkpoints.

Longer term, we should look at why taking (and restoring?) checkpoints is
so slow and try to fix that, but nearer term, when I have to run lots of
these in a row, it would be really nice to trim them down by a good number
of minutes a time.

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: replacement for x86-boot-tests/run_exit.py?

[Gabe Black via gem5-dev]

That works. Thanks!

Gabe

On Fri, Oct 1, 2021 at 2:16 PM Bobby Bruce via gem5-dev 
wrote:

> Hey Gabe:
>
> Try `tests/gem5/configs/x86_boot_exit_run.py`:
> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/tests/gem5/configs/x86_boot_exit_run.py.
>
>
> It should function similarly to the old `run_exit.py` but you don't need
> to specify the disk and the kernel.
>
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Thu, Sep 30, 2021 at 6:15 PM Gabe Black via gem5-dev 
> wrote:
>
>> Hi folks, particularly Bobby. I was using the x86-boot-tests/run_exit.py
>> configuration to run a fairly quick and easy x86 boot to measure gem5
>> performance, but that script seems to have gone away in the last week or
>> two.
>>
>> What is the replacement for it? I need something I can use to do a
>> reasonably representative task in gem5 which I can time to measure
>> simulator performance. I used to be able to do that with this command:
>>
>> time ./build/X86/gem5.opt ./tests/gem5/x86-boot-tests/run_exit.py
>> --kernel ../boot-test/vmlinux-4.19.83 --disk ../boot-test/base.img
>> --cpu-type atomic --num-cpus 1 --boot-type init
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] flakey kokoro failures

[Gabe Black via gem5-dev]

Hi folks, just FYI, I've seen a bunch of kokoro failures recently where
there has been only a single line in the log,

[00:05:11][ERROR] Config validation failed!

https://gem5-review.googlesource.com/c/public/gem5/+/49751

https://source.cloud.google.com/results/invocations/ef418ce8-bf20-48bb-8480-378a89d4df20/targets/gem5%2Fgcp_ubuntu%2Fpresubmit/log

I'm pretty sure this is a problem with kokoro itself (or some internal
service it depends on), and have contacted the kokoro team to help sort
this out.

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] replacement for x86-boot-tests/run_exit.py?

[Gabe Black via gem5-dev]

Hi folks, particularly Bobby. I was using the x86-boot-tests/run_exit.py
configuration to run a fairly quick and easy x86 boot to measure gem5
performance, but that script seems to have gone away in the last week or
two.

What is the replacement for it? I need something I can use to do a
reasonably representative task in gem5 which I can time to measure
simulator performance. I used to be able to do that with this command:

time ./build/X86/gem5.opt ./tests/gem5/x86-boot-tests/run_exit.py --kernel
../boot-test/vmlinux-4.19.83 --disk ../boot-test/base.img --cpu-type atomic
--num-cpus 1 --boot-type init
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: failing ARM dual CPU tests?

[Gabe Black via gem5-dev]

I tried deleting the resources directory again, and this time when I re-ran
the normal tests they all passed. There must have been some file which got
caught crossways, or I thought I had deleted but the ownership of the
directory was wrong, or etc, etc. Anyways, I think the mysterious failures
may be gone now. I'm running the long tests to make sure those also are now
working at ToT, and then I'll run them again on the locked mem change to
see if that's ok.

It's always a little unnerving to now know *how* a mysterious failure like
this got resolved, but at least it seems to have which is good?

Gabe

On Fri, Sep 24, 2021 at 2:55 PM Bobby Bruce  wrote:

> Hey Gabe,
>
> This is very strange and I can't say I've seen this issue before. The
> problem shouldn't be docker, none of these tests spin up an instance. I was
> going to suggest deleting the resources (`tests/gem5/resources`) and trying
> again, but it seems like you've tried that. My only sensible guess at this
> point is your not downloading the resources needed (network issues?), as,
> unfortunately, the TestLib downloader fails silently (e.g. if the download
> fails it tends to continue to try to run the test). Though if this is the
> case. it'd be weird to just see these tests failing as we download quite a
> few things to get testing working.
>
> Have you looked into the output under `tests/testing-results` to see
> what's printing to stdout/stderr for these tests? Do you notice anything
> unusual there?
>
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Wed, Sep 22, 2021 at 5:23 PM Gabe Black  wrote:
>
>> Thanks Giacomo, I *think* since these are running as part of the testing
>> infrastructure that they are downloading the files they need, and I hope
>> they are downloading current ones. Clearly *something* is out of whack, but
>> since this should all be handled automatically I don't know where or what
>> to look at to try to find what's out of date. I know once upon a time I had
>> an out of date docker that was causing problems, but I'm not using a docker
>> for this and so I don't think that's the problem(?).
>>
>> Do you have any ideas Bobby? I've tried deleting the resources directory
>> it downloads under tests, but that didn't seem to fix it.
>>
>> Gabe
>>
>> On Wed, Sep 22, 2021 at 9:17 AM Giacomo Travaglini <
>> giacomo.travagl...@arm.com> wrote:
>>
>>> Hi Gabe,
>>>
>>> From an Arm perspective, could you make sure you are using the latest
>>> bootloader?
>>> I remember there was a change some time ago which required the
>>> bootloader to be rebuilt
>>>
>>> You could either download latest tarball from
>>> https://www.gem5.org/documentation/general_docs/fullsystem/guest_binaries
>>>
>>> Or rebuild the bootloader yourself
>>>
>>> Kind Regards
>>>
>>> Giacomo
>>>
>>>
>>> > -Original Message-
>>> > From: Jason Lowe-Power via gem5-dev 
>>> > Sent: 22 September 2021 17:12
>>> > To: gem5 Developer List 
>>> > Cc: Gabe Black ; Jason Lowe-Power
>>> > 
>>> > Subject: [gem5-dev] Re: failing ARM dual CPU tests?
>>> >
>>> > Hey Gabe,
>>> >
>>> >
>>> > To solve this and the x86 test issue you've been having, I think there
>>> are a
>>> > couple of possibilities:
>>> >
>>> > 1. Can you use the docker images that kokoro uses? This will guarantee
>>> that
>>> > you are using the *exact* same "host" setup when running gem5. I think
>>> this
>>> > is the only way to have a consistent set of tests without something
>>> like
>>> > Bazel's reproducible build and test.
>>> > 2. We're open to modifying and improving the tests. If the tests don't
>>> work
>>> > for you, they probably don't work for others as well. Improving the
>>> > documentation so it's more clear how to use the tests or improving the
>>> > testing infrastructure or modifying the tests so that they work more
>>> easily for
>>> > more people would be a *very* welcome contribution.
>>> >
>>> > Cheers,
>>> > Jason
>>> >
>>> > On Tue, Sep 21, 2021 at 6:22 PM Gabe Black via gem5-dev >> > d...@gem5.org <mailto:gem5-dev@gem5.org> > wrote:
>>> >
>>> >
>>> >   Hi folks. When I run the test script mai

[gem5-dev] Re: name collision between tests/gem5 and built in gem5 module

[Gabe Black via gem5-dev]

I don't disagree with you :-)

Gabe

On Fri, Sep 24, 2021 at 2:46 PM Bobby Bruce  wrote:

> Personally I've never really liked the directory structure under `tests`.
> Scripts are often far from the tests that run them. There's also
> `tests/configs` and `tests/gem5/configs` which could almost certainly be
> merged. Almost all tests are stored under `tests/gem5` for no other reason
> than this is where we've put them. At the very least it's not a very
> descriptive name for the directory. While your solution would be
> beneficial, I also think we (well, probably just me unless anyone wants to
> volunteer) should think about how to clean-up this directory in general.
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Wed, Sep 22, 2021 at 10:32 PM Gabe Black via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Hey folks, just FYI, when running tests from the tests directory (as the
>> instructions say to do), if a script imports a gem5 module, there is some
>> ambiguity whether that should be the built in gem5 module added for the
>> components stuff, or if it should be the gem5 directory in the tests
>> directory used by the test infrastructure.
>>
>> I think as is today we get away with that for some timing reason I
>> haven't fully nailed down, and I'm attempting to reorder things in my SCons
>> refactor so that the internal version takes precedence over anything in the
>> file system. I'm hopeful this will fix things, but it's still running.
>>
>> This isn't necessarily a call to arms or anything, but this seems like a
>> situation likely enough to cause errors that I wanted to point it out.
>>
>> Gabe
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] name collision between tests/gem5 and built in gem5 module

[Gabe Black via gem5-dev]

Hey folks, just FYI, when running tests from the tests directory (as the
instructions say to do), if a script imports a gem5 module, there is some
ambiguity whether that should be the built in gem5 module added for the
components stuff, or if it should be the gem5 directory in the tests
directory used by the test infrastructure.

I think as is today we get away with that for some timing reason I haven't
fully nailed down, and I'm attempting to reorder things in my SCons
refactor so that the internal version takes precedence over anything in the
file system. I'm hopeful this will fix things, but it's still running.

This isn't necessarily a call to arms or anything, but this seems like a
situation likely enough to cause errors that I wanted to point it out.

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: failing ARM dual CPU tests?

[Gabe Black via gem5-dev]

Thanks Giacomo, I *think* since these are running as part of the testing
infrastructure that they are downloading the files they need, and I hope
they are downloading current ones. Clearly *something* is out of whack, but
since this should all be handled automatically I don't know where or what
to look at to try to find what's out of date. I know once upon a time I had
an out of date docker that was causing problems, but I'm not using a docker
for this and so I don't think that's the problem(?).

Do you have any ideas Bobby? I've tried deleting the resources directory it
downloads under tests, but that didn't seem to fix it.

Gabe

On Wed, Sep 22, 2021 at 9:17 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:

> Hi Gabe,
>
> From an Arm perspective, could you make sure you are using the latest
> bootloader?
> I remember there was a change some time ago which required the bootloader
> to be rebuilt
>
> You could either download latest tarball from
> https://www.gem5.org/documentation/general_docs/fullsystem/guest_binaries
>
> Or rebuild the bootloader yourself
>
> Kind Regards
>
> Giacomo
>
>
> > -Original Message-
> > From: Jason Lowe-Power via gem5-dev 
> > Sent: 22 September 2021 17:12
> > To: gem5 Developer List 
> > Cc: Gabe Black ; Jason Lowe-Power
> > 
> > Subject: [gem5-dev] Re: failing ARM dual CPU tests?
> >
> > Hey Gabe,
> >
> >
> > To solve this and the x86 test issue you've been having, I think there
> are a
> > couple of possibilities:
> >
> > 1. Can you use the docker images that kokoro uses? This will guarantee
> that
> > you are using the *exact* same "host" setup when running gem5. I think
> this
> > is the only way to have a consistent set of tests without something like
> > Bazel's reproducible build and test.
> > 2. We're open to modifying and improving the tests. If the tests don't
> work
> > for you, they probably don't work for others as well. Improving the
> > documentation so it's more clear how to use the tests or improving the
> > testing infrastructure or modifying the tests so that they work more
> easily for
> > more people would be a *very* welcome contribution.
> >
> > Cheers,
> > Jason
> >
> > On Tue, Sep 21, 2021 at 6:22 PM Gabe Black via gem5-dev  > d...@gem5.org <mailto:gem5-dev@gem5.org> > wrote:
> >
> >
> >   Hi folks. When I run the test script main.py locally on an
> otherwise
> > passing tree, I get 8 test failures. 6 of those are from x86 dynamic
> linking tests
> > which use a host library which uses a system call gem5 doesn't implement.
> > That is annoying, but I understand that problem.
> >
> >   The other 2 are from ARM dual CPU tests (like realview64-simple-
> > timing-dual-ARM-x86_64-opt-MatchFileRegex) which fail because the
> > second CPU doesn't come up, and the check doesn't see the message it
> > expects.
> >
> >   This is very surprising to me, since I don't think these tests
> would
> > have any host dependence, and I'm *pretty* sure that the files they use
> > would come from the resources thing and should be up to date, etc. The
> > system in the test seems to otherwise boot up, it's just that the second
> CPU
> > never comes online and linux prints an error message about it instead of
> the
> > normal one.
> >
> >   Does anybody know of something else I can try to update, etc, which
> > might fix these tests? Could there be stale system files it's using
> floating
> > around somewhere?
> >
> >   I would really like to get that sorted out, since that could affect
> > whether I can successfully test my locked memory helper function change,
> > since the earlier version of that had caused problems with O3 multi-CPU
> tests
> > for ARM, sort of right in line with this false positive on these tests.
> >
> >   Thanks!
> >   Gabe
> >   ___
> >   gem5-dev mailing list -- gem5-dev@gem5.org <mailto:gem5-
> > d...@gem5.org>
> >   To unsubscribe send an email to gem5-dev-le...@gem5.org
> > <mailto:gem5-dev-le...@gem5.org>
> >   %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> 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
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: failing ARM dual CPU tests?

[Gabe Black via gem5-dev]

On Wed, Sep 22, 2021 at 9:12 AM Jason Lowe-Power 
wrote:

> Hey Gabe,
>
> To solve this and the x86 test issue you've been having, I think there are
> a couple of possibilities:
>
> 1. Can you use the docker images that kokoro uses? This will guarantee
> that you are using the *exact* same "host" setup when running gem5. I think
> this is the only way to have a consistent set of tests without something
> like Bazel's reproducible build and test.
>

Yes, I think I might need to do that. Part of why that's a pain is that it
uses a different tool chain than I do locally, and so I have to delete all
my build directories or it chokes on the existing files. This is really a
work around rather than an actual fix, of course. To be clear that's
probably all we can do about it right now, but I think there's a flaw in
the way our dynamic linking support works if it relies on things being
installed on your host. I think you could argue it should *optionally*, or
even by default, use things on your host just as a way to lower the initial
barrier to getting things working, but I think it's a fundamental flaw if
there's no possible optional way to use anything *but* what's on your host.
That would mean if you wanted to use any dynamic library in your binary,
you'd have to install it on your host, and you'd get possibly different or
even incorrect behavior changing between a development workstation, a
cluster to sweep parameters, a machine at home for tinkering, etc.


> 2. We're open to modifying and improving the tests. If the tests don't
> work for you, they probably don't work for others as well. Improving the
> documentation so it's more clear how to use the tests or improving the
> testing infrastructure or modifying the tests so that they work more easily
> for more people would be a *very* welcome contribution.
>

Yes, this is already happening in the wild. I've seen reports from at least
two people that have run into this x86 problem. I would be happy to fix up
the testing infrastructure and would like to arrange for time to do a deep
dive into it, but I can't for now at least.
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] failing ARM dual CPU tests?

[Gabe Black via gem5-dev]

Hi folks. When I run the test script main.py locally on an otherwise
passing tree, I get 8 test failures. 6 of those are from x86 dynamic
linking tests which use a host library which uses a system call gem5
doesn't implement. That is annoying, but I understand that problem.

The other 2 are from ARM dual CPU tests
(like realview64-simple-timing-dual-ARM-x86_64-opt-MatchFileRegex) which
fail because the second CPU doesn't come up, and the check doesn't see the
message it expects.

This is very surprising to me, since I don't think these tests would have
any host dependence, and I'm *pretty* sure that the files they use would
come from the resources thing and should be up to date, etc. The system in
the test seems to otherwise boot up, it's just that the second CPU never
comes online and linux prints an error message about it instead of the
normal one.

Does anybody know of something else I can try to update, etc, which might
fix these tests? Could there be stale system files it's using floating
around somewhere?

I would really like to get that sorted out, since that could affect whether
I can successfully test my locked memory helper function change, since the
earlier version of that had caused problems with O3 multi-CPU tests for
ARM, sort of right in line with this false positive on these tests.

Thanks!
Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: SCons SimObject() and m5.objects hierarchy

[Gabe Black via gem5-dev]

Ack. After thinking about it a bit, I think a minor rename of the riscv
version is the right approach for right now.

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Page size for prefetchers

[Gabe Black via gem5-dev]

Ack

On Tue, Sep 14, 2021 at 8:55 AM Jason Lowe-Power 
wrote:

> Hi Gabe,
>
> It is reasonable to make the page size a parameter to the RubyPrefetcher
> (and default to 4KiB). I would hesitate from making the "cross_page"
> parameter implicit based on the page size parameter. IMO, that's confusing
> and error prone. Also, this is the smallest change with the least chance of
> unexpected consequences.
>
> Cheers,
> Jason
>
> On Tue, Sep 14, 2021 at 2:15 AM Gabe Black via gem5-dev 
> wrote:
>
>> Hi folks. I'm currently looking at getting rid of the arch/page_size.hh
>> header file (123 change series for vecregs.hh waiting for review, needs
>> attention from ARM next), and I have at least a good game plan to get rid
>> of the usage of the PageShift and PageBytes constants in most places.
>>
>> The one tricky place I'm probably going to have the most trouble with are
>> the prefetchers, both Ruby and classic, and in particular the Ruby one. In
>> the classic prefetchers, only the queued prefetcher seems to care what the
>> page size is. Also it only cares if there is a TLB associated with the
>> prefetcher. If there is, then that's a pretty good ISA specific spot to
>> feed in the page size information, and if it's missing nobody cares. I can
>> handle that without affecting any existing functionality that is at least
>> checked in upstream.
>>
>> On the Ruby side, there are three configs which both use the
>> RubyPrefetcher object, and don't have it's "cross_page" property set to
>> True, which makes (as far as I can tell) crossing page boundaries
>> irrelevant. That one config is configs/ruby/MESI_Two_Level.py.
>>
>> Is it reasonable to make the page size to respect a config parameter on
>> RubyPrefetcher?
>>
>> There are currently two parameters which are effectively related to page
>> size, whether it's ok to cross page boundaries, and the System object which
>> is only used to get the page size. Would it be reasonable to make that a
>> single page size parameter, which if unset implicitly means page crossing
>> is ok?
>>
>> I think from a configuration perspective this is maybe a little better,
>> since maybe you want your prefetcher to work on some non standard page
>> boundary for some reason. Maybe you're using lots of large pages or
>> something. It is slightly more manual, since the system object is currently
>> found automatically, and the page size is implicit with the system object.
>>
>> This implicitness is precisely the problem we have to fix though, since
>> if there isn't an implicit global ISA to use with an implicit (but
>> artificially forced) single page size to use, then there is no way for this
>> setting to remain implicit. It would really just be a question of where the
>> setting was/came from.
>>
>> Looking for input from Ruby people, and people that work with the memory
>> system and setups where the prefetcher is an important consideration in
>> that system.
>>
>> Gabe
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: SCons SimObject() and m5.objects hierarchy

[Gabe Black via gem5-dev]

Just FYI, I'm working on pushing env['TARGET_ISA'] == 'foo' checks out of
SCons, and I almost have it working except that both arm and riscv define
VirtIOMMIO.py SimObject files which conflict with each other since they
take the same slot in m5.objects. You could reasonably blame that on
copy/paste coding, but there are times when you need to have basically the
same thing with some differences in two different ISAs. We can fix that by
renaming things to have an ISA prefix, but alternatively we could also put
things in packages so we don't have a flat hierarchy rooted in m5.objects
which engenders these sorts of conflicts.

Gabe

On Mon, Aug 16, 2021 at 7:59 AM Jason Lowe-Power 
wrote:

> Hey Gabe,
>
> I completely agree with you that hierarchy in the Python code would be
> better! This is in part why we're working on the components library. The
> problem is supporting backwards compatibility.
>
> Cheers,
> Jason
>
> On Fri, Aug 13, 2021 at 5:49 PM Gabe Black  wrote:
>
>> Ok, it sounds like listing out the contents of the SimObject files is not
>> going to be a problem then, and I'll plan on doing that.
>>
>> *I* still like the idea of adding hierarchy (this is why python has
>> packages, c++ has namespaces, almost all modern languages have similar
>> features, etc), but fortunately that's an orthogonal issue to this and
>> isn't blocking. This just would make that easier to implement if we decide
>> to do that in the future.
>>
>> Gabe
>>
>> On Fri, Aug 13, 2021 at 10:21 AM Jason Lowe-Power 
>> wrote:
>>
>>> Hey Gabe,
>>>
>>> Some responses inline below.
>>>
>>> On Thu, Aug 12, 2021 at 9:37 PM Gabe Black via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
>>>> Hey folks, here are some of my thoughts on the SimObject() mechanism in
>>>> SCons, and the structure of the m5.objects package.
>>>>
>>>> Right now, when you put a SimObject('foo.py') line in a SConscript,
>>>> that eventually leads to SCons importing foo.py (with some special
>>>> machinery) and discovering through python what SimObjects, etc, are
>>>> declared in that file. Those are collected into lists, and then each
>>>> SimObject gets a params/Foo.hh, params/Bar.hh, etc.
>>>>
>>>> Then as far as m5.objects, each file declared with SimObject() ends up
>>>> as a subpackage, with the stuff inside it available as you would expect, ie
>>>> m5.objects.Foo.Bar and m5.objects.Foo.Foo. Also, all the SimObjects are
>>>> artificially put under m5.objects so that:
>>>>
>>>> from m5.objects import *
>>>>
>>>> will get everything.
>>>>
>>>>
>>>> First, having a single SimObject() which can produce an arbitrary
>>>> number of actual SimObject subclasses, enums, etc, is problematic for
>>>> SCons. SCons only does one pass, where you have to tell it all of what
>>>> files come from what files, and then tell it to build. That means that
>>>> SimObject() files *must* be read in during the build setup phase, since we
>>>> have to figure out what files they would produce. It would be much more
>>>> convenient to be able to delay that and do that as part of the actual
>>>> build. That would let us, for example, build the marshal binary as a build
>>>> product and not as part of setting up the build process itself.
>>>>
>>>> Second, something that I've brought up in the past is that having no
>>>> hierarchy in m5.objects is not ideal. That leads to SimObjects having
>>>> namespace information built into their name like "X86TLB", "ARMTLB", etc.
>>>> This makes things more verbose, and hides structure. It also increases the
>>>> likelihood of name collisions since everything is jammed into the same
>>>> space.
>>>>
>>>
>>> I actually think the more verbose names are better. I really don't like
>>> that we allow name "collisions" in different namespaces in C++ right now.
>>> That confuses me/our users and also confuses IDEs.
>>>
>>>
>>>>
>>>>
>>>> To help solve both of those problems, I'd like to propose changing
>>>> SimObject() to have an __all__ type parameter which specifies what inside
>>>> it to export, and what to export it as. It would also need to encode what
>>>> type of entity something is as well, so we know if we need to define an
>>>> enum, a SimObject, etc. Perhaps something li

[gem5-dev] Page size for prefetchers

[Gabe Black via gem5-dev]

Hi folks. I'm currently looking at getting rid of the arch/page_size.hh
header file (123 change series for vecregs.hh waiting for review, needs
attention from ARM next), and I have at least a good game plan to get rid
of the usage of the PageShift and PageBytes constants in most places.

The one tricky place I'm probably going to have the most trouble with are
the prefetchers, both Ruby and classic, and in particular the Ruby one. In
the classic prefetchers, only the queued prefetcher seems to care what the
page size is. Also it only cares if there is a TLB associated with the
prefetcher. If there is, then that's a pretty good ISA specific spot to
feed in the page size information, and if it's missing nobody cares. I can
handle that without affecting any existing functionality that is at least
checked in upstream.

On the Ruby side, there are three configs which both use the RubyPrefetcher
object, and don't have it's "cross_page" property set to True, which makes
(as far as I can tell) crossing page boundaries irrelevant. That one config
is configs/ruby/MESI_Two_Level.py.

Is it reasonable to make the page size to respect a config parameter on
RubyPrefetcher?

There are currently two parameters which are effectively related to page
size, whether it's ok to cross page boundaries, and the System object which
is only used to get the page size. Would it be reasonable to make that a
single page size parameter, which if unset implicitly means page crossing
is ok?

I think from a configuration perspective this is maybe a little better,
since maybe you want your prefetcher to work on some non standard page
boundary for some reason. Maybe you're using lots of large pages or
something. It is slightly more manual, since the system object is currently
found automatically, and the page size is implicit with the system object.

This implicitness is precisely the problem we have to fix though, since if
there isn't an implicit global ISA to use with an implicit (but
artificially forced) single page size to use, then there is no way for this
setting to remain implicit. It would really just be a question of where the
setting was/came from.

Looking for input from Ruby people, and people that work with the memory
system and setups where the prefetcher is an important consideration in
that system.

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] review help

[Gabe Black via gem5-dev]

Hi folks. I've uploaded many reviews recently, and there is another large
batch on the way. I really appreciate how there has been good engagement on
some of the reviews since I know everyone is busy, and few have a vested
interest in my projects.

To try to keep the reviews from piling up and never getting in, or getting
in with insufficient review, some of my colleagues (Yu-hsin and Jui-min)
from Google are going to help out. This will be a great opportunity for
them to get more involved with upstream and learn more about the guts of
gem5, and for us to be able to contribute more and more efficiently to
upstream.

This is of course not intended in *any way* to decrease the value of other
people's reviews, or diminish the importance of their feedback. If you want
to review a change or if you have concerns about something, please don't
hesitate to jump in and participate, this is just to help unload the
current choke point, which are the busy schedules of other volunteers.

One thing in particular that this may not help with are places where there
are requests for some sort of additional testing, for instance to make sure
we don't break our fairly new RISCV support which is being actively worked
on. I think the best way to address this is to have some sort of testing
criteria, either manual or automatic, so that changes aren't blocked
forever waiting for testing nobody either can or has time to do. If you can
at least *describe* what testing should be done, then that will enable
someone else to either perform the testing themselves, or even ideally
automate the testing and put it into our framework.

Anyway, I just wanted to let everyone know what's going on and what to
expect. Thanks!

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] SCons refactor reviews

[Gabe Black via gem5-dev]

Hey folks, I just uploaded a big new batch of patches to my series which
refactors our SCons scripts in various ways and cleans them up. I added
reviewers for the first few to get the ball rolling, but to avoid having to
go through each one and to avoid a big wave of email to people on the
reviewers list, many (most?) of them have no reviewer.

If you are a reviewer on that series, please take a look, and feel free to
keep reviewing even when you get to the end of the CLs that have reviewers.
If anybody else wants to take a look as well, please go ahead.

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: SCons SimObject() and m5.objects hierarchy

[Gabe Black via gem5-dev]

Ok, it sounds like listing out the contents of the SimObject files is not
going to be a problem then, and I'll plan on doing that.

*I* still like the idea of adding hierarchy (this is why python has
packages, c++ has namespaces, almost all modern languages have similar
features, etc), but fortunately that's an orthogonal issue to this and
isn't blocking. This just would make that easier to implement if we decide
to do that in the future.

Gabe

On Fri, Aug 13, 2021 at 10:21 AM Jason Lowe-Power 
wrote:

> Hey Gabe,
>
> Some responses inline below.
>
> On Thu, Aug 12, 2021 at 9:37 PM Gabe Black via gem5-dev 
> wrote:
>
>> Hey folks, here are some of my thoughts on the SimObject() mechanism in
>> SCons, and the structure of the m5.objects package.
>>
>> Right now, when you put a SimObject('foo.py') line in a SConscript, that
>> eventually leads to SCons importing foo.py (with some special machinery)
>> and discovering through python what SimObjects, etc, are declared in that
>> file. Those are collected into lists, and then each SimObject gets a
>> params/Foo.hh, params/Bar.hh, etc.
>>
>> Then as far as m5.objects, each file declared with SimObject() ends up as
>> a subpackage, with the stuff inside it available as you would expect, ie
>> m5.objects.Foo.Bar and m5.objects.Foo.Foo. Also, all the SimObjects are
>> artificially put under m5.objects so that:
>>
>> from m5.objects import *
>>
>> will get everything.
>>
>>
>> First, having a single SimObject() which can produce an arbitrary number
>> of actual SimObject subclasses, enums, etc, is problematic for SCons. SCons
>> only does one pass, where you have to tell it all of what files come from
>> what files, and then tell it to build. That means that SimObject() files
>> *must* be read in during the build setup phase, since we have to figure out
>> what files they would produce. It would be much more convenient to be able
>> to delay that and do that as part of the actual build. That would let us,
>> for example, build the marshal binary as a build product and not as part of
>> setting up the build process itself.
>>
>> Second, something that I've brought up in the past is that having no
>> hierarchy in m5.objects is not ideal. That leads to SimObjects having
>> namespace information built into their name like "X86TLB", "ARMTLB", etc.
>> This makes things more verbose, and hides structure. It also increases the
>> likelihood of name collisions since everything is jammed into the same
>> space.
>>
>
> I actually think the more verbose names are better. I really don't like
> that we allow name "collisions" in different namespaces in C++ right now.
> That confuses me/our users and also confuses IDEs.
>
>
>>
>>
>> To help solve both of those problems, I'd like to propose changing
>> SimObject() to have an __all__ type parameter which specifies what inside
>> it to export, and what to export it as. It would also need to encode what
>> type of entity something is as well, so we know if we need to define an
>> enum, a SimObject, etc. Perhaps something like this:
>>
>> SimObject('foo.py', ['objects.x86.TLB', 'objects.x86.LocalApic',
>> 'enum.MyFavoriteEnum'])
>>
>
> I like this idea. It will make other things like supporting documentation
> and typing easier as well. However, I think we should not make significant
> changes to the python module hierarchy.
>
>
>>
>> That would tell SCons what targets to set up for, and also how to
>> structure the m5.objects package.
>>
>> import m5.objects.x86
>>
>> Foo.tlb = x86.TLB()
>>
>> class Example(SimObject):
>> tlb = Param.x86.TLB(...)
>>
>>
>> This would be a major departure from how imports have worked. It would
>> mostly be mechanical when SimObjects are imported directly, but would make
>> "from m5.objects import *" impossible.\\
>>
>
> I think this is a huge downside. Essentially, all of the config files
> would have to be updated, and testing those is impossible in our current
> implementation. If we really think that deprecating `from m5.object import
> *` is going to provide large benefits for the community, then we are going
> to have to do it over *many* release cycles (at least 3, I would guess,
> maybe more).
>
>
>>
>> It would also probably also mean the params/ headers would be slightly
>> more complex, and would need to be something like:
>>
>> #include "params/x86/TLB.hh"
>>
>> instead of:
>>
>> #include "params/X86TLB.hh"
>>
>>
>> What do folks think?
>>
>> Gabe
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: plan to eliminate the "zero register" concept at the CPU level

[Gabe Black via gem5-dev]

Unfortunately it looks like that mechanism I mentioned (for predicating
reads/writes) makes some big assumptions which are not generally correct,
they just happened to be correct in the situation that feature was
initially used.

I think I'm going to try to replace that mechanism with one which puts
sentry indices into the source/dest arrays which other mechanisms will know
to skip. I think I remember mentioning that in an email before? That new
mechanism will both handle zero registers, and replace this predication
mechanism with something less complicated and less broken.

Gabe

On Thu, Aug 12, 2021 at 6:21 PM Gabe Black  wrote:

> Hey folks. I was thinking about better ways to handle the "zero register"
> in the CPUs.
>
> A plan I had a little while ago was something sort of like /dev/null,
> where the zero register would be flattened to one thing if it was a source
> which would always hold zero, and another thing as a destination which
> would just collect junk. I was thinking about how to implement this, but it
> occurred to me that this scheme would have unnecessary overhead. Even
> though the source register would never be written to and would always have
> the same value, it would have to actually take up a spot in the register
> file, get plumbed through to instructions, etc, just to have a fixed value.
> The destination register would also take up at least one slot, and on
> systems which use renaming, may actually take up more slots if multiple
> instructions that wrote to it were in flight at a time.
>
> Fortunately, there is a mechanism that was added for x86 for condition
> code registers a good while ago which will help. The original idea was that
> when there is a single "register" from an architectural view which is
> actually made up of multiple real registers from an implementation point of
> view, specifically the condition code portion of the flags register in x86,
> you might read a register to build the original value of the composite
> register, but then end up writing over all the bits that came from that
> part. This mechanism lets you conditionalize whether you're actually going
> to read from (or write to) a register, and leave it out of src/dest
> register arrays and not actually call the accessors if not.
>
> So, my proposal is to use this mechanism to handle accesses to any zero
> registers at the ISA description level, and remove all special handling
> anywhere else. I expect this to be fairly painless and non-controversial,
> but wanted to send this email to let people know what was going on just in
> case, and also to provide context for the eventual reviews. I think I might
> put this into a JIRA issue as well.
>
> Gabe
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] SCons SimObject() and m5.objects hierarchy

[Gabe Black via gem5-dev]

Hey folks, here are some of my thoughts on the SimObject() mechanism in
SCons, and the structure of the m5.objects package.

Right now, when you put a SimObject('foo.py') line in a SConscript, that
eventually leads to SCons importing foo.py (with some special machinery)
and discovering through python what SimObjects, etc, are declared in that
file. Those are collected into lists, and then each SimObject gets a
params/Foo.hh, params/Bar.hh, etc.

Then as far as m5.objects, each file declared with SimObject() ends up as a
subpackage, with the stuff inside it available as you would expect, ie
m5.objects.Foo.Bar and m5.objects.Foo.Foo. Also, all the SimObjects are
artificially put under m5.objects so that:

from m5.objects import *

will get everything.


First, having a single SimObject() which can produce an arbitrary number of
actual SimObject subclasses, enums, etc, is problematic for SCons. SCons
only does one pass, where you have to tell it all of what files come from
what files, and then tell it to build. That means that SimObject() files
*must* be read in during the build setup phase, since we have to figure out
what files they would produce. It would be much more convenient to be able
to delay that and do that as part of the actual build. That would let us,
for example, build the marshal binary as a build product and not as part of
setting up the build process itself.

Second, something that I've brought up in the past is that having no
hierarchy in m5.objects is not ideal. That leads to SimObjects having
namespace information built into their name like "X86TLB", "ARMTLB", etc.
This makes things more verbose, and hides structure. It also increases the
likelihood of name collisions since everything is jammed into the same
space.


To help solve both of those problems, I'd like to propose changing
SimObject() to have an __all__ type parameter which specifies what inside
it to export, and what to export it as. It would also need to encode what
type of entity something is as well, so we know if we need to define an
enum, a SimObject, etc. Perhaps something like this:

SimObject('foo.py', ['objects.x86.TLB', 'objects.x86.LocalApic',
'enum.MyFavoriteEnum'])

That would tell SCons what targets to set up for, and also how to structure
the m5.objects package.

import m5.objects.x86

Foo.tlb = x86.TLB()

class Example(SimObject):
tlb = Param.x86.TLB(...)


This would be a major departure from how imports have worked. It would
mostly be mechanical when SimObjects are imported directly, but would make
"from m5.objects import *" impossible.

It would also probably also mean the params/ headers would be slightly more
complex, and would need to be something like:

#include "params/x86/TLB.hh"

instead of:

#include "params/X86TLB.hh"


What do folks think?

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] plan to eliminate the "zero register" concept at the CPU level

[Gabe Black via gem5-dev]

Hey folks. I was thinking about better ways to handle the "zero register"
in the CPUs.

A plan I had a little while ago was something sort of like /dev/null, where
the zero register would be flattened to one thing if it was a source which
would always hold zero, and another thing as a destination which would just
collect junk. I was thinking about how to implement this, but it occurred
to me that this scheme would have unnecessary overhead. Even though the
source register would never be written to and would always have the same
value, it would have to actually take up a spot in the register file, get
plumbed through to instructions, etc, just to have a fixed value. The
destination register would also take up at least one slot, and on systems
which use renaming, may actually take up more slots if multiple
instructions that wrote to it were in flight at a time.

Fortunately, there is a mechanism that was added for x86 for condition code
registers a good while ago which will help. The original idea was that when
there is a single "register" from an architectural view which is actually
made up of multiple real registers from an implementation point of view,
specifically the condition code portion of the flags register in x86, you
might read a register to build the original value of the composite
register, but then end up writing over all the bits that came from that
part. This mechanism lets you conditionalize whether you're actually going
to read from (or write to) a register, and leave it out of src/dest
register arrays and not actually call the accessors if not.

So, my proposal is to use this mechanism to handle accesses to any zero
registers at the ISA description level, and remove all special handling
anywhere else. I expect this to be fairly painless and non-controversial,
but wanted to send this email to let people know what was going on just in
case, and also to provide context for the eventual reviews. I think I might
put this into a JIRA issue as well.

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: overview/documentation/tests for vector register related stuff?

[Gabe Black via gem5-dev]

On Mon, Aug 9, 2021 at 1:02 PM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:

> Hi Gabe,
>
> > -Original Message-----
> > From: Gabe Black via gem5-dev 
> > Sent: 09 August 2021 11:02
> > To: gem5 Developer List 
> > Cc: Gabe Black 
> > Subject: [gem5-dev] Re: overview/documentation/tests for vector register
> > related stuff?
> >
> > I've done a bit of digging so far, and I think I've figured out a bit
> about the
> > rename mode.
> >
> > 1. This is only used by ARM to handle the difference in how registers are
> > renamed in aarch64 vs otherwise.
> > 2. This is handled in O3 by detecting a squash in the CPU and then
> checking
> > the aarch64 bit of the PCState.
> > 3. If this changes, then O3 potentially shuffles things around to make
> register
> > chunks contiguous, and starts renaming things differently.
> > 4. The only way to switch in or out of aarch64 is through a fault.
>
> Yes, just to be more precise, it is happening by issuing a fault or by
> returning from a fault (this is just to make it clear
> the switch can happen with a non faulting instruction like an ERET)
>
> >
> > This leads me to a few conclusions.
> >
> > 1. Having the aarch64 bit in the PCState structure is probably not
> necessary
> > and may actually be harmful because it makes that structure larger and
> > slower to move around. This value does *not* change quickly or
> frequently,
> > and only changes as part of an already heavy mode switch. It does not
> need
> > to be predicted/predictable like a next PC, like something like thumb
> mode
> > might.
>
> You can figure out the execution mode (AArch64/AArch32) in a different way
> by inspecting
> The PSTATE. So I can see the redundancy. However, inspecting the
> PSTATE/CPSR from the TC is probably not
> going to be faster. We need to know the aarch64 in the decoder, so I guess
> we could cache it in there.
>
> In any case IMO I don't think removing it from the PCState is gonna affect
> in any measurable way simulation time.
>

Yeah, I think this is mostly orthogonal, I just wanted to bring it up since
I noticed it.


>
> > 2. The O3 CPU is checking renaming mode *way* more often than it really
> > needs to. Almost every single squash is *not* a switch to/from 64 bit
> mode,
> > but *every* switch involves that check, even in ISAs that don't even
> *have*
> > rename modes.
> > 3. The rename semantics switch can be handled right in the fault object
> when
> > it implements the faulting context switch. It can detect that a switch is
> > necessary and enact it without all the extra checks.
>
> Totally agree on point 2. About point 3, yes you could handle it in the
> fault object and in the ERET instruction.
> That would mean leaking uarch code in the arch directory. In other words,
> having some *O3 specific* code in
> The arch directory. This is not ideal IMHO as it is bounding the arch code
> to a single cpu model
>

Please see my CL here:
https://gem5-review.googlesource.com/c/public/gem5/+/49147

I don't think it brings uarch code into the ISA implementation. What it
does is reestablish the invariant that registers are atomic blobs which
have no structure to the CPU, and then builds the different indexing views
into the ARM implementation instead. This is the way it used to work where
an ISA would compose composite registers by reading in their parts. I would
say this actually brings *less* uarch implementation into the ISA than
before, since now the ISA doesn't need to worry about rename modes, or that
there is even a rename step. It just has to maintain the invariant that
registers are atomic blobs as far as the CPU is concerned, and build
whatever other semantics it needs on top of that.


>
> > 4. ARM can implement SVE, etc, using two different register files, one
> which
> > is indexed by element for 32 bit mode, and one which is indexed by vector
> > for 64 bit mode. The mode switch can copy values between the register
> files,
> > and we can remove what I suspect is a lot of machinery from O3 by just
> > letting it manage two different register files simply, instead of
> managing one
> > with two different personalities. This also makes the register files
> much more
> > homogenous and easier to generalize. A "real" CPU may not want to waste
> > transistors, buses, etc, for two separate register files, but in the end
> it
> > doesn't matter if the behavior is the same. This is all just in how O3
> does its
> > bookkeeping, and a redundant register file is nearly free for gem5.
> >
>
> I would love to see a cleaner implementation! But 

[gem5-dev] Re: overview/documentation/tests for vector register related stuff?

[Gabe Black via gem5-dev]

I've done a bit of digging so far, and I think I've figured out a bit about
the rename mode.

1. This is only used by ARM to handle the difference in how registers are
renamed in aarch64 vs otherwise.
2. This is handled in O3 by detecting a squash in the CPU and then checking
the aarch64 bit of the PCState.
3. If this changes, then O3 potentially shuffles things around to make
register chunks contiguous, and starts renaming things differently.
4. The only way to switch in or out of aarch64 is through a fault.

This leads me to a few conclusions.

1. Having the aarch64 bit in the PCState structure is probably not
necessary and may actually be harmful because it makes that structure
larger and slower to move around. This value does *not* change quickly or
frequently, and only changes as part of an already heavy mode switch. It
does not need to be predicted/predictable like a next PC, like something
like thumb mode might.
2. The O3 CPU is checking renaming mode *way* more often than it really
needs to. Almost every single squash is *not* a switch to/from 64 bit mode,
but *every* switch involves that check, even in ISAs that don't even *have*
rename modes.
3. The rename semantics switch can be handled right in the fault object
when it implements the faulting context switch. It can detect that a switch
is necessary and enact it without all the extra checks.
4. ARM can implement SVE, etc, using two different register files, one
which is indexed by element for 32 bit mode, and one which is indexed by
vector for 64 bit mode. The mode switch can copy values between the
register files, and we can remove what I suspect is a lot of machinery from
O3 by just letting it manage two different register files simply, instead
of managing one with two different personalities. This also makes the
register files much more homogenous and easier to generalize. A "real" CPU
may not want to waste transistors, buses, etc, for two separate register
files, but in the end it doesn't matter if the behavior is the same. This
is all just in how O3 does its bookkeeping, and a redundant register file
is nearly free for gem5.

Please let me know if this is correct, and I'll start chopping away. Some
way to test my changes would be very helpful, since otherwise I'll just be
hoping for the best :-P.

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] overview/documentation/tests for vector register related stuff?

[Gabe Black via gem5-dev]

Hi folks. I may have asked about this in general before, and I'm pretty
sure I've asked about specific pieces of this since I remember Giacomo
trying to help me out, but, what resources do we have around:

1. VecRegContainer
2. VecElem
3. VecPredReg
4. rename mode
5. readWriteable accessors
6. pinned writes

I would be interested in any existing documentation, design doc type
documents, tests (especially of the end product, ie the SVE extension),
and/or an overview of what all these pieces are intended to accomplish and
how they work together.

I've dug around in them enough to have a rough idea at least of what they
do superficially, but there's a lot of complexity there which I don't fully
understand.

I've cut away a lot of pieces of them already which weren't used which
helped, I think, but now I'm going to need to get into the guts of this a
little more deeply, and I really don't want to break anything (or
everything), especially in ways that aren't immediately apparent.

I remember in the past Giacomo tried to find me a test program I could use
which would exercise at least some of this stuff, but I remember it didn't
work for some reason, and I *think* it only tested neon and not SVE?

Also, while testing is very important and I do still want/need something on
that axis, I also want to understand what those various mechanisms are
there to accomplish. Trying to make exactly those mechanisms continue to
work would be one way to avoid breaking things, but maintaining the end
functionality they provide would work too, and that flexibility I think
will be incredibly useful.

I can find (or at least in the past have found) documentation for SVE
itself, so the higher priority would be understanding the various gem5
mechanisms so that I can operate on them without breaking everything.

Gabe
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: kokoro failures due to bug in gem5-art?

[Gabe Black via gem5-dev]

omehow.
>>>>>>
>>>>>> Gabe
>>>>>>
>>>>>> On Wed, Jul 21, 2021 at 3:52 PM Bobby Bruce 
>>>>>> wrote:
>>>>>>
>>>>>>> There's definitely something funny going on with the gem5art tests
>>>>>>> there but I believe that error is happening without triggering a 
>>>>>>> non-zero
>>>>>>> exit code. The gem5art test script is set to `set -e`, which means the
>>>>>>> script should exit immediately after a failure, yet it doesn't. The 
>>>>>>> testing
>>>>>>> also continues onto the other tests. I'll look into this.
>>>>>>>
>>>>>>> In the example you linked, the issue appears to be because it has
>>>>>>> reached the 6 hour timeout. We could increase the timeout to fix this, 
>>>>>>> but
>>>>>>> I'd like to know why our build/test times have increased enough to push 
>>>>>>> us
>>>>>>> over the 6 hour line.  I'll see if I can figure it out as well.
>>>>>>>
>>>>>>> --
>>>>>>> Dr. Bobby R. Bruce
>>>>>>> Room 3050,
>>>>>>> Kemper Hall, UC Davis
>>>>>>> Davis,
>>>>>>> CA, 95616
>>>>>>>
>>>>>>> web: https://www.bobbybruce.net
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jul 21, 2021 at 2:51 PM Gabe Black via gem5-dev <
>>>>>>> gem5-dev@gem5.org> wrote:
>>>>>>>
>>>>>>>> I've seen many kokoro failures lately, including this one which
>>>>>>>> seems to be from a problem in gem5-art? Any idea what's going on?
>>>>>>>>
>>>>>>>>
>>>>>>>> https://source.cloud.google.com/results/invocations/caae5aad-91a6-4c6e-9fbe-20962f9c5519/targets/gem5%2Fgcp_ubuntu%2Fpresubmit/log
>>>>>>>> ___
>>>>>>>> gem5-dev mailing list -- gem5-dev@gem5.org
>>>>>>>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>>>>>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>>>>>
>>>>>>>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: python versions used by SCons and gem5

[Gabe Black via gem5-dev]

On Thu, Aug 5, 2021 at 3:08 PM Bobby Bruce  wrote:

> Hey Gabe,
>
> Just so we're on the same page, I'd like to take a moment to outline how I
> understand this problem/solution. Please let me know if I've understood
> correctly:
>
> We essentially have three components of the project which interpret gem5
> Python code: The gem5 binary, the Marshal binary, and the Scons build
> system. The gem5 and Marshal binaries both link to the Python library, so
> we have no problems there; they should interpret things identically. The
> problematic entity is Scons which will use the host python executable when
> processing Simobjects et al. at compile time. Your solution is to offload
> the relevant Scons gem5 Python interpretations/auto-generations to the
> Marshal binary where they'll use the Python library. Is this correct?
>

Correct.


>
> If so, I support this move as it makes things considerably easier to work
> with. While there is the small `--without-python` drawback, I don't
> personally see this being a big problem for the vast majority of users.
>

Ok, great. I'll move forward with that then.


>
>
> I do have a few of questions (I'm not sure if you an answer them, but may
> be something to think about):
>
> 1) Will this make it easier to embed configuration scripts (such as those
> found in the `configs` directory) into the gem5 binary?
>

That would be orthogonal to this. You could more or less do that today,
although I think in most cases you wouldn't want to since then you'd have
to recompile gem5 to change them.


> 2) Will this change the way we add new SimObjects or will it be
> more-or-less identical as before?
>

There should be no change. Unrelated to this, the more I dig around in how
SimObjects are set up the more I think we may need to change something
there, but I haven't thought about that enough to know for sure if that's
necessary, or what a better system might look like.


> 3) One of our goals moving forward is to enforce more Python type
> annotations so we can use tools such as MyPy. We've had some problems
> running this with this due to embedding (i.e., we can't just point MyPy at
> a SimObject Python file). Do you have any idea if this could be made easier?
>


I'm not familiar with mypy, but looking at their website, something like
this might work?

https://mypy.readthedocs.io/en/latest/extending_mypy.html

It looks like it would be fairly easy to add that to gem5's python "main"
method, although of course I haven't tried it.

Gabe

>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: kokoro failures due to bug in gem5-art?

[Gabe Black via gem5-dev]

Yeah, I wouldn't be surprised if it was specific to kokoro, or something
about how its networking is set up. Those failures seem to have stopped
happening now, or at least are happening much less. I don't remember seeing
one for a while at least. Hopefully we can avoid making our timeout any
longer! Thanks for looking into it, Bobby.

Gabe

On Thu, Aug 5, 2021 at 1:16 PM Bobby Bruce  wrote:

> That theory could be true, and I certainly don't have any better ideas,
> though I've never observed any hang on my local machine when recreating
> this issue. It could be something specific to Kokoro.
>
> I've fixed the gem5art error here:
> https://gem5-review.googlesource.com/c/public/gem5/+/49044. We can see if
> this fixes the timeout issue. If the timeout error persists  we can
> consider increasing the timeout:
> https://gem5-review.googlesource.com/c/public/gem5/+/48443
>
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Thu, Jul 22, 2021 at 8:33 PM Gabe Black  wrote:
>
>> Another possibility is that while the gem5-art error may not actually
>> kill the run, it may, for instance, have failed trying to download
>> something with a generous timeout, and waiting for that timeout pushed the
>> rest of the run out enough to trip the timeout? Just a thought. I haven't
>> checked exhaustively, but it feels like the timeout always goes along with
>> the gem5-art error message.
>>
>> Gabe
>>
>> On Thu, Jul 22, 2021 at 5:27 PM Gabe Black  wrote:
>>
>>> Ok, thanks. I don't know if you saw the CL I put up recently where the
>>> src/base/cprintftime.cc executable (the one built from that source) was
>>> broken, which made kokoro fail. The breakage was real and worth fixing, but
>>> I'm not sure why kokoro was trying to build it in the first place? Maybe
>>> sometimes kokoro tries building things that we didn't really want it to.
>>>
>>> In my recent scons hacking, I ran into that accidentally when
>>> build/X86/${BLAHBLAH} expanded into build/X86/ because that variable didn't
>>> exist, so scons went of and started building EVERYTHING it knew about below
>>> build/X86/. Hypothetically, that could explain the long build times and the
>>> building of that random other binary? Maybe we have some sort of race
>>> condition where a target expands to an empty string?
>>>
>>> Gabe
>>>
>>> On Thu, Jul 22, 2021 at 3:04 PM Bobby Bruce  wrote:
>>>
>>>> Ok, so I did look into this today and didn't find anything. On my
>>>> desktop machine the difference in running the pre-submit tests from the
>>>> stable branch and develop branch (including building the binaries) was only
>>>> 10 minutes so we've really not done anything to increase the build/test
>>>> times to a significant extent. My running theory is Kokoro was running
>>>> slower (??? I have no idea what Kokoro is actually doing or running on
>>>> behind the scenes so I don't know whether that makes sense, but I cannot
>>>> think of any other explanation). I don't like the solution, but I've
>>>> submitted a patch to increase the timeout to 7 hours which should stop this
>>>> timeout event from happening:
>>>> https://gem5-review.googlesource.com/c/public/gem5/+/48443
>>>>
>>>> I still haven't looked into the gem5 error yet but I'm pretty confident
>>>> this shouldn't interfere with the presubmit validation.
>>>>
>>>> --
>>>> Dr. Bobby R. Bruce
>>>> Room 3050,
>>>> Kemper Hall, UC Davis
>>>> Davis,
>>>> CA, 95616
>>>>
>>>> web: https://www.bobbybruce.net
>>>>
>>>>
>>>> On Wed, Jul 21, 2021 at 5:37 PM Gabe Black 
>>>> wrote:
>>>>
>>>>> Ok thanks, Bobby. Please let me know if you find anything, especially
>>>>> if it looks like it's a bug in kokoro itself somehow.
>>>>>
>>>>> Gabe
>>>>>
>>>>> On Wed, Jul 21, 2021 at 3:52 PM Bobby Bruce 
>>>>> wrote:
>>>>>
>>>>>> There's definitely something funny going on with the gem5art tests
>>>>>> there but I believe that error is happening without triggering a non-zero
>>>>>> exit code. The gem5art test script is set to `set -e`, which means the
>>>>>> script should exit immediately after a failure, yet it doesn't. The 
>>>>>&g