[gem5-dev] Re: Issues when try to mount full-system image files

[Jason Lowe-Power via gem5-dev]

Here's the answer from the gem5-GPT bot (
https://chat.openai.com/g/g-o3y1y4t8J-gem5-gpt, if you have chatGPT plus):

The error message you're encountering indicates a problem with mounting the
filesystem from the `ubuntu-18.04-arm64-docker.img` image. This can be due
to several reasons such as an incorrect offset value, filesystem
corruption, or a mismatch between the filesystem type and the tools
available on your system. Here's a step-by-step approach to troubleshoot
and resolve this issue:

1. **Verify the Filesystem Type and Integrity:**
   - First, ensure that the image file is not corrupted. You can use
`sha256sum` or a similar tool to verify the integrity of the downloaded
image against the checksum provided on the gem5 guest binaries page.
   - Determine the filesystem type of the image. You can use the `file`
command to check the type of filesystem contained within the image. For
example: `file ubuntu-18.04-arm64-docker.img`.

2. **Check the Offset:**
   - The offset you've specified (`32256`) might be incorrect for the
image. The correct offset depends on how the image was created. You can use
`fdisk -l ubuntu-18.04-arm64-docker.img` to list the partitions within the
image and calculate the correct offset. The offset is typically the start
sector of the partition multiplied by the sector size (usually 512 bytes).

3. **Ensure Necessary Filesystem Support:**
   - Make sure your system supports the filesystem type used in the image.
For instance, if it's an ext4 filesystem, your system should have support
for mounting ext4 partitions.
   - If the filesystem is not natively supported by your Linux
distribution, you may need to install additional packages.

4. **Mounting the Image:**
   - Once you have the correct offset and ensured filesystem support, try
mounting the image again with the updated offset. Ensure that the mount
point (`./mnt`) exists and you have the necessary permissions to mount
there.

5. **Using `losetup`:**
   - Alternatively, you can use `losetup` to associate the image with a
loop device, specifying the correct offset, and then mount the loop device
instead of directly mounting the image file. This can sometimes be more
reliable.

6. **Checking for Additional Errors:**
   - If the issue persists, examine `dmesg` for any kernel messages that
might indicate why the mount operation is failing.

7. **Seeking Further Assistance:**
   - If you continue to face issues, consider reaching out to gem5
communities or forums with detailed information about the steps you've
taken and the specific errors encountered.

Remember to handle filesystem operations with care, especially when
mounting image files, to avoid data corruption. If you're not familiar with
these operations, it's a good idea to create backups of important data
before proceeding.

On Thu, Dec 21, 2023 at 9:45 PM sun2k23 via gem5-dev 
wrote:

> Hello,
>
> I'm trying to moving host files to full-system image files which is
> the ubuntu-18.04-arm64-docker.img, but encountered below error information
> in my linux terminal:  $: mount: /mnt: wrong fs type, bad option, bad
> superblock on /dev/loop1, missing codepage or helper program, or other
> error.
>
>It's pretty appreciated if anyone provide some comments or feedbacks on
> this issue.
>
>My terminal command is as below:  $: sudo mount -o loop,offset=32256
> ./ubuntu-18.04-arm64-docker.img ./mnt
>The ubuntu-18.04-arm64-docker.img is downloaded via gem5 guest binaries
> link.
>
>Best regards,
>
> Sun2K
>
>
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

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

[Jason Lowe-Power via gem5-dev]

This looks like a random failure to me. This happens on jenkins once every
week or two. It might be better tomorrow. Unfortunately, this failure gives
us no information.

On Fri, Jul 7, 2023 at 8:29 AM Matt Sinclair via gem5-dev 
wrote:

> Hi Bobby,
>
> How do I read this output?  I wanted to check if Square was still passing,
> because of the patch Matt P pushed yesterday, but I don't seem to see it.
> I realize we are replacing this setup shortly, but nonetheless want to make
> sure bugs aren't slipping in.
>
> Thanks,
> Matt
>
> On Fri, Jul 7, 2023 at 9:14 AM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> See <
>> https://jenkins.gem5.org/job/nightly/659/display/redirect?page=changes>
>>
>> Changes:
>>
>> [Bobby R. Bruce] util: Update GitHub Runners Vagrant to overcommit memory
>>
>> [Bobby R. Bruce] util: '-eq' -> '-ge' for if in vm_manager.sh
>>
>> [Bobby R. Bruce] util: Add 'shutdown' argument option to vm_manager.sh
>>
>> [Bobby R. Bruce] util: Add 'swapspace' daemon to runner VM.
>>
>>
>> --
>> [...truncated 2.76 MB...]
>> Starting Test Suite:
>> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example
>>
>> Starting Test Case:
>> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example
>> Test:
>> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example
>> Passed
>> Starting Test Case:
>> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Logging call to command: diff /tmp/gem5outfhfhbv7i/simout
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/second_chance_test1_ld
>> Test:
>> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Passed
>> Logging call to command:
>> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d
>> /tmp/gem5outtvvim2dh -re --silent-redirect
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
>> traces/second_chance_test2_ld
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/second_chance_test2_ld.py
>> Starting Test Suite:
>> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example
>>
>> Starting Test Case:
>> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example
>> Test:
>> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example
>> Passed
>> Starting Test Case:
>> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Logging call to command: diff /tmp/gem5outtvvim2dh/simout
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/second_chance_test2_ld
>> Test:
>> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Passed
>> Logging call to command:
>> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d
>> /tmp/gem5outqn5wz59b -re --silent-redirect
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
>> traces/second_chance_test3_ld
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/second_chance_test3_ld.py
>> Starting Test Suite:
>> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example
>>
>> Starting Test Case:
>> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example
>> Test:
>> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example
>> Passed
>> Starting Test Case:
>> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Logging call to command: diff /tmp/gem5outqn5wz59b/simout
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/second_chance_test3_ld
>> Test:
>> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Passed
>> Logging call to command:
>> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d
>> /tmp/gem5out6it56ldp -re --silent-redirect
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
>> traces/tree_plru_test1_ld
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/tree_plru_test1_ld.py
>> Starting Test Suite:
>> test-replacement-policy-traces/tree_plru_test1_ld-NULL-x86_64-opt-MI_example
>>
>> Starting Test Case:
>> test-replacement-policy-traces/tree_plru_test1_ld-NULL-x86_64-opt-MI_example
>> Test:
>> test-replacement-policy-traces/tree_plru_test1_ld-NULL-x86_64-opt-MI_example
>> Passed
>> Starting Test Case:
>> test-replacement-policy-traces/tree_plru_test1_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Logging call to command: diff /tmp/gem5out6it56ldp/simout
>> 

[gem5-dev] State of Arm SVE2 in gem5

[Jason Lowe-Power via gem5-dev]

Hi Giacomo,

I've noticed that you've been pushing a number of updates to the Arm ISA,
some of which are implementing Arm SVE2 instructions (I believe). Could you
let us know what the current status is of these instructions? Have all of
them been integrated into gem5 or just a subset?

Thanks!
Jason
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Re: Build failed in Jenkins: weekly #99

[Jason Lowe-Power via gem5-dev]

Thanks for quickly digging into this, Matt!

On Sat, Jan 7, 2023 at 1:41 PM Matt Sinclair via gem5-dev 
wrote:

> I have confirmed that the Pannotia benchmarks (to my surprise) are using
> AMD's cache bypassing flags for some memory accesses, which Vishnu added
> support for this week.  Good thing the support is added now!  But that is
> why they are failing here -- they hit a corner case Vishnu and I had
> considered, but implemented incorrectly.  I have a fix I am testing now and
> will push later tonight assuming it solves the problem.
>
> Matt
>
> On Fri, Jan 6, 2023 at 10:07 PM Matt Sinclair <
> mattdsinclair.w...@gmail.com> wrote:
>
>> Hi Matt P & Vishnu,
>>
>> It appears something with the GPU support must have broken between your
>> changes this week -- as far as I can tell all of the nightly tests passed
>> when you checked in your commits, but something in the more complex
>> benchmarks (BC in this case) is breaking:
>>
>> gem5.opt: build/GCN3_X86/mem/ruby/system/VIPERCoalescer.cc:265: void 
>> gem5::ruby::VIPERCoalescer::invTCPCallback(gem5::Addr): Assertion 
>> `m_cache_inv_pkt && m_num_pending_invs > 0' failed.
>>
>> Vishnu, did you test your changes with the weekly tests at all?
>>
>> Matt P did you test your changes with the weekly tests at all?  And have
>> you started bisecting yet to find the offending commit?
>>
>> If not, Vishnu I can show you how to do this.  I will be away next week
>> (although with intermittent email access) so a fix relying on me may be
>> delayed ... but hopefully between the three of us we can isolate and figure
>> out which commit is causing/fixing.  My intuition says that it's probably
>> one of Vishnu's commits, since Matt P's aren't changing the coherence
>> protocol at all, but it's not obvious why Vishnu's commits would be
>> affecting the invalidation calls at all ...
>>
>> Thanks,
>> Matt S.
>>
>> On Fri, Jan 6, 2023 at 9:54 PM jenkins-no-reply--- via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> See <
>>> https://jenkins.gem5.org/job/weekly/99/display/redirect?page=changes>
>>>
>>> Changes:
>>>
>>> [Bobby R. Bruce] ext: Fix SST Documentation links
>>>
>>> [Bobby R. Bruce] tests: Fix the download test
>>>
>>> [Bobby R. Bruce] stdlib: Removing incorrect requires.
>>>
>>> [Bobby R. Bruce] stdlib: se_binary_workload exits on work items by
>>> default
>>>
>>> [Bobby R. Bruce] configs: Fix unconnected PCI port in SST gem5 config
>>>
>>> [Bobby R. Bruce] mem: Add getAddrRanges in HBMCtrl
>>>
>>> [Bobby R. Bruce] system-arm: Fix FEAT_PAuth trapping in AArch64
>>> bootloader
>>>
>>> [Bobby R. Bruce] misc: Update version info to v22.0.0.2
>>>
>>> [Bobby R. Bruce] misc: Update RELEASE-NOTES.md for v22.0.0.2
>>>
>>> [Bobby R. Bruce] stdlib: Fix get_isa_from_str() exception behavior in
>>> isas.py
>>>
>>> [Bobby R. Bruce] dev-amdgpu: Handle ring buffer wrap for PM4 queue
>>>
>>> [Bobby R. Bruce] arch-vega: Fix SOPK instruction sign extends
>>>
>>> [Bobby R. Bruce] dev-amdgpu: Fix SDMA ring buffer wrap around
>>>
>>> [Bobby R. Bruce] arch-x86: X86ISA default vector_string to HygonGenuine
>>>
>>> [Bobby R. Bruce] arch-arm: Revert 'Setup TC/ISA at construction time..'
>>>
>>> [Bobby R. Bruce] stdlib,configs: Update riscvmatched-fs example docstring
>>>
>>> [Bobby R. Bruce] configs,stdlib: Fix import in riscvmatched-fs.py
>>>
>>> [Bobby R. Bruce] configs,stdlib,tests: Update riscvmatched-fs.py to-init
>>>
>>> [Bobby R. Bruce] tests: Update riscvmatched tests to use ALL/gem5.opt
>>>
>>> [Bobby R. Bruce] configs: Add missing `_pre_instantiate` call in
>>> "run_lupv.py"
>>>
>>> [Bobby R. Bruce] tests: Delete build directory before running KVM in
>>> nightly
>>>
>>> [Bobby R. Bruce] configs: Set CPU vendor to M5 Simulator in apu_se.py
>>>
>>> [Bobby R. Bruce] stdlib,python: Allow setting of to tick exits via m5
>>>
>>> [Bobby R. Bruce] stdlib, configs: Updating configs/example/gem5_library
>>>
>>> [Bobby R. Bruce] arch-arm: Setup TC/ISA at construction time 2nd attempt
>>>
>>> [Bobby R. Bruce] scons: Remove -Werror for the gem5 v22.1 release
>>>
>>> [Bobby R. Bruce] base: Update the version to v22.1.0.0
>>>
>>> [Bobby R. Bruce] python,tests: Update Resource URL path to v22-1
>>>
>>> [Bobby R. Bruce] stdlib: Update the gem5 resources' version to "v22.1"
>>>
>>> [Bobby R. Bruce] util-docker: Update gcn-gpu Docker to use v22-1 ROCM
>>> patch
>>>
>>> [Bobby R. Bruce] util-docker: Add v22-1 tag to docker-compose.yaml
>>>
>>> [Bobby R. Bruce] tests: Update the compiler-tests.sh to use the v22-1
>>> images
>>>
>>> [Bobby R. Bruce] tests: Abstract the docker image tag for Nightly tests
>>>
>>> [Bobby R. Bruce] tests: Update nightly test docker image tags to v22-1
>>>
>>> [Bobby R. Bruce] tests: Abstract the docker image tag for Weekly tests
>>>
>>> [Bobby R. Bruce] tests: Update weekly test docker image tags to v22-1
>>>
>>> [Bobby R. Bruce] util-gem5art: Fix incorrect type of size in
>>> `createArtifact`
>>>
>>> [Bobby R. Bruce] tests: Update presubmit.sh to use v22-1 docker 

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

[Jason Lowe-Power via gem5-dev]

Hi Matt,

That might work for KVM, but it doesn't work for the timing CPUs as far as
I know. The problem we ran into was not with KVM but with the timing CPUs.

The underlying problem is that we are not modeling the system correctly.
Either there's something wrong with our cpuid instruction (it's definitely
not a "valid" result! but I'm not sure if it's the main problem here), or
there's something wrong with our APIC implementation. Almost certainly both
are true, but I don't know which one is the main culprit here.

Cheers,
Jason

On Mon, Nov 14, 2022 at 5:05 PM Poremba, Matthew via gem5-dev <
gem5-dev@gem5.org> wrote:

> [AMD Official Use Only - General]
>
> Hi Bobby,
>
>
>
>
>
> I have seen this issue with do_boot_cpu as well. The short story is I had
> to use multiple event queues and set the “sim_quantum” of the Root object
> to 1e8:  https://gem5-review.googlesource.com/c/public/gem5/+/65131.
> Note that 1e8 is different from the 1e9 value used elsewhere in gem5. Based
> on a test of doing 100 boots with 4 CPUs, 1e8 booted all four CPUs every
> time and 1e9 booted all four CPUs only twice.
>
>
>
>
>
> -Matt
>
>
>
> *From:* Bobby Bruce via gem5-dev 
> *Sent:* Monday, November 14, 2022 10:37 AM
> *To:* gem5-dev@gem5.org
> *Cc:* Bobby Bruce 
> *Subject:* [gem5-dev] Re: Build failed in Jenkins: nightly #413
>
>
>
> *Caution:* This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
>
> Hey all,
>
>
>
> I've submitted the following patch to Gerrit which should fix the timeout
> issues we're seeing with the Jenkin's nightly build:
> https://gem5-review.googlesource.com/c/public/gem5/+/65492
> 
> .
>
>
>
> The high level summary of the problem is as follows:
>
>
>
> - Up until recently we were using "m5 Simulator" as the "vendor_string"
> for each CPU in a gem5 simulation by default.
>
> - The latest versions of GLIB are now much stricter in checking system
> capabilities. It does not recognize "m5 Simulator" as a legitimate vendor
> and this causes problems. We became aware of this when trying to run SE
> workloads in Ubuntu 22.04 or running FS Ubuntu 22.04 workloads.
>
> - Jason changed the default vendor string to "AuthenticAMD" via this
> commit: https://gem5-review.googlesource.com/c/public/gem5/+/64831
> .
> This fixed the above problems but due to a bug, highlighted here:
> https://gem5.atlassian.net/browse/GEM5-1300
> ,
> Linux boots were taking an extremely long time. This caused our Nightly
> tests to reach timeout.
>
> - Our solution is to change the default vector string "HygonGenuine".
> This fixes all of the problems (GLIB problems and long boot times).
> However, we'd prefer to use "AuthenticAMD" over "HygonGenuine" so would
> appreciate it someone could find the time to look into the bug in GEM5-1300.
>
>
>
> Thanks to everyone for your patience here. I know you've all been spammed
> with failing Nightly errors for some time now. Hopefully after this patch
> is submitted we'll be back to everything passing.
>
>
>
> Kind regards,
>
> Bobby
>
>
>
> --
>
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
>
>
> web: https://www.bobbybruce.net
> 
>
>
>
>
>
> On Wed, Nov 9, 2022 at 2:33 PM Bobby Bruce  wrote:
>
> It turns out this patch:
> https://gem5-review.googlesource.com/c/public/gem5/+/64831
> 

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

[Jason Lowe-Power via gem5-dev]

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] Re: Build failed in Jenkins: weekly #44

[Jason Lowe-Power via gem5-dev]

Hi all,

Here's a link to the failing test:
https://jenkins.gem5.org/job/weekly/44/artifact/tests/testing-results/SuiteUID%3Atiming-cpu_2-cores_mesi_two_level_DualChannelDDR4_2400_systemd_x86-boot-test-X86-x86_64-opt/TestUID%3Atiming-cpu_2-cores_mesi_two_level_DualChannelDDR4_2400_systemd_x86-boot-test-X86-x86_64-opt/

I *think* the problem is in how we're exiting the simulation after boot. It
looks like the system boots up correctly. However, the simulation is not
exiting cleanly as there are no stats output.

We've had some issues with flakiness in booting through systemd in
the past. I always assumed it's because systemd tries to enable networking,
etc. and something was going wrong in one of those subsystems, but maybe
it's something else. If anyone has ideas on how to track this down, I'd
love to hear them. Frustratingly, it seems to work when we run the test
locally.

Cheers,
Jason

On Sun, Apr 17, 2022 at 12:06 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See 
>
> Changes:
>
> [hoanguyen] stdlib, configs: Migrate riscv-ubuntu-run example to Simulator
>
> [Jason Lowe-Power] scons: Fix bug in error message
>
> [gabe.black] arch-x86: Override make(Read|Write) instead of
> (read|write)_code.
>
> [gabe.black] arch: Eliminate the now unused read_code and write_code args.
>
> [yuhsingw] scons: Fix script failed when default files not found
>
> [gabe.black] scons: Ensure the fast model license count is always at least
> 1.
>
> [yuhsingw] fastmodel: Export more CortexA76 reset pin
>
> [yuhsingw] fastmodel: Export more CortexR52 reset pin
>
> [joy] arch-riscv: Added the Zba and Zbb bitmanip instructions
>
> [joy] arch-riscv: Added the Zbc bitmanip instructions
>
> [joy] arch-riscv: Added the Zbs bitmanip instructions
>
> [hoanguyen] stdlib, configs: Fix riscv-ubuntu-run error
>
>
> --
> [...truncated 536.09 KB...]
>  [SHCC] X86/ext/softfloat/s_normSubnormalF16Sig.c -> .os
>  [SHCC] X86/ext/softfloat/s_normSubnormalF32Sig.c -> .os
>  [SHCC] X86/ext/softfloat/s_normSubnormalF64Sig.c -> .os
>  [SHCC] X86/ext/softfloat/softfloat_raiseFlags.c -> .os
>  [SHCC] X86/ext/softfloat/softfloat_state.c -> .os
>  [SHCC] X86/ext/softfloat/s_propagateNaNF128UI.c -> .os
>  [SHCC] X86/ext/softfloat/s_propagateNaNF16UI.c -> .os
>  [SHCC] X86/ext/softfloat/s_propagateNaNF32UI.c -> .os
>  [SHCC] X86/ext/softfloat/s_propagateNaNF64UI.c -> .os
>  [SHCC] X86/ext/softfloat/s_remStepMBy32.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundMToI64.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundMToUI64.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackMToI64.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackMToUI64.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackToF128.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackToF16.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackToF32.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackToF64.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackToI32.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackToI64.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackToUI32.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackToUI64.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundToI32.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundToI64.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundToUI32.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundToUI64.c -> .os
>  [SHCC] X86/ext/softfloat/s_shiftRightJam128.c -> .os
>  [SHCC] X86/ext/softfloat/s_shiftRightJam128Extra.c -> .os
>  [SHCC] X86/ext/softfloat/s_shiftRightJam256M.c -> .os
>  [SHCC] X86/ext/softfloat/s_shiftRightJam32.c -> .os
>  [SHCC] X86/ext/softfloat/s_shiftRightJam64.c -> .os
>  [SHCC] X86/ext/softfloat/s_shiftRightJam64Extra.c -> .os
>  [SHCC] X86/ext/softfloat/s_shortShiftLeft128.c -> .os
>  [SHCC] X86/ext/softfloat/s_shortShiftLeft64To96M.c -> .os
>  [SHCC] X86/ext/softfloat/s_shortShiftRight128.c -> .os
>  [SHCC] X86/ext/softfloat/s_shortShiftRightExtendM.c -> .os
>  [SHCC] X86/ext/softfloat/s_shortShiftRightJam128.c -> .os
>  [SHCC] X86/ext/softfloat/s_shortShiftRightJam128Extra.c -> .os
>  [SHCC] X86/ext/softfloat/s_shortShiftRightJam64.c -> .os
>  [SHCC] X86/ext/softfloat/s_shortShiftRightJam64Extra.c -> .os
>  [SHCC] X86/ext/softfloat/s_shortShiftRightM.c -> .os
>  [SHCC] X86/ext/softfloat/s_sub128.c -> .os
>  [SHCC] X86/ext/softfloat/s_sub1XM.c -> .os
>  [SHCC] X86/ext/softfloat/s_sub256M.c -> .os
>  [SHCC] X86/ext/softfloat/s_subMagsF128.c -> .os
>  [SHCC] X86/ext/softfloat/s_subMagsF16.c -> .os
>  [SHCC] X86/ext/softfloat/s_subMagsF32.c -> .os
>  [SHCC] X86/ext/softfloat/s_subMagsF64.c -> .os
>  [SHCC] X86/ext/softfloat/s_subM.c -> .os
>  [SHCC] X86/ext/softfloat/ui32_to_f128.c -> .os
>  [SHCC] X86/ext/softfloat/ui32_to_f16.c -> .os
>  [SHCC] 

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

[Jason Lowe-Power via gem5-dev]

It looks successful to me. Supposedly
test-gem5-library-example-x86-gapbs-benchmarks-X86-aarch64-opt-MESI_Two_Level
failed, but everything looks fine:
https://jenkins.gem5.org/job/nightly/194/artifact/tests/testing-results/SuiteUID%3Atest-gem5-library-example-x86-gapbs-benchmarks-X86-aarch64-opt-MESI_Two_Level/TestUID%3Atest-gem5-library-example-x86-gapbs-benchmarks-X86-aarch64-opt-MESI_Two_Level/

Let's hope that it's just a bump and things are back to normal tonight.

Cheers,
Jason

On Fri, Apr 15, 2022 at 3:53 PM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/194/display/redirect?page=changes>
>
> Changes:
>
> [hoanguyen] stdlib, configs: Fix riscv-ubuntu-run error
>
>
> --
> [...truncated 1.66 MB...]
> 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) in C library rt...
> (cached) yes
> Checking size of struct kvm_xsave ... (cached) yes
> Checking for member exclude_host in struct perf_event_attr...(cached) yes
> Checking for shm_open("/test", 0, 0) in C library None... (cached) yes
> Checking for char temp; backtrace_symbols_fd((void *), 0, 0) in C
> library None... (cached) yes
> Checking for pkg-config package protobuf... (cached) yes
> Checking for GOOGLE_PROTOBUF_VERIFY_VERSION in C++ library protobuf...
> (cached) yes
> Checking for C header file linux/if_tun.h... (cached) yes
> Checking whether __i386__ is declared... (cached) no
> Checking whether __x86_64__ is declared... (cached) yes
> Checking for compiler -Wno-self-assign-overloaded support... (cached) yes
> Checking for compiler -Wno-free-nonheap-object support... (cached) yes
> scons: done reading SConscript files.
> scons: Building targets ...
>  [VER TAGS]  -> GCN3_X86/sim/tags.cc
> scons: `build/GCN3_X86/gem5.opt' is up to date.
> 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.
> Building the following targets. This may take a while.
> /nobackup/jenkins/workspace/nightly/build/X86_MI_example/gem5.opt
> You may want to run with only a single ISA(--isa=), use --skip-build, or
> use 'rerun'.
> Logging call to command: scons -C /nobackup/jenkins/workspace/nightly -j
> 16 --ignore-style --no-compress-debug
> /nobackup/jenkins/workspace/nightly/build/X86_MI_example/gem5.opt
> --default=X86 PROTOCOL=MI_example
> scons: Entering directory `/nobackup/jenkins/workspace/nightly'
> scons: Reading SConscript files ...
>
> Mkdir("/nobackup/jenkins/workspace/nightly/build/X86_MI_example/gem5.build")
> Checking for linker -Wl,--as-needed support... (cached) yes
> Checking for compiler -Wno-free-nonheap-object 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
> Building in /nobackup/jenkins/workspace/nightly/build/X86_MI_example
> Using saved variables file(s)
> /nobackup/jenkins/workspace/nightly/build/X86_MI_example/gem5.build/variables
> 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) in C library rt...
> (cached) yes
> Checking size of struct kvm_xsave ... 

[gem5-dev] Re: gem5 v22.0 to be released in early May. Staging branch to be created by the end of April

[Jason Lowe-Power via gem5-dev]

Hi all,

I would like to merge in my multi-Ruby protocol changes:
https://gem5-review.googlesource.com/c/public/gem5/+/58469
Outstanding issues:
  - I'm still working on the one WIP change to update scons. This should be
ready to review in a couple of days. The other changesets are ready to
review now.

Cheers,
Jason

On Fri, Apr 15, 2022 at 9:13 AM Jason Lowe-Power 
wrote:

> Hi all,
>
> Please respond to this message with a pointer to the gerrit review links
> for changesets that you would like to prioritize for 22.0. This way the
> community can work together to make this another great release with lots of
> new features!
>
> There's a list of issues open in jira here
> .
> There's currently 65 issues that are "to do", "in progress", or "in
> review". We almost certainly will not be able to get to all of these in the
> next 2 weeks, but if there's something that's important to you, please let
> the community know, and we can try to work together to prioritize that.
>
> Cheers,
> Jason
>
> On Thu, Apr 14, 2022 at 11:39 AM Bobby Bruce via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Dear all,
>>
>> We intend to create the staging branch on April 28th, with the intent of
>> releasing gem5 v22.0 in early May. This is a two week warning. Please
>> ensure all your patches you wish to be part of v22.0 are submitted to the
>> develop branch prior to April 28th.
>>
>> Kind regards,
>> Bobby
>> --
>> Dr. Bobby R. Bruce
>> Room 3050,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>>
>>
>> On Mon, Apr 4, 2022 at 10:28 AM Bobby Bruce  wrote:
>>
>>> Dear all,
>>>
>>> In line with our policy of having three major releases a year, we're
>>> aiming to have v22.0 of gem5 released in early May.  This means we'll be
>>> creating a staging branch from the develop branch by the end of April. The
>>> staging branch will be intensely tested to ensure it is suitable for
>>> general community use before being merged into the stable branch.
>>>
>>> We understand there's a backlog of patches to be reviewed. We'll try to
>>> ensure everyone who puts in the effort to submit for this release, and
>>> responds promptly to feedback, makes it into the v22.0 release. If you feel
>>> your patches have been ignored, please ping us on the relevant Gerrit
>>> submission (if you have not already added reviewers, remember to add them).
>>> Help with reviewing over the next month would also be greatly appreciated.
>>>
>>> Kind regards,
>>> Bobby
>>> --
>>> Dr. Bobby R. Bruce
>>> Room 3050,
>>> Kemper Hall, UC Davis
>>> Davis,
>>> CA, 95616
>>>
>>> web: https://www.bobbybruce.net
>>>
>> ___
>> 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 v22.0 to be released in early May. Staging branch to be created by the end of April

[Jason Lowe-Power via gem5-dev]

Hi all,

Please respond to this message with a pointer to the gerrit review links
for changesets that you would like to prioritize for 22.0. This way the
community can work together to make this another great release with lots of
new features!

There's a list of issues open in jira here
.
There's currently 65 issues that are "to do", "in progress", or "in
review". We almost certainly will not be able to get to all of these in the
next 2 weeks, but if there's something that's important to you, please let
the community know, and we can try to work together to prioritize that.

Cheers,
Jason

On Thu, Apr 14, 2022 at 11:39 AM Bobby Bruce via gem5-dev 
wrote:

> Dear all,
>
> We intend to create the staging branch on April 28th, with the intent of
> releasing gem5 v22.0 in early May. This is a two week warning. Please
> ensure all your patches you wish to be part of v22.0 are submitted to the
> develop branch prior to April 28th.
>
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Mon, Apr 4, 2022 at 10:28 AM Bobby Bruce  wrote:
>
>> Dear all,
>>
>> In line with our policy of having three major releases a year, we're
>> aiming to have v22.0 of gem5 released in early May.  This means we'll be
>> creating a staging branch from the develop branch by the end of April. The
>> staging branch will be intensely tested to ensure it is suitable for
>> general community use before being merged into the stable branch.
>>
>> We understand there's a backlog of patches to be reviewed. We'll try to
>> ensure everyone who puts in the effort to submit for this release, and
>> responds promptly to feedback, makes it into the v22.0 release. If you feel
>> your patches have been ignored, please ping us on the relevant Gerrit
>> submission (if you have not already added reviewers, remember to add them).
>> Help with reviewing over the next month would also be greatly appreciated.
>>
>> Kind regards,
>> Bobby
>> --
>> Dr. Bobby R. Bruce
>> Room 3050,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>>
> ___
> 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: Request for comments/reviews: Multiple Ruby protocols in a single binary

[Jason Lowe-Power via gem5-dev]

Hi all,

I would really appreciate some reviews on these changes. This is something
that I know many in the development community (Andreas, Gabe, others) have
been asking for. Please take a look!

I think most changes are pretty straightforward. There is one change where
I would like some specific feedback on a good way to incorporate multiple
Ruby protocols into the SConscript (
https://gem5-review.googlesource.com/c/public/gem5/+/58443/2)

Hi Giacomo,

I dug into the idea you proposed a bit more today, and I'm pretty convinced
that it would be significant work.

It's possible to make a SimObject be part of a submodule of m5.objects.
However, the problem comes in the params. I don't think there's an easy way
to create two params/.hh files for SimObjects which have the
same name.

Basically, we have a strong assumption in the SimObject generation code
that no two SimObjects will have exactly the same name. Extending this to
allow SimObjects with the same name would be quite a bit of effort. Right
now, I don't believe this effort is worth the benefit for this set of
changes.

Let me know what you think.

Cheers,
Jason

On Fri, Apr 1, 2022 at 7:48 AM Jason Lowe-Power  wrote:

> Sounds like a good idea. But I don't know how to do this easily. All
> SimObjects are part of the m5.object module, and this is deeply embedded in
> many different parts of gem5.
>
> My best guess at how to do this would be to add a new type of SimObject
> which is not in m5.objects, but in a submodule. Then, we would also have to
> extend the Scons concept of "SimObject" and how scons creates the SimObject
> params files and the python m5.objects files. My initial thought is that
> this would be a lot more work. I could be wrong, though.
>
> If you have a specific idea on how to implement this, or if you can
> provide an implementation, I can try to integrate it with what I have done.
>
> Either way, it will require non-backwards compatible changes to configs to
> import the correct module or use the new names. I'm not sure the benefit is
> worth the investment, though.
>
> Let me know what you think :)
>
> Cheers,
> Jason
>
>
>
> On Fri, Apr 1, 2022 at 7:31 AM Giacomo Travaglini <
> giacomo.travagl...@arm.com> wrote:
>
>> Congrats to Jason and to everyone who’s making this possible!
>>
>>
>>
>> About the naming, I wonder if we could provide a different python module
>> per ruby protocol.
>>
>> That would allow us to avoid prefixing in favour of something like:
>>
>>
>> $from m5.objects.mi_example import L1Cache_Controller
>>
>>
>>
>> or
>>
>>
>> $from m5.objects.msi import L1Cache_Controller
>>
>>
>>
>> Kind Regards
>>
>>
>>
>> Giacomo
>>
>>
>>
>>
>>
>> *From: *Jason Lowe-Power via gem5-dev 
>> *Date: *Thursday, 31 March 2022 at 18:43
>> *To: *gem5 Developer List 
>> *Cc: *Jason Lowe-Power 
>> *Subject: *[gem5-dev] Request for comments/reviews: Multiple Ruby
>> protocols in a single binary
>>
>> Hi all,
>>
>>
>>
>> For as long as gem5 has been gem5, you have had to build a different gem5
>> binary if you want to use a different Ruby protocol. Making it possible to
>> build multiple protocols has been on the roadmap for a long time (at least
>> as long as I've been involved with the project).
>>
>>
>>
>> I'm excited to say that we've been able to do this (finally), and we have
>> a set of changesets on gerrit for review/comments feedback.
>>
>>
>>
>> There are a couple of todo items before it's merged, and a couple of
>> user-facing changes that we could not find a way to make fully backwards
>> compatible. More on this below.
>>
>>
>>
>> Let me know what you think, and let me know if there are any questions!
>> I'm excited to see this get in for gem5-22.0.
>>
>>
>>
>> Changes: https://gem5-review.googlesource.com/q/topic:all-ruby-protocols
>>
>>
>>
>> *Non-backwards compatible changes:*
>>
>> Previously each SLICC protocol used the same names for the same machine
>> time. E.g., MI_example has an `L1Cache_Controller` and MSI has an
>> `L1Cache_Controller`. These names were automatically generated from the
>> MachineType (L1Cache) + "_Controller". Now, since we want to be able to
>> compile these two protocols at the same time, we need to make sure there
>> are no (python) name clashes. So, these have been renamed to have the
>> protocol name prepended onto the machine name (e.g.,
>> `MI_example_L1Cache_Controller`).
>>
>>
>>

[gem5-dev] Problem decoding RISC-V vector instructions

[Jason Lowe-Power via gem5-dev]

Hi all,

In working to integrate the RISC-V vector instructions (RVV) implementation
from Rivos, I've come across a unique (to me) problem. In RVV, the vector
length and the size of the vector element is specified *at runtime* by the
`setvl` instruction. So, the way you decode a vector instruction changes
depending on the previous instructions that have executed.

The problem is that when constructing a static instruction, you need to
know the number of source and destination registers. You also need to be
able to set the src/dest register ids (though, I have to be honest that I
don't fully understand what `set[Src/Dest]RegIdx` is actually doing).

However, for RISC-V vector instructions, the number of src/dest registers
and register IDs depends on the current state (execution context). The
vector length, masking, and vector element size is dependent on
`MISCREG_VL` and `MISCREG_VTYPE`. Right now, these are MISCREGs, but it may
be more appropriate to use a different register class (e.g., something more
like CC regs?).

I can't find another example of this kind of dependency in the codebase. If
someone could point me to an example of how to use execution context state
to decode, I would appreciate it.

I have a feeling this is a new requirement. So, assuming there's no good
examples today, I'd appreciate some pointers for the "right" way to
implement this.

Right now, I'm not very concerned with being able to rename these
registers. Getting RVV working for the O3CPU isn't a requirement currently.
If we can come up with a solution that works in the simple case first, then
try to generalize to O3, that would be good with me.

I suppose one option would be to use the thread context (not execution
context) in the decoder to "speculate" what the vector length is, then, in
execute, read the correct value and make sure we're correct. This may work
for the Simple CPU. It probably won't work for the other CPU models.

Here's a link to the current (working) implementation that "hacks" around
the issue by passing the MISCREGs into the decoder.
https://github.com/rivosinc/gem5/commit/d6d068c9fabf34e5327107513ec41dea3e5e9acc

We could instead use the thread context pointer in the ISA object, but I
don't believe that will solve the problem generally.

Thanks for the input!

Cheers,
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] Re: Build failed in Jenkins: compiler-checks #189

[Jason Lowe-Power via gem5-dev]

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__)}'
>>>&

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

[Jason Lowe-Power via gem5-dev]

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 target 'Garnet_standalone.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'Garnet_standalone.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MESI_Two_Level.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MESI_Two_Level.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_CMP_directory.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_CMP_directory.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 '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 'NULL_MOESI_hammer.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_hammer.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL.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 'MIPS.opt' with 'gcc-version-11'...
> Done.
>   * 

[gem5-dev] Re: Request for comments/reviews: Multiple Ruby protocols in a single binary

[Jason Lowe-Power via gem5-dev]

Sounds like a good idea. But I don't know how to do this easily. All
SimObjects are part of the m5.object module, and this is deeply embedded in
many different parts of gem5.

My best guess at how to do this would be to add a new type of SimObject
which is not in m5.objects, but in a submodule. Then, we would also have to
extend the Scons concept of "SimObject" and how scons creates the SimObject
params files and the python m5.objects files. My initial thought is that
this would be a lot more work. I could be wrong, though.

If you have a specific idea on how to implement this, or if you can provide
an implementation, I can try to integrate it with what I have done.

Either way, it will require non-backwards compatible changes to configs to
import the correct module or use the new names. I'm not sure the benefit is
worth the investment, though.

Let me know what you think :)

Cheers,
Jason



On Fri, Apr 1, 2022 at 7:31 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:

> Congrats to Jason and to everyone who’s making this possible!
>
>
>
> About the naming, I wonder if we could provide a different python module
> per ruby protocol.
>
> That would allow us to avoid prefixing in favour of something like:
>
>
> $from m5.objects.mi_example import L1Cache_Controller
>
>
>
> or
>
>
> $from m5.objects.msi import L1Cache_Controller
>
>
>
> Kind Regards
>
>
>
> Giacomo
>
>
>
>
>
> *From: *Jason Lowe-Power via gem5-dev 
> *Date: *Thursday, 31 March 2022 at 18:43
> *To: *gem5 Developer List 
> *Cc: *Jason Lowe-Power 
> *Subject: *[gem5-dev] Request for comments/reviews: Multiple Ruby
> protocols in a single binary
>
> Hi all,
>
>
>
> For as long as gem5 has been gem5, you have had to build a different gem5
> binary if you want to use a different Ruby protocol. Making it possible to
> build multiple protocols has been on the roadmap for a long time (at least
> as long as I've been involved with the project).
>
>
>
> I'm excited to say that we've been able to do this (finally), and we have
> a set of changesets on gerrit for review/comments feedback.
>
>
>
> There are a couple of todo items before it's merged, and a couple of
> user-facing changes that we could not find a way to make fully backwards
> compatible. More on this below.
>
>
>
> Let me know what you think, and let me know if there are any questions!
> I'm excited to see this get in for gem5-22.0.
>
>
>
> Changes: https://gem5-review.googlesource.com/q/topic:all-ruby-protocols
>
>
>
> *Non-backwards compatible changes:*
>
> Previously each SLICC protocol used the same names for the same machine
> time. E.g., MI_example has an `L1Cache_Controller` and MSI has an
> `L1Cache_Controller`. These names were automatically generated from the
> MachineType (L1Cache) + "_Controller". Now, since we want to be able to
> compile these two protocols at the same time, we need to make sure there
> are no (python) name clashes. So, these have been renamed to have the
> protocol name prepended onto the machine name (e.g.,
> `MI_example_L1Cache_Controller`).
>
>
>
> For most people using Ruby, we can provide backwards compatibility. If you
> simply instantiate the `L1Cache_Controller` in python, we can provide a new
> factory function that does the "right" thing. However, if you inherit from
> `L1Cache_Controller` to specialize the controller, this won't work.
>
>
>
> *The user-facing change is* if you have any local ruby protocol
> configuration files which use inheritance with the controllers, you will
> have to update the controller classes to use the name of the protocol
> prepended on the controller name.
>
>
>
> We have updated all of the configurations that are in the gem5 repo. You
> will see warnings if you use the old backwards-compatible names (including
> with Ruby.py).
>
>
>
> The only other user-facing change (I think, reviewers, please point out if
> I'm wrong), is that in places that `buildEnv["PROTOCOL"]` was used to check
> the protocol that was built, you will now need to use `getRubyProtocol`
> (also available in `m5.defines`). However, we are currently supporting
> backwards compatibility here, but there will be no warning when we drop
> backwards compatibility (I expect this to be in a couple of releases).
>
>
>
> *To do items*
>
> - Correctly integrate this with scons (and the new kconfig). See
> https://gem5-review.googlesource.com/c/public/gem5/+/58443 for a WIP that
> needs to be updated.
>
> - Update the website. Assuming there are no major flaws in our
> implementation, we will update the website soon (before the changes are
> com

[gem5-dev] Re: Request for comments/reviews: Multiple Ruby protocols in a single binary

[Jason Lowe-Power via gem5-dev]

Thanks, Brad!

I *hope* that the downstream work is minimal. There's only one change that
I couldn't figure out a way to make backwards compatible, and it's a very
minor update. BTW, if you have an idea on how to make it backwards
compatible, I'm open to revising. I tried a few different things, but I
couldn't find a solution.

The motivation was twofold:
1. There are two sets of changes pushed by Gabe Black that move us closer
to having a single gem5 binary: the MultiISA changes and the kconfig
changes. When these are merged, Ruby was the only thing holding us back
from having a single gem5 binary. I think that having a single gem5 binary
will be a huge win for our users. In fact, for many users they will only
have to build gem5 once, or maybe not at all, if we distribute a prebuilt
version!
2. Testing will be much easier/faster. I don't have data on this, yet, as
the final contribution to select the protocol at runtime is missing. I'm
waiting for reviews on the scons changes before I tackle the last part.
That said, well over 50% (probably closer to 75% or more) of our testing is
building gem5. If we can reduce the number of different targets, we're
going to see a huge win, even if each build is 10% slower.

I'll say that if we were to merge the changes as-is (which we shouldn't!
there's still at least one large WIP), the compile time would increase. In
fact, it would increase in the worst possible way. SLICC is pretty slow
right now, and it runs once for every protocol during the scons startup.
So, building after a change even to a single file is going to be worse with
this change. Thus, I am advocating for waiting on this change (at least the
part that enables multiple protocols) until after the kconfig changes have
been merged.

Let me know if you have any other questions!

Here's the change that I couldn't figure out how to make backwards
compatible: https://gem5-review.googlesource.com/c/public/gem5/+/58442 I
can go into more details on that changeset, if you'd like.
Here's the change that should not be merged until we have a way to easily
select which protocols to build:
https://gem5-review.googlesource.com/c/public/gem5/+/58443 Everything up to
that change makes no difference to compile time, etc.

Cheers,
Jason

On Thu, Mar 31, 2022 at 12:36 PM Beckmann, Brad 
wrote:

> [AMD Official Use Only]
>
> Hi Jason,
>
>
>
> This is a huge undertaking.  I’m very impressed that you got this the
> work.  Congratulations!
>
>
>
> Your email covers many important aspects of the change, but one item
> missing is the motivation for the change.  Is it primarily compilation
> simplicity?  Now one can build gem5 once and use that binary to run
> multiple different protocols at different times?  If so, can you speak to
> the compilation speedup of compiling all protocols at once versus compiling
> each one individually.  Also does this change allow us to add more tests to
> check-ins because we don’t have to spend as much time building a bunch of
> individual binaries?  Some quantified data could really help motivate the
> downstream work involved to consume this change.
>
>
>
> Thanks!
>
>
>
> Brad
>
>
>
>
>
>
>
>
>
> *From:* Jason Lowe-Power via gem5-dev 
> *Sent:* Thursday, March 31, 2022 9:42 AM
> *To:* gem5 Developer List 
> *Cc:* Jason Lowe-Power 
> *Subject:* [gem5-dev] Request for comments/reviews: Multiple Ruby
> protocols in a single binary
>
>
>
> [CAUTION: External Email]
>
> Hi all,
>
>
>
> For as long as gem5 has been gem5, you have had to build a different gem5
> binary if you want to use a different Ruby protocol. Making it possible to
> build multiple protocols has been on the roadmap for a long time (at least
> as long as I've been involved with the project).
>
>
>
> I'm excited to say that we've been able to do this (finally), and we have
> a set of changesets on gerrit for review/comments feedback.
>
>
>
> There are a couple of todo items before it's merged, and a couple of
> user-facing changes that we could not find a way to make fully backwards
> compatible. More on this below.
>
>
>
> Let me know what you think, and let me know if there are any questions!
> I'm excited to see this get in for gem5-22.0.
>
>
>
> Changes: https://gem5-review.googlesource.com/q/topic:all-ruby-protocols
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgem5-review.googlesource.com%2Fq%2Ftopic%3Aall-ruby-protocols=04%7C01%7Cbrad.beckmann%40amd.com%7C8d109b9ce6e1484f661508da13357d22%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637843417701279262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=eVLWdZC6Kp0DmBoVanOw%2BASEgwXYv%2FsssJNGIZUCGqE%3D=0>
>
>
>
> *Non-backwards compatible changes:*
>
> Pre

[gem5-dev] Request for comments/reviews: Multiple Ruby protocols in a single binary

[Jason Lowe-Power via gem5-dev]

Hi all,

For as long as gem5 has been gem5, you have had to build a different gem5
binary if you want to use a different Ruby protocol. Making it possible to
build multiple protocols has been on the roadmap for a long time (at least
as long as I've been involved with the project).

I'm excited to say that we've been able to do this (finally), and we have a
set of changesets on gerrit for review/comments feedback.

There are a couple of todo items before it's merged, and a couple of
user-facing changes that we could not find a way to make fully backwards
compatible. More on this below.

Let me know what you think, and let me know if there are any questions! I'm
excited to see this get in for gem5-22.0.

Changes: https://gem5-review.googlesource.com/q/topic:all-ruby-protocols

*Non-backwards compatible changes:*
Previously each SLICC protocol used the same names for the same machine
time. E.g., MI_example has an `L1Cache_Controller` and MSI has an
`L1Cache_Controller`. These names were automatically generated from the
MachineType (L1Cache) + "_Controller". Now, since we want to be able to
compile these two protocols at the same time, we need to make sure there
are no (python) name clashes. So, these have been renamed to have the
protocol name prepended onto the machine name (e.g.,
`MI_example_L1Cache_Controller`).

For most people using Ruby, we can provide backwards compatibility. If you
simply instantiate the `L1Cache_Controller` in python, we can provide a new
factory function that does the "right" thing. However, if you inherit from
`L1Cache_Controller` to specialize the controller, this won't work.

*The user-facing change is* if you have any local ruby protocol
configuration files which use inheritance with the controllers, you will
have to update the controller classes to use the name of the protocol
prepended on the controller name.

We have updated all of the configurations that are in the gem5 repo. You
will see warnings if you use the old backwards-compatible names (including
with Ruby.py).

The only other user-facing change (I think, reviewers, please point out if
I'm wrong), is that in places that `buildEnv["PROTOCOL"]` was used to check
the protocol that was built, you will now need to use `getRubyProtocol`
(also available in `m5.defines`). However, we are currently supporting
backwards compatibility here, but there will be no warning when we drop
backwards compatibility (I expect this to be in a couple of releases).

*To do items*
- Correctly integrate this with scons (and the new kconfig). See
https://gem5-review.googlesource.com/c/public/gem5/+/58443 for a WIP that
needs to be updated.
- Update the website. Assuming there are no major flaws in our
implementation, we will update the website soon (before the changes are
committed). The main updates are the two user-facing changes described
above, but I expect some updates to how Ruby/SLICC works as well.
- Add another commit that checks if the protocol is in the list of built
protocols instead of a single protocol. I'm holding off on this one until
item #1 is complete. This will also include a new command-line parameter to
set the "main" protocol for backwards compatibility.

Cheers,
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] Re: Build failed in Jenkins: nightly #177

[Jason Lowe-Power via gem5-dev]

I'm not sure why this test failed. The build artifacts look successful.

However, there seems to be a bug in which tests are selected to run. We
seem to be running duplicate tests on the x86_64 host and calling them both
x86_64 and aarch64 tests.

Jason

On Tue, Mar 29, 2022 at 11:01 PM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/177/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
>
>
> --
> [...truncated 3.91 MB...]
>  [SHCC] X86_MESI_Two_Level/ext/libelf/elf_getarsym.c -> .os
>  [SHCC] X86_MESI_Two_Level/ext/libelf/gelf_move.c -> .os
>  [SHCC] X86_MESI_Two_Level/ext/libelf/elf_hash.c -> .os
>  [SHCC] X86_MESI_Two_Level/ext/libelf/libelf_ar_util.c -> .os
>  [SHCC] X86_MESI_Two_Level/ext/libelf/gelf_shdr.c -> .os
>  [SHCC] X86_MESI_Two_Level/ext/libelf/gelf_cap.c -> .os
>  [SHCC] X86_MESI_Two_Level/ext/libelf/elf_rawfile.c -> .os
>  [SHCC] X86_MESI_Two_Level/ext/libelf/elf_open.c -> .os
>  [SHCC] X86_MESI_Two_Level/ext/libelf/elf_getident.c -> .os
>  [SHCC] X86_MESI_Two_Level/ext/libelf/elf.c -> .os
>  [SHCC] X86_MESI_Two_Level/ext/libelf/libelf_xlate.c -> .os
>  [SHCC] X86_MESI_Two_Level/ext/libelf/elf_update.c -> .os
>  [SHCC] X86_MESI_Two_Level/ext/libelf/gelf_checksum.c -> .os
>  [SHCC] X86_MESI_Two_Level/ext/libelf/gelf_rela.c -> .os
>  [SHCC] X86_MESI_Two_Level/ext/libelf/gelf_dyn.c -> .os
>  [SHCC] X86_MESI_Two_Level/ext/libelf/elf_fill.c -> .os
>  [SHCC] X86_MESI_Two_Level/ext/libelf/elf_errmsg.c -> .os
>  [SHCC] X86_MESI_Two_Level/ext/libelf/elf_next.c -> .os
>  [SHCC] X86_MESI_Two_Level/ext/libelf/elf_shnum.c -> .os
>  [  AR]  -> X86_MESI_Two_Level/ext/softfloat/libsoftfloat.a
>  [  AR]  -> X86_MESI_Two_Level/ext/libelf/libelf.a
>  [  RANLIB]  -> X86_MESI_Two_Level/ext/libelf/libelf.a
>  [  RANLIB]  -> X86_MESI_Two_Level/ext/softfloat/libsoftfloat.a
>  [LINK]  -> X86_MESI_Two_Level/gem5.opt
> /usr/bin/ld: skipping incompatible /usr/lib/libgcc_s.so.1 when searching
> for libgcc_s.so.1
> /usr/bin/ld: skipping incompatible /usr/lib/libgcc_s.so.1 when searching
> for libgcc_s.so.1
> 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.
> Warning: Deleting old variant variables file
> "/nobackup/jenkins/workspace/nightl
>  y/build/variables/X86_MESI_Two_Level"
> Building the following targets. This may take a while.
> /nobackup/jenkins/workspace/nightly/build/GCN3_X86/gem5.opt
> You may want to run with only a single ISA(--isa=), use --skip-build, or
> use 'rerun'.
> Logging call to command: scons -C /nobackup/jenkins/workspace/nightly -j
> 16 --ignore-style --no-compress-debug
> /nobackup/jenkins/workspace/nightly/build/GCN3_X86/gem5.opt
> scons: Entering directory `/nobackup/jenkins/workspace/nightly'
> scons: Reading SConscript files ...
> Mkdir("/nobackup/jenkins/workspace/nightly/build/GCN3_X86/gem5.build")
> Checking for linker -Wl,--as-needed support... (cached) yes
> Checking for compiler -Wno-free-nonheap-object 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
> Building in /nobackup/jenkins/workspace/nightly/build/GCN3_X86
> Using saved variables file(s)
> /nobackup/jenkins/workspace/nightly/build/GCN3_X86/gem5.build/variables
> 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) 

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

[Jason Lowe-Power via gem5-dev]

Thanks, Gabe!

On Tue, Mar 15, 2022 at 9:28 PM Gabe Black via gem5-dev 
wrote:

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

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

[Jason Lowe-Power via gem5-dev]

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  ] TwoDifferentVecRegs.ShowParam
> [   OK ] TwoDifferentVecRegs.ShowParam (0 ms)
> [--] 6 tests from TwoDifferentVecRegs (0 ms total)
>
> [--] Global test environment tear-down
> [==] 8 tests from 2 test suites ran. (0 ms total)
> [  PASSED  ] 8 tests.
>  [SO Param] m5.objects.SimObject, SimObject -> NULL/params/SimObject.hh
>  [ENUMDECL] m5.objects.StaticInstFlags, StaticInstFlags ->
> NULL/enums/StaticInstFlags.hh
>  [ENUMDECL] m5.objects.FuncUnit, OpClass -> NULL/enums/OpClass.hh
>  [ENUMDECL] m5.objects.SimObject, ByteOrder -> NULL/enums/ByteOrder.hh
> build/NULL/arch/generic/vec_pred_reg.test.opt
> --gtest_output=xml:build/NULL/unittests.opt/arch/generic/vec_pred_reg.test.xml
> Running main() from build/NULL/ext/googletest/googletest/src/gtest_main.cc
> [==] Running 14 tests from 3 test suites.
> [--] Global test environment set-up.
> [--] 2 tests from VecPredReg
> [ RUN  ] VecPredReg.reset
> [   OK ] VecPredReg.reset (0 ms)
> [ RUN  ] VecPredReg.set
> [   OK ] VecPredReg.set (0 ms)
> [--] 2 tests from VecPredReg (0 ms total)
>
> [--] 9 tests from TwoDifferentVecPredRegs
> [ RUN  ] 

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

[Jason Lowe-Power via gem5-dev]

I spent some time looking into this I'm not sure what's going on. I
don't *think* we're running out of memory (at least, dmesg doesn't say we
ran out of memory).

I'm trying to figure out if maybe docker is configured to kill processes
when they use "too much" memory (for some definition of too much), but
having trouble tracking that down.

I'll keep digging...

Jason

On Fri, Mar 11, 2022 at 4:31 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/157/display/redirect?page=changes>
>
> Changes:
>
> [gabe.black] arch-x86: Use the new operand desc classes in the ISA
> description.
>
> [gabe.black] arch: Create a new operand desc type which takes a class as a
> parameter.
>
> [gabe.black] arch-riscv: Use the OperandDesc classes in the ISA
> description.
>
> [gabe.black] arch-arm: Use the new OperandDesc classes in the ISA
> description.
>
>
> --
> [...truncated 1.49 MB...]
> Starting Test Case: build-POWER-opt
> Starting Test Suite:
> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR3_1600-512MiB-NULL-x86_64-opt-MESI_Two_Level
>
> Starting Test Case:
> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR3_1600-512MiB-NULL-x86_64-opt-MESI_Two_Level
> Test:
> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR3_1600-512MiB-NULL-x86_64-opt-MESI_Two_Level
> Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/NULL_MESI_Two_Level/gem5.opt -d
> /tmp/gem5out254odcqw -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/traffic_gen/simple_traffic_run.py
> LinearGenerator 1 MESITwoLevel gem5.components.memory
> SingleChannelDDR3_2133 512MiB
> Starting Test Suite:
> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR3_2133-512MiB-NULL-x86_64-opt-MESI_Two_Level
>
> Starting Test Case:
> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR3_2133-512MiB-NULL-x86_64-opt-MESI_Two_Level
> Test:
> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR3_2133-512MiB-NULL-x86_64-opt-MESI_Two_Level
> Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/NULL_MESI_Two_Level/gem5.opt -d
> /tmp/gem5outhken_zl9 -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/traffic_gen/simple_traffic_run.py
> LinearGenerator 1 MESITwoLevel gem5.components.memory
> SingleChannelDDR4_2400 512MiB
> Starting Test Suite:
> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR4_2400-512MiB-NULL-x86_64-opt-MESI_Two_Level
>
> Starting Test Case:
> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR4_2400-512MiB-NULL-x86_64-opt-MESI_Two_Level
> Test:
> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR4_2400-512MiB-NULL-x86_64-opt-MESI_Two_Level
> Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/NULL_MESI_Two_Level/gem5.opt -d
> /tmp/gem5out5maaqx5u -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/traffic_gen/simple_traffic_run.py
> LinearGenerator 1 MESITwoLevel gem5.components.memory
> SingleChannelLPDDR3_1600 512MiB
> Starting Test Suite:
> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelLPDDR3_1600-512MiB-NULL-x86_64-opt-MESI_Two_Level
>
> Starting Test Case:
> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelLPDDR3_1600-512MiB-NULL-x86_64-opt-MESI_Two_Level
> Test:
> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelLPDDR3_1600-512MiB-NULL-x86_64-opt-MESI_Two_Level
> Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/NULL_MESI_Two_Level/gem5.opt -d
> /tmp/gem5out09n9ru6k -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/traffic_gen/simple_traffic_run.py
> LinearGenerator 1 MESITwoLevel gem5.components.memory SingleChannelHBM
> 512MiB
> Starting Test Suite:
> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelHBM-512MiB-NULL-x86_64-opt-MESI_Two_Level
>
> Starting Test Case:
> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelHBM-512MiB-NULL-x86_64-opt-MESI_Two_Level
> Test:
> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelHBM-512MiB-NULL-x86_64-opt-MESI_Two_Level
> Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/NULL_MESI_Two_Level/gem5.opt -d
> /tmp/gem5outkwnarmuf -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/traffic_gen/simple_traffic_run.py
> LinearGenerator 1 MESITwoLevel gem5.components.memory DualChannelDDR3_1600
> 512MiB
> Starting Test Suite:
> 

[gem5-dev] Re: All tests failing: Please don't commit anything!

[Jason Lowe-Power via gem5-dev]

Great news everyone! The tests are finally passing again. Thanks for your
patience!

As always see https://jenkins.gem5.org/ for the current testing status.

Cheers,
Jason

On Tue, Mar 8, 2022 at 3:53 PM Jason Lowe-Power  wrote:

> Hi all,
>
> Please, please, please, refrain from committing anything until we are sure
> that the current bugs are squashed! The weekly tests should finish today or
> tonight, so we can open up committing again tomorrow (if they pass).
>
> It is incredibly difficult to track down what's causing failures when new
> changes are introduced while these tests are failing. The maintainers would
> greatly appreciate your patience!
>
> Thanks,
> Jason
>
> On Mon, Mar 7, 2022 at 3:00 PM Bobby Bruce  wrote:
>
>> Pretty sure the compiler tests are fixed, but they are re-running, so
>> let's see.
>>
>> The nighty tests succeeded in the last couple of runs. Either what was
>> pushed before this submission freeze fixed the issue (I don't know exactly
>> how), or the test is flaky in some capacity. I'm letting it run again to
>> see if it triggers anything. It could have also just failed due to some
>> Jenkin's stutter.
>>
>> The weekly tests failed with a docker error, "error waiting for
>> container: EOF". I couldn't reproduce this locally. From some Googling it
>> happens when you overwhelm the docker with too much CPU or memory
>> utilization. I've never seen it happen before with these tests. I'm running
>> again to see if it triggers again (I want to know if this is now something
>> that will consistently fail or some flakiness in our tests).
>>
>> I'll wait until the weekly's finish again to see if we can unfreeze
>> submissions.
>> --
>> Dr. Bobby R. Bruce
>> Room 3050,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>>
>>
>> On Mon, Mar 7, 2022 at 8:26 AM Jason Lowe-Power via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>> >
>> > Thanks, Giacomo!
>> >
>> > Now we just have to track down the others...
>> >
>> > Jason
>> >
>> > On Mon, Mar 7, 2022 at 2:02 AM Giacomo Travaglini <
>> giacomo.travagl...@arm.com> wrote:
>> >>
>> >> Hi Jason,
>> >>
>> >>
>> >>
>> >> https://gem5-review.googlesource.com/c/public/gem5/+/57349 might fix
>> the compiler-check failure (gcc-version-7)
>> >>
>> >>
>> >>
>> >> Kind Regards
>> >>
>> >>
>> >>
>> >> Giacomo
>> >>
>> >>
>> >>
>> >> From: Jason Lowe-Power via gem5-dev 
>> >> Date: Saturday, 5 March 2022 at 17:27
>> >> To: gem5 Developer List 
>> >> Cc: Jason Lowe-Power 
>> >> Subject: [gem5-dev] All tests failing: Please don't commit anything!
>> >>
>> >> Hi gem5 developers!
>> >>
>> >>
>> >>
>> >> You may or may not have noticed that as of this morning (3/5) all of
>> the tests on our Jenkins server are failing. This includes the nightly
>> tests, weekly tests, and the compiler tests.
>> >>
>> >>
>> >>
>> >> I'd like to ask everyone to refrain from committing anything else to
>> develop until these tests are passing again. It's incredibly difficult to
>> track down the offending commit when the target is moving and new changes
>> may introduce new bugs.
>> >>
>> >>
>> >>
>> >> If you have some time to help track down these issues, we would also
>> greatly appreciate the help! You can find all of the logs from the failing
>> tests on the jenkins server: https://jenkins.gem5.org/. All of the build
>> artifacts are available for download.
>> >>
>> >>
>> >>
>> >> If you find any leads, please let us know! Given that today is a
>> Saturday, it will be Monday at the earliest that we will be able to dive in
>> ourselves.
>> >>
>> >>
>> >>
>> >> Thanks,
>> >>
>> >> Jason
>> >>
>> >> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>> >
>> > ___
>> > gem5-dev 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: All tests failing: Please don't commit anything!

[Jason Lowe-Power via gem5-dev]

Hi all,

Please, please, please, refrain from committing anything until we are sure
that the current bugs are squashed! The weekly tests should finish today or
tonight, so we can open up committing again tomorrow (if they pass).

It is incredibly difficult to track down what's causing failures when new
changes are introduced while these tests are failing. The maintainers would
greatly appreciate your patience!

Thanks,
Jason

On Mon, Mar 7, 2022 at 3:00 PM Bobby Bruce  wrote:

> Pretty sure the compiler tests are fixed, but they are re-running, so
> let's see.
>
> The nighty tests succeeded in the last couple of runs. Either what was
> pushed before this submission freeze fixed the issue (I don't know exactly
> how), or the test is flaky in some capacity. I'm letting it run again to
> see if it triggers anything. It could have also just failed due to some
> Jenkin's stutter.
>
> The weekly tests failed with a docker error, "error waiting for container:
> EOF". I couldn't reproduce this locally. From some Googling it happens when
> you overwhelm the docker with too much CPU or memory utilization. I've
> never seen it happen before with these tests. I'm running again to see if
> it triggers again (I want to know if this is now something that will
> consistently fail or some flakiness in our tests).
>
> I'll wait until the weekly's finish again to see if we can unfreeze
> submissions.
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Mon, Mar 7, 2022 at 8:26 AM Jason Lowe-Power via gem5-dev <
> gem5-dev@gem5.org> wrote:
> >
> > Thanks, Giacomo!
> >
> > Now we just have to track down the others...
> >
> > Jason
> >
> > On Mon, Mar 7, 2022 at 2:02 AM Giacomo Travaglini <
> giacomo.travagl...@arm.com> wrote:
> >>
> >> Hi Jason,
> >>
> >>
> >>
> >> https://gem5-review.googlesource.com/c/public/gem5/+/57349 might fix
> the compiler-check failure (gcc-version-7)
> >>
> >>
> >>
> >> Kind Regards
> >>
> >>
> >>
> >> Giacomo
> >>
> >>
> >>
> >> From: Jason Lowe-Power via gem5-dev 
> >> Date: Saturday, 5 March 2022 at 17:27
> >> To: gem5 Developer List 
> >> Cc: Jason Lowe-Power 
> >> Subject: [gem5-dev] All tests failing: Please don't commit anything!
> >>
> >> Hi gem5 developers!
> >>
> >>
> >>
> >> You may or may not have noticed that as of this morning (3/5) all of
> the tests on our Jenkins server are failing. This includes the nightly
> tests, weekly tests, and the compiler tests.
> >>
> >>
> >>
> >> I'd like to ask everyone to refrain from committing anything else to
> develop until these tests are passing again. It's incredibly difficult to
> track down the offending commit when the target is moving and new changes
> may introduce new bugs.
> >>
> >>
> >>
> >> If you have some time to help track down these issues, we would also
> greatly appreciate the help! You can find all of the logs from the failing
> tests on the jenkins server: https://jenkins.gem5.org/. All of the build
> artifacts are available for download.
> >>
> >>
> >>
> >> If you find any leads, please let us know! Given that today is a
> Saturday, it will be Monday at the earliest that we will be able to dive in
> ourselves.
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> >
> > ___
> > gem5-dev 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: All tests failing: Please don't commit anything!

[Jason Lowe-Power via gem5-dev]

Thanks, Giacomo!

Now we just have to track down the others...

Jason

On Mon, Mar 7, 2022 at 2:02 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:

> Hi Jason,
>
>
>
> https://gem5-review.googlesource.com/c/public/gem5/+/57349 might fix the
> compiler-check failure (gcc-version-7)
>
>
>
> Kind Regards
>
>
>
> Giacomo
>
>
>
> *From: *Jason Lowe-Power via gem5-dev 
> *Date: *Saturday, 5 March 2022 at 17:27
> *To: *gem5 Developer List 
> *Cc: *Jason Lowe-Power 
> *Subject: *[gem5-dev] All tests failing: Please don't commit anything!
>
> Hi gem5 developers!
>
>
>
> You may or may not have noticed that as of this morning (3/5) all of the
> tests on our Jenkins server are failing. This includes the nightly tests,
> weekly tests, and the compiler tests.
>
>
>
> *I'd like to ask everyone to refrain from committing anything else to
> develop* until these tests are passing again. It's incredibly difficult
> to track down the offending commit when the target is moving and new
> changes may introduce new bugs.
>
>
>
> If you have some time to help track down these issues, we would also
> greatly appreciate the help! You can find all of the logs from the failing
> tests on the jenkins server: https://jenkins.gem5.org/. All of the build
> artifacts are available for download.
>
>
>
> If you find any leads, please let us know! Given that today is a Saturday,
> it will be Monday at the earliest that we will be able to dive in ourselves.
>
>
>
> Thanks,
>
> Jason
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
___
gem5-dev 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] All tests failing: Please don't commit anything!

[Jason Lowe-Power via gem5-dev]

Hi gem5 developers!

You may or may not have noticed that as of this morning (3/5) all of the
tests on our Jenkins server are failing. This includes the nightly tests,
weekly tests, and the compiler tests.

*I'd like to ask everyone to refrain from committing anything else to
develop* until these tests are passing again. It's incredibly difficult to
track down the offending commit when the target is moving and new changes
may introduce new bugs.

If you have some time to help track down these issues, we would also
greatly appreciate the help! You can find all of the logs from the failing
tests on the jenkins server: https://jenkins.gem5.org/. All of the build
artifacts are available for download.

If you find any leads, please let us know! Given that today is a Saturday,
it will be Monday at the earliest that we will be able to dive in ourselves.

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] Re: Build failed in Jenkins: nightly #135

[Jason Lowe-Power via gem5-dev]

Hey Matt,

It looks like one of the Ruby changes you recently pushed is breaking the
nightly tests. Can you take a look?

Thanks!
Jason

On Sat, Feb 19, 2022 at 2:06 PM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/135/display/redirect?page=changes>
>
> Changes:
>
> [tiago.muck] mem-ruby: Fix handling of stale CleanUnique
>
> [matthew.poremba] mem-ruby: Ensure MOESI_AMD_Base-dir has probe
> destinations
>
> [matthew.poremba] mem-ruby: Remove DirectoryMemory storage in
> MOESI_AMD_BASE-dir
>
> [matthew.poremba] mem-ruby: Add protocol prints to MOESI_AMD_BASE-dma
>
> [matthew.poremba] cpu: Only acquire needed tokens in PTL tester
>
> [matthew.poremba] configs: Allow for no DMAs in Ruby GPU tester
>
> [tiago.muck] cpu: fix issues with ruby's memtest
>
> [mattdsinclair] gpu-compute: Set scratch_base, lds_base for gfx902
>
> [mattdsinclair] gpu-compute: Fix register checking and allocation in dyn
> manager
>
> [gabe.black] ext-testlib: Import MutableSet properly.
>
>
> --
> [...truncated 1.65 MB...]
>  [ CXX] GCN3_X86/debug/VIOBlock.cc -> .o
>  [ CXX] GCN3_X86/debug/VIO9P.cc -> .o
>  [ CXX] GCN3_X86/debug/VIO9PData.cc -> .o
>  [ CXX] GCN3_X86/python/m5/defines.py.cc -> .o
>  [ CXX] GCN3_X86/python/m5/info.py.cc -> .o
>  [   SHCXX] iostream3/zfstream.cc -> .os
>  [   SHCXX] nomali/lib/gpu.cc -> .os
>  [   SHCXX] nomali/lib/gpublock.cc -> .os
>  [   SHCXX] nomali/lib/gpucontrol.cc -> .os
>  [   SHCXX] nomali/lib/jobcontrol.cc -> .os
>  [   SHCXX] nomali/lib/jobslot.cc -> .os
>  [   SHCXX] nomali/lib/mali_midgard.cc -> .os
>  [   SHCXX] nomali/lib/mali_t6xx.cc -> .os
>  [   SHCXX] nomali/lib/mali_t7xx.cc -> .os
>  [   SHCXX] nomali/lib/addrspace.cc -> .os
>  [   SHCXX] nomali/lib/mmu.cc -> .os
>  [   SHCXX] nomali/lib/nomali_api.cc -> .os
>  [   SHCXX] drampower/src/CommandAnalysis.cc -> .os
>  [   SHCXX] drampower/src/MemArchitectureSpec.cc -> .os
>  [   SHCXX] drampower/src/MemCommand.cc -> .os
>  [   SHCXX] drampower/src/MemPowerSpec.cc -> .os
>  [   SHCXX] drampower/src/MemTimingSpec.cc -> .os
>  [   SHCXX] drampower/src/MemoryPowerModel.cc -> .os
>  [   SHCXX] drampower/src/MemorySpecification.cc -> .os
>  [   SHCXX] drampower/src/Parameter.cc -> .os
>  [   SHCXX] drampower/src/Parametrisable.cc -> .os
>  [   SHCXX] drampower/src/libdrampower/LibDRAMPower.cc -> .os
>  [   SHCXX] drampower/src/CAHelpers.cc -> .os
>  [   SHCXX] drampower/src/CmdHandlers.cc -> .os
>  [   SHCXX] drampower/src/MemBankWiseParams.cc -> .os
>  [ CXX] GCN3_X86/base/date.cc -> .o
>  [LINK]  -> GCN3_X86/gem5.opt
> 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.
> + wget -qN http://dist.gem5.org/dist/develop/test-progs/square/square
> + mkdir -p tests/testing-results
> + docker run --rm -u 118: --volume
> /nobackup/jenkins/workspace/nightly/tests/..:/nobackup/jenkins/workspace/nightly/tests/..
> -w /nobackup/jenkins/workspace/nightly/tests/..
> gcr.io/gem5-test/gcn-gpu:latest build/GCN3_X86/gem5.opt
> configs/example/apu_se.py --reg-alloc-policy=dynamic -n3 -c square
> Global frequency set at 1 ticks per second
> build/GCN3_X86/mem/mem_interface.cc:791: warn: DRAM device capacity (8192
> Mbytes) does not match the address range assigned (512 Mbytes)
> build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (5) does not
> divide range [1:75] into equal-sized buckets. Rounding up.
> build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (2) does not
> divide range [1:10] into equal-sized buckets. Rounding up.
> build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (2) does not
> divide range [1:64] into equal-sized buckets. Rounding up.
> build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does
> not divide range [1:1e+06] into equal-sized buckets. Rounding up.
> build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (5) does not
> divide range [1:75] into equal-sized buckets. Rounding up.
> build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (2) does not
> divide range [1:10] into equal-sized buckets. Rounding up.
> build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (2) does not
> divide range [1:64] into equal-sized buckets. Rounding up.
> build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does
> not divide range [1:1e+06] into equal-sized buckets. Rounding up.
> build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (5) does not
> divide range [1:75] into equal-sized buckets. Rounding up.
> build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (2) does not
> divide range [1:10] into equal-sized buckets. Rounding up.
> build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (2) does not
> divide range [1:64] into equal-sized buckets. 

[gem5-dev] Re: build configuration overhaul

[Jason Lowe-Power via gem5-dev]

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

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.

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] Re: LupIO: Friendly IO Devices for gem5 (reviews appreciated!)

[Jason Lowe-Power via gem5-dev]

Hey Boris,

Absolutely, it should be easy for this to work with POWER, Arm, etc. I
believe that Joel is actually working on Arm support (not sure about
POWER). We chose to only support RISC-V at this release since we haven't
tested others. That said, it should be mostly just SConscript changes to
compile these in when other versions of gem5 are built.

Cheers,
Jason

On Sat, Dec 18, 2021 at 12:24 PM Boris Shingarov via gem5-dev <
gem5-dev@gem5.org> wrote:

> This is very interesting especially in view of what Prof. Wu Feng said in
> this year's OpenPOWER conference about "vertically integrated" teaching:
> https://www.youtube.com/watch?v=nfOzppTBiQE
> His curriculum is also based on gem5 (although for the ISA he uses
> OpenPOWER, not RISC-V).
> I would like to hope that what we are witnessing is the start of a common
> phenomenon which will rapidly grow beyond VT and UC Davis.
>
> I don't imagine there is much RISC-V-specific stuff in this
> relation-chain, so it should be easy to make LupIO work with OpenPOWER too,
> right?
>
> -"Bobby Bruce via gem5-dev"  wrote: -
> To: "gem5 Developer List" 
> From: "Bobby Bruce via gem5-dev" 
> Date: 12/03/2021 09:43PM
> Cc: "Melissa Jost" , llhin...@ucdavis.edu, "Joël
> Porquet-Lupine" , "Bobby Bruce" 
> Subject: [gem5-dev] LupIO: Friendly IO Devices for gem5 (reviews
> appreciated!)
>
> Dear all,
>
> Here at UC Davis two undergraduate students, Melissa Jost and Laura
> Hinman, have been working on incorporating LupIO devices into gem5.
>
> For those unaware, LupIO devices were developed by Prof. Joel
> Porquet-Lupine as a set of open-source I/O devices to be used for teaching.
> They were designed to model a complete set of I/O devices that are neither
> too complex to teach in a classroom setting, or too simple to translate to
> understanding real-world devices. Our collection consists of a real-time
> clock, random number generator, terminal device, block device, system
> controller, timer device, programmable interrupt controller, as well as an
> inter-processor interrupt controller. A more detailed outline of LupIO can
> be found here:
> https://luplab.cs.ucdavis.edu/assets/lupio/wcae21-porquet-lupio-paper.pdf
> . Within gem5, these devices offer the capability to run simulations with a
> complete set of I/O devices that are both easy to understand and manipulate.
>
> Prior to Melissa and Laura's work these devices were only available for
> use with QEMU. They have worked diligently over the past term to
> incorporate these into gem5 for the RISCV ISA. They have incrementally
> added each device into gem5, and into a LupV gem5 Board (LupvBoard) which,
> when using gem5 alongside the correct device drivers in Linux, provides the
> capability of booting a RISC-V Linux system with SMP support.
>
> At present this work exists as a relation-chain in Gerrit:
> https://gem5-review.googlesource.com/c/public/gem5/+/53040. We would
> appreciate feedback on this relation-chain by those interested in this
> work. We hope we can get this chain submitted into the develop branch soon
> so it can be part of the gem5 v21.2 release.
>
> For those interested in setting up and running the LupvBoard, an example
> configuration script has been included at the top of the relation chain:
> https://gem5-review.googlesource.com/c/public/gem5/+/53046.
>
> Kind regards,
> Bobby
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
> ___
> 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: Commit message guidelines (was: LupIO: Friendly IO Devices for gem5)

[Jason Lowe-Power via gem5-dev]

Hey Boris,

Feel free to make a gerrit change request to the CONTRIBUTING.md file. We
can discuss more there.

>From my perspective, it's not a big deal to me what the conjugation of a
change request is. As long as it's clear, I'm ok with whatever. I'm also OK
with putting a preference in the CONTRIBUTING document. However, I think
it's unlikely that this will be strictly enforced, especially because we
don't have bot for it :).

Cheers,
Jason

On Sat, Dec 18, 2021 at 12:24 PM Boris Shingarov via gem5-dev <
gem5-dev@gem5.org> wrote:

> I was reading through this relation-chain and the only thing that looked
> not quite right is the inconsistent commit message style: some of these
> commits have it in indicative mood, sometimes in imperative, sometimes
> plural and sometimes singular.  Frankly this is rather distracting.  I was
> hoping that somewhere on the "Contributing" page the standard what the
> commit message should look like would be spelled out.  For example in the
> Eclipse project we say this on the "Contributing" page: "The first line
> describes the change made. It is written in the imperative mood, and should
> say what happens when the patch is applied. ..."  (
> https://github.com/eclipse-openj9/openj9/blob/master/CONTRIBUTING.md)  To
> my surprise, gem5's "Contributing" page is silent on this matter --
> although (at least on the few first pages of the commit log) all other
> commits but the ones in this relation-chain are consistent.
>
> What is the procedure for PRs to the Contributing Guide?
>
>
> -"Bobby Bruce via gem5-dev"  wrote: -
> To: "gem5 Developer List" 
> From: "Bobby Bruce via gem5-dev" 
> Date: 12/03/2021 09:43PM
> Cc: "Melissa Jost" , llhin...@ucdavis.edu, "Joël
> Porquet-Lupine" , "Bobby Bruce" 
> Subject: [gem5-dev] LupIO: Friendly IO Devices for gem5 (reviews
> appreciated!)
>
> Dear all,
>
> Here at UC Davis two undergraduate students, Melissa Jost and Laura
> Hinman, have been working on incorporating LupIO devices into gem5.
>
> For those unaware, LupIO devices were developed by Prof. Joel
> Porquet-Lupine as a set of open-source I/O devices to be used for teaching.
> They were designed to model a complete set of I/O devices that are neither
> too complex to teach in a classroom setting, or too simple to translate to
> understanding real-world devices. Our collection consists of a real-time
> clock, random number generator, terminal device, block device, system
> controller, timer device, programmable interrupt controller, as well as an
> inter-processor interrupt controller. A more detailed outline of LupIO can
> be found here:
> https://luplab.cs.ucdavis.edu/assets/lupio/wcae21-porquet-lupio-paper.pdf
> . Within gem5, these devices offer the capability to run simulations with a
> complete set of I/O devices that are both easy to understand and manipulate.
>
> Prior to Melissa and Laura's work these devices were only available for
> use with QEMU. They have worked diligently over the past term to
> incorporate these into gem5 for the RISCV ISA. They have incrementally
> added each device into gem5, and into a LupV gem5 Board (LupvBoard) which,
> when using gem5 alongside the correct device drivers in Linux, provides the
> capability of booting a RISC-V Linux system with SMP support.
>
> At present this work exists as a relation-chain in Gerrit:
> https://gem5-review.googlesource.com/c/public/gem5/+/53040. We would
> appreciate feedback on this relation-chain by those interested in this
> work. We hope we can get this chain submitted into the develop branch soon
> so it can be part of the gem5 v21.2 release.
>
> For those interested in setting up and running the LupvBoard, an example
> configuration script has been included at the top of the relation chain:
> https://gem5-review.googlesource.com/c/public/gem5/+/53046.
>
> Kind regards,
> Bobby
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
> ___
> 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: Broken SST due to python changes

[Jason Lowe-Power via gem5-dev]

Thanks, Gabe! We'll run the nightly tests and double check everything is
working as expected.

Jason

On Thu, Dec 16, 2021 at 6:49 AM Gabe Black  wrote:

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

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

[Jason Lowe-Power via gem5-dev]

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

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

[Jason Lowe-Power via gem5-dev]

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

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

[Jason Lowe-Power via gem5-dev]

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

[gem5-dev] Broken SST due to python changes

[Jason Lowe-Power via gem5-dev]

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] Re: multi-ISA gem5 proof of concept

[Jason Lowe-Power via gem5-dev]

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

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

[Jason Lowe-Power via gem5-dev]

OK! Thinking that it might be a python issue, I tried updating pybind and
the segfault goes away for me in at least some cases. However, it depends
on the different fixes that I've applied which are still on gerrit. Maybe
taken all together it works? It's hard to tell.

It worries me that we never tracked it down, but this seems like a
reasonable stop-gap. Let's try to push this in and see if that makes
Jenkins happier.

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

Cheers,
Jason

On Fri, Nov 5, 2021 at 9:03 PM Gabe Black  wrote:

> +Bobby who's fingerprints I see on the pybind stats interface, and
> +Andreas who has a lot of experience with pybind. I started digging into
> the code myself, but I got confused and stopped.
>
> I think there's some sort of reference counting bug here, where some stats
> related something is getting deleted before it's supposed to, and then
> that's getting referred to at the end of the simulation and exploding.
>
> Gabe
>
> On Fri, Nov 5, 2021 at 8:50 PM Gabe Black  wrote:
>
>> That was run on an older checkout where I had reproduced the segfault
>> before, so here is a newer one with (I think) all of the fixes so far. The
>> stats events in the valgrind log still show up.
>>
>> Gabe
>>
>> On Fri, Nov 5, 2021 at 6:39 PM Gabe Black  wrote:
>>
>>> Here is a log from a valgrind run without any suppressions. I let it run
>>> a little bit and then stopped it so it would finish fairly quickly, but
>>> that still went through the process at the end of printing stats. You can
>>> see a lot of pretty concerning output related to stats, so I think that
>>> might be a fertile area to explore.
>>>
>>> Gabe
>>>
>>> On Fri, Nov 5, 2021 at 5:58 PM Gabe Black  wrote:
>>>
 I had started to hunt these down earlier, to get rid of the warning
 messages that pop up when running the tests. It's a WIP and only in Ruby at
 the moment, so likely not applicable here.

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

 You can look at the change I'd made to the base stats to get an idea
 for how to root them out with the compiler.

 Gabe

 On Fri, Nov 5, 2021 at 5:12 PM Jason Lowe-Power 
 wrote:

> Ah, I found them (what a pain...).
>
> Here's a couple of changeset removing these legacy stats. Maybe this
> will solve the issue. I'm heading out for the day, but I'll check on it
> tomorrow morning.
>
> https://gem5-review.googlesource.com/c/public/gem5/+/52503
> https://gem5-review.googlesource.com/c/public/gem5/+/52504
>
> Cheers,
> Jason
>
> On Fri, Nov 5, 2021 at 4:55 PM Jason Lowe-Power 
> wrote:
>
>> Well, now I got the segfault in a stats++ operator (I can't tell you
>> exactly where as the templates in stats hid all of the useful 
>> information).
>> It happened ~10 cycles before the end of simulation this time.
>>
>> I am thinking it might be a "legacy" stat bug. But, again because of
>> the template magic in stats I can't find the statistic name that is
>> "legacy".
>>
>> Jason
>>
>> On Fri, Nov 5, 2021 at 4:48 PM Gabe Black 
>> wrote:
>>
>>>
>>>
>>> On Fri, Nov 5, 2021 at 11:18 AM Jason Lowe-Power <
>>> ja...@lowepower.com> wrote:
>>>
 Here's what the undefined behavior sanitizer says with these
 patches applied. Also, the backtrace from the core dump is shown.


 build/ARM_clang/base/stats/text.cc:234:13: runtime error: load of
 value 32, which is not a valid value for type 'bool'
 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
 build/ARM_clang/base/stats/text.cc:234:13 in
 gem5 has encountered a segmentation fault!

>>>
>>> I think this will fix the undefined behavior at least:
>>>
>>> https://gem5-review.googlesource.com/c/public/gem5/+/52483
>>>
>>> The fact that the segfault happens after this point says even more
>>> that this is some sort of cleanup thing, since the undefined behavior is
>>> from when it's printing stats to a text file.
>>>
>>>

 --- BEGIN LIBC BACKTRACE ---
 build/ARM_clang/gem5.opt[0x1c7684a]
 build/ARM_clang/gem5.opt[0x1cc6255]
 /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7feaafd103c0]

 /lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache21ReleaseToCentralCacheEPNS0_8FreeListEji+0x93)[0x7feaaf9b9f83]

 /lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache8ScavengeEv+0x4e)[0x7feaaf9ba2de]
 /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x2707e8)[0x7feaaff8e7e8]

 /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyState_ClearModules+0xb5)[0x7feaafead745]

 /lib/x86_64-linux-gnu/libpython3.8.so.1.0(PyImport_Cleanup+0x4f7)[0x7feaafec61c7]

 

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

[Jason Lowe-Power via gem5-dev]

Ah, I found them (what a pain...).

Here's a couple of changeset removing these legacy stats. Maybe this will
solve the issue. I'm heading out for the day, but I'll check on it tomorrow
morning.

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

Cheers,
Jason

On Fri, Nov 5, 2021 at 4:55 PM Jason Lowe-Power  wrote:

> Well, now I got the segfault in a stats++ operator (I can't tell you
> exactly where as the templates in stats hid all of the useful information).
> It happened ~10 cycles before the end of simulation this time.
>
> I am thinking it might be a "legacy" stat bug. But, again because of the
> template magic in stats I can't find the statistic name that is "legacy".
>
> Jason
>
> On Fri, Nov 5, 2021 at 4:48 PM Gabe Black  wrote:
>
>>
>>
>> On Fri, Nov 5, 2021 at 11:18 AM Jason Lowe-Power 
>> wrote:
>>
>>> Here's what the undefined behavior sanitizer says with these patches
>>> applied. Also, the backtrace from the core dump is shown.
>>>
>>>
>>> build/ARM_clang/base/stats/text.cc:234:13: runtime error: load of value
>>> 32, which is not a valid value for type 'bool'
>>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>>> build/ARM_clang/base/stats/text.cc:234:13 in
>>> gem5 has encountered a segmentation fault!
>>>
>>
>> I think this will fix the undefined behavior at least:
>>
>> https://gem5-review.googlesource.com/c/public/gem5/+/52483
>>
>> The fact that the segfault happens after this point says even more that
>> this is some sort of cleanup thing, since the undefined behavior is from
>> when it's printing stats to a text file.
>>
>>
>>>
>>> --- BEGIN LIBC BACKTRACE ---
>>> build/ARM_clang/gem5.opt[0x1c7684a]
>>> build/ARM_clang/gem5.opt[0x1cc6255]
>>> /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7feaafd103c0]
>>>
>>> /lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache21ReleaseToCentralCacheEPNS0_8FreeListEji+0x93)[0x7feaaf9b9f83]
>>>
>>> /lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache8ScavengeEv+0x4e)[0x7feaaf9ba2de]
>>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x2707e8)[0x7feaaff8e7e8]
>>>
>>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyState_ClearModules+0xb5)[0x7feaafead745]
>>>
>>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(PyImport_Cleanup+0x4f7)[0x7feaafec61c7]
>>>
>>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(Py_FinalizeEx+0x90)[0x7feaafeb1690]
>>> build/ARM_clang/gem5.opt[0x1cc8a07]
>>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7feaaf28e0b3]
>>> build/ARM_clang/gem5.opt[0x5e078e]
>>> --- END LIBC BACKTRACE ---
>>>
>>
>> Is there some sort of bookkeeping bug in the stats interaction between
>> c++ and python? This is a crash in the heap manager triggered by the python
>> interpreter doing some sort of cleanup. I can imagine this being a latent
>> bug where something was corrupted earlier and it's just falling over now,
>> but this makes sense for three reasons. First, python stats related
>> problems would likely show up at the end when the stats are printed out
>> which is done partially through python. Second, python's reference counting
>> stuff would be easy to make a mistake with since it's complicated and
>> sometimes has to be handled manually. Third, when running valgrind, I
>> suppressed errors in the python library which would hide any bad behavior
>> right before the segfault.
>>
>>
>>
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Fri, Nov 5, 2021 at 7:28 AM Gabe Black  wrote:
>>>
 Can you try this pair of changes?

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

 I think this should at least fix the undefined behavior, but when I
 tried to test it it took an hour and a half to unsuccessfully compile with
 the sanitizers for build/ARM so I gave up.

 I'm hopeful this could also fix the segfault?

 Gabe

 On Thu, Nov 4, 2021 at 4:18 PM Gabe Black  wrote:

> Oh, yes, that does look very suspicious. I'll have to take a closer
> look at that!
>
> Gabe
>
> On Thu, Nov 4, 2021 at 3:02 PM Jason Lowe-Power 
> wrote:
>
>> Glad you asked! I didn't look closely enough at the output.
>>
>> Here's an error that looks suspicious (The whole file is attached.)
>>
>> build/ARM_clang/cpu/o3/dyn_inst.hh:252:29: runtime error: constructor
>> call on misaligned address 0x1c1ed9ac for type 'gem5::PhysRegId *',
>> which requires 8 byte alignment
>> 0x1c1ed9ac: note: pointer points here
>>   00 00 00 00 00 00 00 00  50 d9 1e 1c 00 00 00 00  70 8d 20 1c 00 00
>> 00 00  40 58 1e 1c 00 00 00 00
>>   ^
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>> build/ARM_clang/cpu/o3/dyn_inst.hh:252:29 in
>> build/ARM_clang/cpu/o3/dyn_inst.hh:335:13: runtime error: store to
>> misaligned address 0x1c1ed9bc for type 'gem5::PhysRegIdPtr' (aka
>> 'gem5::PhysRegId *'), which requires 8 byte 

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

[Jason Lowe-Power via gem5-dev]

Well, now I got the segfault in a stats++ operator (I can't tell you
exactly where as the templates in stats hid all of the useful information).
It happened ~10 cycles before the end of simulation this time.

I am thinking it might be a "legacy" stat bug. But, again because of the
template magic in stats I can't find the statistic name that is "legacy".

Jason

On Fri, Nov 5, 2021 at 4:48 PM Gabe Black  wrote:

>
>
> On Fri, Nov 5, 2021 at 11:18 AM Jason Lowe-Power 
> wrote:
>
>> Here's what the undefined behavior sanitizer says with these patches
>> applied. Also, the backtrace from the core dump is shown.
>>
>>
>> build/ARM_clang/base/stats/text.cc:234:13: runtime error: load of value
>> 32, which is not a valid value for type 'bool'
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>> build/ARM_clang/base/stats/text.cc:234:13 in
>> gem5 has encountered a segmentation fault!
>>
>
> I think this will fix the undefined behavior at least:
>
> https://gem5-review.googlesource.com/c/public/gem5/+/52483
>
> The fact that the segfault happens after this point says even more that
> this is some sort of cleanup thing, since the undefined behavior is from
> when it's printing stats to a text file.
>
>
>>
>> --- BEGIN LIBC BACKTRACE ---
>> build/ARM_clang/gem5.opt[0x1c7684a]
>> build/ARM_clang/gem5.opt[0x1cc6255]
>> /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7feaafd103c0]
>>
>> /lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache21ReleaseToCentralCacheEPNS0_8FreeListEji+0x93)[0x7feaaf9b9f83]
>>
>> /lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache8ScavengeEv+0x4e)[0x7feaaf9ba2de]
>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x2707e8)[0x7feaaff8e7e8]
>>
>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyState_ClearModules+0xb5)[0x7feaafead745]
>>
>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(PyImport_Cleanup+0x4f7)[0x7feaafec61c7]
>>
>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(Py_FinalizeEx+0x90)[0x7feaafeb1690]
>> build/ARM_clang/gem5.opt[0x1cc8a07]
>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7feaaf28e0b3]
>> build/ARM_clang/gem5.opt[0x5e078e]
>> --- END LIBC BACKTRACE ---
>>
>
> Is there some sort of bookkeeping bug in the stats interaction between c++
> and python? This is a crash in the heap manager triggered by the python
> interpreter doing some sort of cleanup. I can imagine this being a latent
> bug where something was corrupted earlier and it's just falling over now,
> but this makes sense for three reasons. First, python stats related
> problems would likely show up at the end when the stats are printed out
> which is done partially through python. Second, python's reference counting
> stuff would be easy to make a mistake with since it's complicated and
> sometimes has to be handled manually. Third, when running valgrind, I
> suppressed errors in the python library which would hide any bad behavior
> right before the segfault.
>
>
>
>>
>> Cheers,
>> Jason
>>
>> On Fri, Nov 5, 2021 at 7:28 AM Gabe Black  wrote:
>>
>>> Can you try this pair of changes?
>>>
>>> https://gem5-review.googlesource.com/c/public/gem5/+/52485/1
>>>
>>> I think this should at least fix the undefined behavior, but when I
>>> tried to test it it took an hour and a half to unsuccessfully compile with
>>> the sanitizers for build/ARM so I gave up.
>>>
>>> I'm hopeful this could also fix the segfault?
>>>
>>> Gabe
>>>
>>> On Thu, Nov 4, 2021 at 4:18 PM Gabe Black  wrote:
>>>
 Oh, yes, that does look very suspicious. I'll have to take a closer
 look at that!

 Gabe

 On Thu, Nov 4, 2021 at 3:02 PM Jason Lowe-Power 
 wrote:

> Glad you asked! I didn't look closely enough at the output.
>
> Here's an error that looks suspicious (The whole file is attached.)
>
> build/ARM_clang/cpu/o3/dyn_inst.hh:252:29: runtime error: constructor
> call on misaligned address 0x1c1ed9ac for type 'gem5::PhysRegId *',
> which requires 8 byte alignment
> 0x1c1ed9ac: note: pointer points here
>   00 00 00 00 00 00 00 00  50 d9 1e 1c 00 00 00 00  70 8d 20 1c 00 00
> 00 00  40 58 1e 1c 00 00 00 00
>   ^
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
> build/ARM_clang/cpu/o3/dyn_inst.hh:252:29 in
> build/ARM_clang/cpu/o3/dyn_inst.hh:335:13: runtime error: store to
> misaligned address 0x1c1ed9bc for type 'gem5::PhysRegIdPtr' (aka
> 'gem5::PhysRegId *'), which requires 8 byte alignment
> 0x1c1ed9bc: note: pointer points here
>   70 8d 20 1c 00 00 00 00  40 58 1e 1c 00 00 00 00  1a 00 00 00 00 00
> 00 00  1a 00 00 00 00 00 00 00
>   ^
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
> build/ARM_clang/cpu/o3/dyn_inst.hh:335:13 in
> build/ARM_clang/cpu/o3/dyn_inst.hh:307:13: runtime error: store to
> misaligned address 0x1c1ed9ac for type 'gem5::PhysRegIdPtr' (aka
> 'gem5::PhysRegId *'), which requires 8 byte alignment

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

[Jason Lowe-Power via gem5-dev]

Here's what the undefined behavior sanitizer says with these patches
applied. Also, the backtrace from the core dump is shown.


build/ARM_clang/base/stats/text.cc:234:13: runtime error: load of value 32,
which is not a valid value for type 'bool'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
build/ARM_clang/base/stats/text.cc:234:13 in
gem5 has encountered a segmentation fault!

--- BEGIN LIBC BACKTRACE ---
build/ARM_clang/gem5.opt[0x1c7684a]
build/ARM_clang/gem5.opt[0x1cc6255]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7feaafd103c0]
/lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache21ReleaseToCentralCacheEPNS0_8FreeListEji+0x93)[0x7feaaf9b9f83]
/lib/x86_64-linux-gnu/libtcmalloc.so.4(_ZN8tcmalloc11ThreadCache8ScavengeEv+0x4e)[0x7feaaf9ba2de]
/lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x2707e8)[0x7feaaff8e7e8]
/lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyState_ClearModules+0xb5)[0x7feaafead745]
/lib/x86_64-linux-gnu/libpython3.8.so.1.0(PyImport_Cleanup+0x4f7)[0x7feaafec61c7]
/lib/x86_64-linux-gnu/libpython3.8.so.1.0(Py_FinalizeEx+0x90)[0x7feaafeb1690]
build/ARM_clang/gem5.opt[0x1cc8a07]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7feaaf28e0b3]
build/ARM_clang/gem5.opt[0x5e078e]
--- END LIBC BACKTRACE ---

Cheers,
Jason

On Fri, Nov 5, 2021 at 7:28 AM Gabe Black  wrote:

> Can you try this pair of changes?
>
> https://gem5-review.googlesource.com/c/public/gem5/+/52485/1
>
> I think this should at least fix the undefined behavior, but when I tried
> to test it it took an hour and a half to unsuccessfully compile with the
> sanitizers for build/ARM so I gave up.
>
> I'm hopeful this could also fix the segfault?
>
> Gabe
>
> On Thu, Nov 4, 2021 at 4:18 PM Gabe Black  wrote:
>
>> Oh, yes, that does look very suspicious. I'll have to take a closer look
>> at that!
>>
>> Gabe
>>
>> On Thu, Nov 4, 2021 at 3:02 PM Jason Lowe-Power 
>> wrote:
>>
>>> Glad you asked! I didn't look closely enough at the output.
>>>
>>> Here's an error that looks suspicious (The whole file is attached.)
>>>
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:252:29: runtime error: constructor
>>> call on misaligned address 0x1c1ed9ac for type 'gem5::PhysRegId *',
>>> which requires 8 byte alignment
>>> 0x1c1ed9ac: note: pointer points here
>>>   00 00 00 00 00 00 00 00  50 d9 1e 1c 00 00 00 00  70 8d 20 1c 00 00 00
>>> 00  40 58 1e 1c 00 00 00 00
>>>   ^
>>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:252:29 in
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:335:13: runtime error: store to
>>> misaligned address 0x1c1ed9bc for type 'gem5::PhysRegIdPtr' (aka
>>> 'gem5::PhysRegId *'), which requires 8 byte alignment
>>> 0x1c1ed9bc: note: pointer points here
>>>   70 8d 20 1c 00 00 00 00  40 58 1e 1c 00 00 00 00  1a 00 00 00 00 00 00
>>> 00  1a 00 00 00 00 00 00 00
>>>   ^
>>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:335:13 in
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:307:13: runtime error: store to
>>> misaligned address 0x1c1ed9ac for type 'gem5::PhysRegIdPtr' (aka
>>> 'gem5::PhysRegId *'), which requires 8 byte alignment
>>> 0x1c1ed9ac: note: pointer points here
>>>   00 00 00 00 00 00 00 00  50 d9 1e 1c 00 00 00 00  70 8d 20 1c 00 00 fb
>>> 1c  00 00 00 00 80 10 fb 1c
>>>   ^
>>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:307:13 in
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:322:13: runtime error: store to
>>> misaligned address 0x1c1ed9b4 for type 'gem5::PhysRegIdPtr' (aka
>>> 'gem5::PhysRegId *'), which requires 8 byte alignment
>>> 0x1c1ed9b4: note: pointer points here
>>>   00 00 00 00 00 00 00 00  70 8d 20 1c 00 00 fb 1c  00 00 00 00 80 10 fb
>>> 1c  00 00 00 00 50 0d fb 1c
>>>   ^
>>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:322:13 in
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:300:20: runtime error: load of
>>> misaligned address 0x1c1ed9ac for type 'gem5::PhysRegIdPtr' (aka
>>> 'gem5::PhysRegId *'), which requires 8 byte alignment
>>> 0x1c1ed9ac: note: pointer points here
>>>   00 00 00 00 f0 8f 01 18  00 00 00 00 c0 8c 01 18  00 00 00 00 00 00 fb
>>> 1c  00 00 00 00 80 10 fb 1c
>>>   ^
>>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:300:20 in
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:329:20: runtime error: load of
>>> misaligned address 0x1d223754 for type 'gem5::PhysRegIdPtr' (aka
>>> 'gem5::PhysRegId *'), which requires 8 byte alignment
>>> 0x1d223754: note: pointer points here
>>>   00 00 00 00 f0 8f 01 18  00 00 00 00 18 60 01 1d  00 00 00 00 78 60 01
>>> 1d  00 00 00 00 78 60 01 1d
>>>   ^
>>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>>> build/ARM_clang/cpu/o3/dyn_inst.hh:329:20 in
>>> 

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

[Jason Lowe-Power via gem5-dev]

Glad you asked! I didn't look closely enough at the output.

Here's an error that looks suspicious (The whole file is attached.)

build/ARM_clang/cpu/o3/dyn_inst.hh:252:29: runtime error: constructor call
on misaligned address 0x1c1ed9ac for type 'gem5::PhysRegId *', which
requires 8 byte alignment
0x1c1ed9ac: note: pointer points here
  00 00 00 00 00 00 00 00  50 d9 1e 1c 00 00 00 00  70 8d 20 1c 00 00 00 00
 40 58 1e 1c 00 00 00 00
  ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
build/ARM_clang/cpu/o3/dyn_inst.hh:252:29 in
build/ARM_clang/cpu/o3/dyn_inst.hh:335:13: runtime error: store to
misaligned address 0x1c1ed9bc for type 'gem5::PhysRegIdPtr' (aka
'gem5::PhysRegId *'), which requires 8 byte alignment
0x1c1ed9bc: note: pointer points here
  70 8d 20 1c 00 00 00 00  40 58 1e 1c 00 00 00 00  1a 00 00 00 00 00 00 00
 1a 00 00 00 00 00 00 00
  ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
build/ARM_clang/cpu/o3/dyn_inst.hh:335:13 in
build/ARM_clang/cpu/o3/dyn_inst.hh:307:13: runtime error: store to
misaligned address 0x1c1ed9ac for type 'gem5::PhysRegIdPtr' (aka
'gem5::PhysRegId *'), which requires 8 byte alignment
0x1c1ed9ac: note: pointer points here
  00 00 00 00 00 00 00 00  50 d9 1e 1c 00 00 00 00  70 8d 20 1c 00 00 fb 1c
 00 00 00 00 80 10 fb 1c
  ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
build/ARM_clang/cpu/o3/dyn_inst.hh:307:13 in
build/ARM_clang/cpu/o3/dyn_inst.hh:322:13: runtime error: store to
misaligned address 0x1c1ed9b4 for type 'gem5::PhysRegIdPtr' (aka
'gem5::PhysRegId *'), which requires 8 byte alignment
0x1c1ed9b4: note: pointer points here
  00 00 00 00 00 00 00 00  70 8d 20 1c 00 00 fb 1c  00 00 00 00 80 10 fb 1c
 00 00 00 00 50 0d fb 1c
  ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
build/ARM_clang/cpu/o3/dyn_inst.hh:322:13 in
build/ARM_clang/cpu/o3/dyn_inst.hh:300:20: runtime error: load of
misaligned address 0x1c1ed9ac for type 'gem5::PhysRegIdPtr' (aka
'gem5::PhysRegId *'), which requires 8 byte alignment
0x1c1ed9ac: note: pointer points here
  00 00 00 00 f0 8f 01 18  00 00 00 00 c0 8c 01 18  00 00 00 00 00 00 fb 1c
 00 00 00 00 80 10 fb 1c
  ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
build/ARM_clang/cpu/o3/dyn_inst.hh:300:20 in
build/ARM_clang/cpu/o3/dyn_inst.hh:329:20: runtime error: load of
misaligned address 0x1d223754 for type 'gem5::PhysRegIdPtr' (aka
'gem5::PhysRegId *'), which requires 8 byte alignment
0x1d223754: note: pointer points here
  00 00 00 00 f0 8f 01 18  00 00 00 00 18 60 01 1d  00 00 00 00 78 60 01 1d
 00 00 00 00 78 60 01 1d
  ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
build/ARM_clang/cpu/o3/dyn_inst.hh:329:20 in
build/ARM_clang/cpu/o3/dyn_inst.hh:315:20: runtime error: load of
misaligned address 0x1c1ecba4 for type 'gem5::PhysRegIdPtr' (aka
'gem5::PhysRegId *'), which requires 8 byte alignment
0x1c1ecba4: note: pointer points here
  00 00 00 00 f8 90 01 18  00 00 00 00 f8 90 01 18  00 00 00 00 c0 60 01 1d
 00 00 00 00 78 60 01 1d
  ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
build/ARM_clang/cpu/o3/dyn_inst.hh:315:20 in


Cheers,
Jason

On Thu, Nov 4, 2021 at 2:51 PM Gabe Black  wrote:

> Did you find anything with ASAN?
>
> Gabe
>
> On Thu, Nov 4, 2021, 12:59 PM Gabe Black  wrote:
>
>> I don't know if they do, and frankly even the unique_ptr change could
>> since that could fix heap corruption, even though it's unlikely since I
>> don't think this regression uses any of that code (except maybe VIO). We
>> don't actually *know* that that change is at fault, even though I agree
>> that it seems like a reasonable guess. This could be one of those bugs
>> where something totally unrelated is wrong, and another change just shifts
>> things around until some address lines up with something bad.
>>
>> As valgrind grinds on, I think there's a good chance of identifying
>> exactly what the problem is. I think that should happen in the next day or
>> two, hopefully.
>>
>> Gabe
>>
>> On Thu, Nov 4, 2021 at 9:55 AM Jason Lowe-Power 
>> wrote:
>>
>>> Hey Gabe,
>>>
>>> Do these fix the nightly regression? If not, we may need to back out
>>> "4fe56ff72 - (3 months ago) arch-arm,cpu: Replace rename modes with split
>>> reg/elem register files." until we have a fix.
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Thu, Nov 4, 2021 at 12:13 AM Gabe Black  wrote:
>>>
 Valgrind hasn't finished, but what it found so far is attached. I went
 through it and have the following changes which should address these
 uninitialized accesses, and an inefficiency in the cache it found by
 accident.

 https://gem5-review.googlesource.com/c/public/gem5/+/52403
 https://gem5-review.googlesource.com/c/public/gem5/+/52404
 https://gem5-review.googlesource.com/c/public/gem5/+/52405
 

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

[Jason Lowe-Power via gem5-dev]

Hey Gabe,

Do these fix the nightly regression? If not, we may need to back out
"4fe56ff72 - (3 months ago) arch-arm,cpu: Replace rename modes with split
reg/elem register files." until we have a fix.

Cheers,
Jason

On Thu, Nov 4, 2021 at 12:13 AM Gabe Black  wrote:

> Valgrind hasn't finished, but what it found so far is attached. I went
> through it and have the following changes which should address these
> uninitialized accesses, and an inefficiency in the cache it found by
> accident.
>
> https://gem5-review.googlesource.com/c/public/gem5/+/52403
> https://gem5-review.googlesource.com/c/public/gem5/+/52404
> https://gem5-review.googlesource.com/c/public/gem5/+/52405
> https://gem5-review.googlesource.com/c/public/gem5/+/52406
>
> Gabe
>
> On Wed, Nov 3, 2021 at 12:45 PM Jason Lowe-Power 
> 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  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 
 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 
> 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 
 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 <

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

[Jason Lowe-Power via gem5-dev]

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 
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] Re: Build failed in Jenkins: nightly #27

[Jason Lowe-Power via gem5-dev]

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

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

[Jason Lowe-Power via gem5-dev]

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

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

[Jason Lowe-Power 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  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 
> 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 
>>>
>>> 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 

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

[Jason Lowe-Power via gem5-dev]

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

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

[Jason Lowe-Power via gem5-dev]

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 ] LoggingFixture.BaseMessageOnce (0 ms)
>> [ RUN  ] LoggingFixture.Warn
>> [   OK ] LoggingFixture.Warn (0 ms)
>> [ RUN  ] LoggingFixture.Inform
>> [   OK ] LoggingFixture.Inform (0 ms)
>> [ RUN  ] LoggingFixture.Hack
>> [   OK ] 

[gem5-dev] Re: CPU complex wrapper

[Jason Lowe-Power via gem5-dev]

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
> 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 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 #25

[Jason Lowe-Power via gem5-dev]

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

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

[Jason Lowe-Power via gem5-dev]

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  >
>
> 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  ] AddrRangeTest.SubtractionAssignmentOfRangeListFromRangeList
> [   OK ] AddrRangeTest.SubtractionAssignmentOfRangeListFromRangeList
> (0 ms)
> [--] 74 tests from AddrRangeTest (3 ms total)
>
> [--] Global test environment tear-down
> [==] 75 tests from 2 test suites ran. (156 ms total)
> [  PASSED  ] 75 tests.
>
>   YOU HAVE 6 DISABLED TESTS
>
> build/NULL/base/condcodes.test.opt
> --gtest_output=xml:build/NULL/unittests.opt/base/condcodes.test.xml
> Running main() from build/googletest/googletest/src/gtest_main.cc
> [==] Running 10 tests from 1 test suite.
> [--] Global test environment set-up.
> [--] 10 tests from CircularQueueTest
> [ RUN  ] CircularQueueTest.Empty
> [   OK ] CircularQueueTest.Empty (0 ms)
> [ RUN  ] 

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

[Jason Lowe-Power via gem5-dev]

Looks like the failure is in the GPU tests (note: the weekly tests are also
failing due to GPU errors).

https://jenkins.gem5.org/job/nightly/10/console

On Wed, Oct 13, 2021 at 4:03 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See  >
>
> Changes:
>
> [quentin.forcioli] dev-arm: Added trusted DRAM to vexpress Realview
>
> [giacomo.travaglini] sim-se: Rewrite some syscalls to use a syscallImpl
> function
>
> [giacomo.travaglini] sim-se: Implement at suffixed syscalls
>
> [giacomo.travaglini] arch-arm: Add existing at impl to ArmLinux32 Syscall
> Table
>
> [giacomo.travaglini] sim-se: Implemnt fchownat syscall
>
> [giacomo.travaglini] arch-arm: Add fchown implementation to the Syscall
> Table
>
> [giacomo.travaglini] arch-arm: Add fchownat implementation to the Syscall
> Table
>
> [mattdsinclair] dev-hsa,gpu-compute: fix bug with gfx8 VAs for HSA Queues
>
> [mattdsinclair] tests: fix square and HeteroSync nightly regression command
>
> [giacomo.travaglini] mem-ruby: HTMSequencer stats initialized twice
>
> [gabe.black] scons: Pull the code which generates debug/flags.cc into a
> helper script.
>
> [gabe.black] scons: Rearrange functions to be next to the code that uses
> them.
>
> [Bobby R. Bruce] tests: Fix argparse description in simple_binary_run.py
>
> [mail] python: Fix L1 data cache size in cache components
>
>
> --
> [...truncated 847.41 KB...]
>  [ CXX] GCN3_X86/python/_m5/param_PciMemBar.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_PciMemUpperBar.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_PciVirtIO.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_PerfectCompressor.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_PioDevice.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_Platform.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_PoolManager.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_PowerDomain.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_PowerModel.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_PowerModelState.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_PowerState.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_ProbeListenerObject.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_Process.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_ProtocolTester.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_PyTrafficGen.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_QoSFixedPriorityPolicy.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_QoSMemCtrl.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_QoSMemSinkCtrl.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_QoSMemSinkInterface.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_QoSPolicy.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_QoSPropFairPolicy.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_QoSTurnaroundPolicy.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_QoSTurnaroundPolicyIdeal.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_QueuedPrefetcher.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RandomRP.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RangeAddrMapper.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RawDiskImage.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RedirectPath.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RegisterFile.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RegisterManager.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RepeatedQwordsCompressor.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_Root.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RubyCache.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RubyController.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RubyDirectedTester.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RubyDirectoryMemory.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RubyGPUCoalescer.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RubyHTMSequencer.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RubyNetwork.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RubyPort.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RubyPortProxy.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RubyPrefetcher.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RubySequencer.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RubySystem.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RubyTester.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RubyWireBuffer.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_SBOOEPrefetcher.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_SEWorkload.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_SHiPMemRP.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_SHiPPCRP.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_SHiPRP.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_SQC_Controller.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_STeMSPrefetcher.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_ScalarRegisterFile.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_SecondChanceRP.cc -> .o
>  [ CXX] 

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

[Jason Lowe-Power via gem5-dev]

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 
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
> 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: Page size for prefetchers

[Jason Lowe-Power via gem5-dev]

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

[Jason Lowe-Power via gem5-dev]

+1 for renaming the VirtIOMMIO to be ISA-specific.

Making packages in python is a good long-term goal, but right now, I think
it would cause more problems than it would solve.

Cheers,
Jason

On Tue, Sep 14, 2021 at 4:54 AM Gabe Black  wrote:

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

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

[Jason Lowe-Power via gem5-dev]

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

[gem5-dev] Re: Running clang-format

[Jason Lowe-Power via gem5-dev]

Hey Matt,

I forgot to include a couple of important pieces of information :).

1. There are places that we want to disable clang format. It would be
impossible to find these places in one big formatting change.
2. The big change will cause huge headaches merging. The benefits of having
a more compliant codebase are probably not worth those headaches.

To answer your question, I envision only two small things changing once
49063 is merged.

1. When a reviewer says "that doesn't match the style" the patch submitter
can run `clang-format ` and say "now it does". There will be nothing
to argue about.
2. If someone notices a file that doesn't have the right style, rather than
fixing a subset of the file, they can run `clang-format` and fix the whole
thing at once without worrying about not following the style guide
perfectly.

We would *not* enforce the style across the board automatically (at least
not for now). We can have a separate discussion on if/when to replace
style.py with clang-format. My opinion is that we should do it the same way
we run the current checker, which is we only check the lines that have
changed. But this is getting ahead of what I'm currently proposing :).

Jason


On Fri, Aug 13, 2021 at 11:13 AM Matt Sinclair  wrote:

> What does this practically mean though, Jason?  Does it mean now when
> somebody makes the next change to a file foo (after 49063 is checked in),
> that all of the formatting and spacing changes will be included in that
> patch, since it would need to be run through the checker?  Perhaps that's a
> short-term problem, but it seems to me like that will lead to some
> confusing patches where spacing is ~90% of what is being checked in.  In
> comparison, I'd rather have 49064 that makes all the spacing changes at
> once, but doesn't pollute subsequent patches.  Maybe there is a third
> option I'm not getting though?
>
> Matt
>
> On Fri, Aug 13, 2021 at 12:45 PM Jason Lowe-Power via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Hi all,
>>
>> I have an updated proposal.
>>
>> FYI: It looks like since the changes are marked as WIP they don't send
>> emails when they are updated.
>>
>> For those of you who haven't seen the changesets, you can see the
>> discussion (and some great ideas from others!) at the following links:
>>
>> Clang-format file:
>> https://gem5-review.googlesource.com/c/public/gem5/+/49063
>> The giant changeset:
>> https://gem5-review.googlesource.com/c/public/gem5/+/49064/
>>
>> New proposal:
>> ---
>>
>> Daniel had a great suggestion to apply this change "little by little" and
>> only apply one formatting rule at a time. Unfortunately, I don't think
>> clang-format supports this. However, this fact, combined with the number of
>> places where gem5's current style is underspecified got me thinking.
>>
>> Instead of applying this format for the entire repo at once, I suggest we
>> use the clang-format file as the definitive style guide for gem5. Rather
>> than humans discussing an underspecified style format, whenever anything
>> style related comes up, we can point to clang-format and say "that's the
>> way we do it." In other words, let the machine decide.
>>
>> As previously mentioned, there's lots of places where our current style
>> guide is under specified. Currently it states something like "If not
>> specified here, we use the Google style". So, the clang-format file I
>> created does the *exact same thing*.
>>
>> My goal is for the clang-format file to implement all of the differences
>> from the Google style that we have, and then it falls back on Google for
>> everything else. If you notice anywhere that this is wrong, please comment
>> on the commit.
>>
>> So, to summarize: I propose committing 49036 and dropping 49064. Then,
>> from now on, if anyone has a style comment on a file or updates the style
>> in the file, rather than having a potentially flawed human make the
>> changes, we can have a deterministic machine (clang-format, the program)
>> make the changes.
>>
>> Any objections? :)
>>
>> Cheers,
>> Jason
>>
>>
>> On Thu, Aug 5, 2021 at 4:39 PM Jason Lowe-Power 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> For fun(?), I have come up with a clang-format file that's pretty darn
>>> close to our current style.
>>>
>>> However, the problem is that most of our files don't actually meet our
>>> style guide! :'( So, running this clang-format generates an enormous
>>> changeset. Skimming through the (100,000+) changes clang-format makes a

[gem5-dev] Re: Running clang-format

[Jason Lowe-Power via gem5-dev]

Hi all,

I have an updated proposal.

FYI: It looks like since the changes are marked as WIP they don't send
emails when they are updated.

For those of you who haven't seen the changesets, you can see the
discussion (and some great ideas from others!) at the following links:

Clang-format file:
https://gem5-review.googlesource.com/c/public/gem5/+/49063
The giant changeset:
https://gem5-review.googlesource.com/c/public/gem5/+/49064/

New proposal:
---

Daniel had a great suggestion to apply this change "little by little" and
only apply one formatting rule at a time. Unfortunately, I don't think
clang-format supports this. However, this fact, combined with the number of
places where gem5's current style is underspecified got me thinking.

Instead of applying this format for the entire repo at once, I suggest we
use the clang-format file as the definitive style guide for gem5. Rather
than humans discussing an underspecified style format, whenever anything
style related comes up, we can point to clang-format and say "that's the
way we do it." In other words, let the machine decide.

As previously mentioned, there's lots of places where our current style
guide is under specified. Currently it states something like "If not
specified here, we use the Google style". So, the clang-format file I
created does the *exact same thing*.

My goal is for the clang-format file to implement all of the differences
from the Google style that we have, and then it falls back on Google for
everything else. If you notice anywhere that this is wrong, please comment
on the commit.

So, to summarize: I propose committing 49036 and dropping 49064. Then, from
now on, if anyone has a style comment on a file or updates the style in the
file, rather than having a potentially flawed human make the changes, we
can have a deterministic machine (clang-format, the program) make the
changes.

Any objections? :)

Cheers,
Jason


On Thu, Aug 5, 2021 at 4:39 PM Jason Lowe-Power  wrote:

> Hi everyone,
>
> For fun(?), I have come up with a clang-format file that's pretty darn
> close to our current style.
>
> However, the problem is that most of our files don't actually meet our
> style guide! :'( So, running this clang-format generates an enormous
> changeset. Skimming through the (100,000+) changes clang-format makes all
> of them look "correct" to me. But I didn't check them all, just a few
> spot-checks.
>
> I've put together a WIP commit as an example of what it looks like to run
> clang-format on gem5. There are a few caveats, however.
>
> 1. BitUnion really confuses clang-format for two reasons: (1) We indent
> the code inside the BitUntion macro. (2) there are no semicolons after the
> macro calls for BitUnion and EndBitUntion.
> 2. There are a few lines that go over 79 characters, but they're easy to
> manually fix (it's only 4 files).
> 3. When I ran style.py on all files in src/ there were a huge number that
> had invalid sorting of includes. In at least one case, this causes compiler
> failures when I let style.py fix it.
> 4. I'm skipping sorting includes with clang-format right now. There is a
> way to specify the blocks that we define, but I don't want to dive into
> this right now. I'll create a Jira issue so we can come back to it.
>
> Finally, I'm using the following shell script to test things. This runs
> sed to tell clang-format to ignore the BitUnion blocks, runs clang-format,
> and then undoes the sed script.
>
> If this seems like something we want to continue with, then I'll commit
> these changes and we can add clang-format to the commit hooks.
>
> Clang-format file:
> https://gem5-review.googlesource.com/c/public/gem5/+/49063
> The giant changeset:
> https://gem5-review.googlesource.com/c/public/gem5/+/49064/
>
> The script I used (don't judge my sed ability :D):
> ```
> # Make clang-format ignore bitunions
> grep -r -l BitUnion src | xargs sed -i -e '/^ *BitUnion.*(.*)/i \
> // clang-format off' -e '/^ *EndBitUnion(.*)/a; \
> // clang-format on'
>
> # undo the change to the bitunion file
> git checkout src/base/bitunion.hh
>
> # Run clang format
> find src -name "*.cc" -or -name "*.hh" -exec clang-format -style=file -i
> {} \;
>
> # Remove clang-format off in BitUnion files
> grep -r -l BitUnion src | xargs sed -i -e '/^ *\/\/ clang-format.*$/d' -e
> '/^; *$/d'
> ```
>
> Cheers,
> 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] Re: SCons SimObject() and m5.objects hierarchy

[Jason Lowe-Power via gem5-dev]

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] Running clang-format

[Jason Lowe-Power via gem5-dev]

Hi everyone,

For fun(?), I have come up with a clang-format file that's pretty darn
close to our current style.

However, the problem is that most of our files don't actually meet our
style guide! :'( So, running this clang-format generates an enormous
changeset. Skimming through the (100,000+) changes clang-format makes all
of them look "correct" to me. But I didn't check them all, just a few
spot-checks.

I've put together a WIP commit as an example of what it looks like to run
clang-format on gem5. There are a few caveats, however.

1. BitUnion really confuses clang-format for two reasons: (1) We indent the
code inside the BitUntion macro. (2) there are no semicolons after the
macro calls for BitUnion and EndBitUntion.
2. There are a few lines that go over 79 characters, but they're easy to
manually fix (it's only 4 files).
3. When I ran style.py on all files in src/ there were a huge number that
had invalid sorting of includes. In at least one case, this causes compiler
failures when I let style.py fix it.
4. I'm skipping sorting includes with clang-format right now. There is a
way to specify the blocks that we define, but I don't want to dive into
this right now. I'll create a Jira issue so we can come back to it.

Finally, I'm using the following shell script to test things. This runs sed
to tell clang-format to ignore the BitUnion blocks, runs clang-format, and
then undoes the sed script.

If this seems like something we want to continue with, then I'll commit
these changes and we can add clang-format to the commit hooks.

Clang-format file:
https://gem5-review.googlesource.com/c/public/gem5/+/49063
The giant changeset:
https://gem5-review.googlesource.com/c/public/gem5/+/49064/

The script I used (don't judge my sed ability :D):
```
# Make clang-format ignore bitunions
grep -r -l BitUnion src | xargs sed -i -e '/^ *BitUnion.*(.*)/i \
// clang-format off' -e '/^ *EndBitUnion(.*)/a; \
// clang-format on'

# undo the change to the bitunion file
git checkout src/base/bitunion.hh

# Run clang format
find src -name "*.cc" -or -name "*.hh" -exec clang-format -style=file -i {}
\;

# Remove clang-format off in BitUnion files
grep -r -l BitUnion src | xargs sed -i -e '/^ *\/\/ clang-format.*$/d' -e
'/^; *$/d'
```

Cheers,
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] Re: python versions used by SCons and gem5

[Jason Lowe-Power via gem5-dev]

For MyPy that won't help.. the problem is that it looks for
_m5/objects/.py *file* which doesn't exist on disk... we have to
somehow convince it to look in the marshalled data. I was playing around
with this, but I haven't figured it out yet.

BTW, your suggested changes get a +1 from me.

Cheers,
Jason

On Thu, Aug 5, 2021 at 4:00 PM Gabe Black via gem5-dev 
wrote:

>
>
> 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 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 #145

[Jason Lowe-Power via gem5-dev]

Looks like GCN is failing with clang-11. Could someone take a look? Bobby
is on vacation this week.

Cheers,
Jason

On Mon, Aug 2, 2021 at 12:07 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/compiler-checks/145/display/redirect?page=changes
> >
>
> Changes:
>
> [gabe.black] dev: Fix style in i8254xGBe_defs.hh.
>
> [gabe.black] dev: Fix style in pktfifo.hh.
>
> [gabe.black] dev: Fix style in i8254xGBE.cc.
>
>
> --
> Started by timer
> Running as SYSTEM
> Building in workspace 
> Selected Git installation does not exist. Using Default
> 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 e24db5deddeed1a30c0a635b271b4d364a54c44d
> (refs/remotes/origin/develop)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f e24db5deddeed1a30c0a635b271b4d364a54c44d # timeout=10
> Commit message: "dev: Fix style in i8254xGBE.cc."
>  > git rev-list --no-walk 2cde260198b395177040b48b81fe14615aeaae8c #
> timeout=10
> [compiler-checks] $ /bin/sh -xe /tmp/jenkins5372034535609594944.sh
> + ./tests/compiler-tests.sh -j 12
> Starting build tests with 'gcc-version-10'...
> 'gcc-version-10' was found in the comprehensive tests. All ISAs will be
> built.
>   * Building target 'ARM_MESI_Three_Level.opt' with 'gcc-version-10'...
> Done.
>   * Building target 'ARM_MESI_Three_Level.fast' with 'gcc-version-10'...
> Done.
>   * Building target 'SPARC.opt' with 'gcc-version-10'...
> Done.
>   * Building target 'SPARC.fast' with 'gcc-version-10'...
> Done.
>   * Building target 'NULL_MOESI_CMP_token.opt' with 'gcc-version-10'...
> Done.
>   * Building target 'NULL_MOESI_CMP_token.fast' with 'gcc-version-10'...
> Done.
>   * Building target 'ARM_MOESI_hammer.opt' with 'gcc-version-10'...
> Done.
>   * Building target 'ARM_MOESI_hammer.fast' with 'gcc-version-10'...
> Done.
>   * Building target 'POWER.opt' with 'gcc-version-10'...
> Done.
>   * Building target 'POWER.fast' with 'gcc-version-10'...
> Done.
>   * Building target 'ARM_MESI_Three_Level_HTM.opt' with 'gcc-version-10'...
> Done.
>   * Building target 'ARM_MESI_Three_Level_HTM.fast' with
> 'gcc-version-10'...
> Done.
>   * Building target 'NULL_MESI_Two_Level.opt' with 'gcc-version-10'...
> Done.
>   * Building target 'NULL_MESI_Two_Level.fast' with 'gcc-version-10'...
> Done.
>   * Building target 'X86.opt' with 'gcc-version-10'...
> Done.
>   * Building target 'X86.fast' with 'gcc-version-10'...
> Done.
>   * Building target 'NULL.opt' with 'gcc-version-10'...
> Done.
>   * Building target 'NULL.fast' with 'gcc-version-10'...
> Done.
>   * Building target 'Garnet_standalone.opt' with 'gcc-version-10'...
> Done.
>   * Building target 'Garnet_standalone.fast' with 'gcc-version-10'...
> Done.
>   * Building target 'RISCV.opt' with 'gcc-version-10'...
> Done.
>   * Building target 'RISCV.fast' with 'gcc-version-10'...
> Done.
>   * Building target 'NULL_MOESI_CMP_directory.opt' with 'gcc-version-10'...
> Done.
>   * Building target 'NULL_MOESI_CMP_directory.fast' with
> 'gcc-version-10'...
> Done.
>   * Building target 'X86_MESI_Two_Level.opt' with 'gcc-version-10'...
> Done.
>   * Building target 'X86_MESI_Two_Level.fast' with 'gcc-version-10'...
> Done.
>   * Building target 'X86_MOESI_AMD_Base.opt' with 'gcc-version-10'...
> Done.
>   * Building target 'X86_MOESI_AMD_Base.fast' with 'gcc-version-10'...
> Done.
>   * Building target 'NULL_MOESI_hammer.opt' with 'gcc-version-10'...
> Done.
>   * Building target 'NULL_MOESI_hammer.fast' with 'gcc-version-10'...
> Done.
>   * Building target 'GCN3_X86.opt' with 'gcc-version-10'...
> Done.
>   * Building target 'GCN3_X86.fast' with 'gcc-version-10'...
> Done.
>   * Building target 'ARM.opt' with 'gcc-version-10'...
> Done.
>   * Building target 'ARM.fast' with 'gcc-version-10'...
> Done.
>   * Building target 'MIPS.opt' with 'gcc-version-10'...
> Done.
>   * Building target 'MIPS.fast' with 'gcc-version-10'...
> Done.
> Starting build tests with 'gcc-version-9'...
>   * Building target 'SPARC.opt' with 'gcc-version-9'...
> Done.
>   * Building target 'SPARC.fast' with 'gcc-version-9'...
> Done.
> 

[gem5-dev] Re: build configuration management

[Jason Lowe-Power via gem5-dev]

Hey Gabe,

I strongly agree that the way we configure gem5 is confusing and needs to
be improved. I also like the idea of a menuconfig-like system for doing it.
However, it seems to go against the other project you're working on.
Namely, to make a single gem5 binary with all of the ISAs, etc. compiled
in. If we could have a single build of gem5, I think that would be much
better than a complex build system.

Relatedly, I think that working towards making gem5 more modular (e.g.,
Daniel's work to decouple the SimObjects for the last release) would be one
of the most impactful changes to gem5. If we could build separate (shared?)
libraries for each of the components (e.g., O3CPU, X86ISA, etc.) and then
just discover which components are available at runtime, I think this would
solve a huge number of our biggest pain points.

Cheers,
Jason

On Wed, Jul 28, 2021 at 8:34 PM Gabe Black via gem5-dev 
wrote:

> (Sorry if this already went through. I accidentally sent it from a
> different account the first time, and I think it got silently rejected by
> the mailing list, or at least I couldn't find it in my email.)
>
>
>
> Hey folks. I've been thinking about how build configuration is handled
> right now. Mostly this is done using files in build_opts (selected by the
> name of the build subdirectory), and setting variables on the SCons command
> line.
>
> This can be a bit tricky because there are variables which have sticky
> values, variables which come from the environment, etc, and it's not always
> clear what they are, what they do, what value they have, why, what values
> they could have instead, etc.
>
> One feature we have now which helps, is that if you print out the help
> message, our script will also dump all the config values. This is good, but
> it's a little hidden, and is a big wall of text which can be confusing or
> overwhelming itself.
>
> What I would like to do is to add some sort of explicit configuration
> step/mechanism (think something like make config for the linux kernel)
> which would let you browse around the config options, give them help text,
> etc, and let you manage them in a more friendly environment than passing
> them on the command line.
>
> This would also provide a lot cleaner mechanism for updating variant
> specific variables. For instance, if you want to update the CPU list for
> just x86, you'd need to do something like scons CPU_MODELS=
> build/X86/gem5.opt. You would have to update the setting as part of a
> build, and the build would have to specifically be part of build/X86, even
> if you didn't want to build now, or wanted to build something else, like
> maybe gem5.opt for all the arches.
>
> The downside to making the configuration mechanism more powerful is that
> people will probably take advantage of that, and the number of ways gem5
> could be built will go way up (again, think make config for the linux
> kernel). On the plus side, this will make a mechanism like letting people
> turn on/off individual models, build parts of gem5 as modules, etc, *way*
> more user friendly than having 10,000 USE_BLAH_BLAH flags on the command
> line.
>
> Obviously there are many steps between here and there and I don't expect
> to get there in one huge leap. Given that, what do people think of this as
> far as a general direction?
>
> 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 namespace

[Jason Lowe-Power via gem5-dev]

Thanks, Daniel! We'll put this toward the top of the priority list and be
sure to get it in for the release.

Cheers,
Jason

On Sun, Jun 27, 2021 at 7:58 PM Daniel Carvalho via gem5-dev <
gem5-dev@gem5.org> wrote:

> Dear all,
>
> We have already renamed most of the existing namespaces to snake case.
> Before moving on to the last ones, which may generate more conflicts, I
> have encapsulated most of gem5 in a gem5 namespace. This will ensure that
> these last - and possibly most likely to generate conflicts - renames
> generate less issues. The respective chain can be found in
> https://gem5-review.googlesource.com/c/public/gem5/+/46323/4 .
>
> The approach taken to implement the gem5 namespace was not ideal, since it
> is a huge dump on the whole project instead of a per-dir approach; however,
> it was a trade-off between number of rebasing conflicts that I would have
> to deal with, and the time I had available for this project. To make it at
> least a bit reviewable, I have split it into sub-patches with common
> approaches. These patches will be squashed as soon as they are approved.
>
> Finally, every time I do a git push, many conflicts pop up. This requires
> a lot of effort to support, and processing power to recompile everything
> and make sure everything still works (I don't currently have the latter).
> Also, the next version is on the corner, and it would be great to deliver
> the gem5 namespace with it. Therefore, I would like to get these changes in
> ASAP. When problems show up - and they will - they can be more easily
> fixed, since this change is trivial - one will most likely just need to add
> a "namespace gem5 {" to a specific file that is compiled in a specific
> simulation configuration.
>
> *tl;dr*: Could you review the namespace patches so that we can try to get
> them in for the next version?
>
> Regards,
> Daniel
> Em sexta-feira, 7 de maio de 2021 02:30:13 BRT, Gabe Black via gem5-dev <
> gem5-dev@gem5.org> escreveu:
>
>
> Be warned though, that there are some pitfalls with this namespace
> deprecation approach. The namespaces here are not actually equivalent, and
> so the old deprecated namespace can have things added to it that won't show
> up in the new one. This is probably not that big a deal in practice, and
> should be pretty useful letting people know what's going on, but it's still
> important to be aware of limitations.
>
> Gabe
>
> On Thu, May 6, 2021 at 7:36 AM Jason Lowe-Power via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
> Thanks for putting this all together, Daniel!
>
> IMO, we should do our best with providing deprecation notices, but not
> bend over backwards. For things that are easy to add deprecations to (e.g.,
> function names / class names) we should do it, and for things that have a
> big impact on our users we should provide the warnings. However, if it's
> very difficult to provide the notice *and* if it's for something that is
> unlikely to affect users, then the deprecation warnings are less important.
>
> Example: if we change `panic` to `gem5_panic` (or `GEM5_PANIC`?) we
> definitely need a deprecation warning. This will significantly impact
> users. If, on the other hand, we change a macro that is used in exactly one
> place, it's probably less important
>
> Thanks for coming up with a way to do namespaces! This will be useful.
>
> Cheers,
> Jason
>
> On Thu, May 6, 2021 at 7:06 AM Daniel Carvalho via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
> Glad to see that we are reaching a consensus! Then we will create the
> "gem5" namespace, rename (most) macros to use a "GEM5_" prefix, and will
> rename all namespaces to snake case.
>
>
> I agree that we should do the renaming on a case-by-case basis. I've
> created a new Jira Epic to cover converting all namespaces to snake case:
> https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-974 .
>
>
> Regarding deprecating namespaces, aliases cannot be assigned attributes
> (thus they cannot be marked as deprecated), but I believe this will do the
> trick:
>
>
> #define GEM5_DEPRECATE_NAMESPACE(old_namespace, new_namespace) \
> namespace [[gnu::deprecated("Please use the new namespace: '" \
> #new_namespace "'")]] old_namespace { \
> using namespace new_namespace; \
> }
>
>
> Example:
>
>
> // Suppose we want to rename a namespace from Test to test
> namespace test {
> int var;
> }
> // This can be added to the base file (i.e., the one we know everybody
> will include)
> GEM5_DEPRECATE_NAMESPACE(Test, test)
>
> ...
>
> // In code, som

[gem5-dev] Re: RFC: run python Black on gem5 python code

[Jason Lowe-Power via gem5-dev]

at the point
> of automatically changing their code
> without having them noticing it.
>
> I understand you want developers to commit without the hassle of
> explicitly dealing with style errors.
> On the other hand though we are already doing this for C++ so I don't see
> a reason why we shouldn't do the same
> for the python world.
>
> Other options could be to run the linter as a pre-push hook, or to run the
> linter as part of our presubmit Jenkins script.
>
> > On Thu, Mar 4, 2021 at 6:49 AM Giacomo Travaglini via gem5-dev  > d...@gem5.org <mailto:gem5-dev@gem5.org> > wrote:
> >
> >
> > Hi Jason,
> >
> > This is great news. When you say it is not configurable, do you mean it
> > is not possible to suppress warning/errors or do you
> > mean it is not possible to come up with custom rules?
> >
> >
> >
> > There is a way to suppress changes by modifying the file with a comment
> `#
> > fmt: off`. You can also exclude files with a dotfile (like .gitignore).
> >
> >
> >
> > As I presume it's the first case, I am wondering if a different linter
> > might provide such capabilities:
> >
> > https://books.agiliq.com/projects/essential-python-
> > tools/en/latest/linters.html
> >
> > Is there a reason to prefer black over other linters?
> >
> >
> >
> > It's owned by the python software foundation, which makes it seem
> "official".
> > Though the real reason is that it's the first one I looked at and the
> only one I
> > investigated.
>
> I actually thought pycodestyle was the "official" linter (I am not sure if
> the "official" word makes completely sense though)
>
> I was asking this because for example in pycodestyle (and prob other
> linters as well) there are error codes
> https://pycodestyle.pycqa.org/en/latest/intro.html#error-codes you could
> use include or exclude lists of errors (to ignore specific types of
> warnings).
>
> Kind regards
>
> Giacomo
>
> >
> >
> >
> > Kind regards
> >
> > Giacomo
> >
> > > -Original Message-
> > > From: Gabe Black via gem5-dev  > <mailto:gem5-dev@gem5.org> >
> > > Sent: 04 March 2021 03:59
> > > To: gem5 Developer List mailto:gem5-
> > d...@gem5.org> >
> > > Cc: Gabe Black  > <mailto:gabe.bl...@gmail.com> >
> > > Subject: [gem5-dev] Re: RFC: run python Black on gem5 python code
> > >
> > > I'm a little worried about the no exceptions part of that, since we
> > might have
> > > some weird restrictions that we have to do weird things to work
> > around, but I
> > > can't really think of an example of that off hand. I'd want to look at
> it
> > to see
> > > how much wiggle room there is in the style, since I think ironclad
> > rules which
> > > make no accommodation for occasional common sense are maybe
> > more
> > > trouble than they're worth. I'm not opposed to having at least some
> > stated
> > > standard for python though, and the "official" one seems like a
> > pretty
> > > reasonable choice. I guess it's fine with me, up until it causes me
> > some sort of
> > > problem :-)
> >
> >
> >
> > I actually think it's a feature not a bug. With an "uncompromising
> Python code
> > formatter" there can be no arguments in code review about the style.
> >
> >
> > >
> > > Maybe the right thing to do would be to give it a shot but not make
> > it
> > > compulsory until we have a feeling for how much trouble it is.
> > >
> > >
> > > Gabe
> > >
> > > On Wed, Mar 3, 2021 at 11:24 AM Bobby Bruce via gem5-dev  > > d...@gem5.org <mailto:d...@gem5.org>  <mailto:gem5-
> > d...@gem5.org <mailto:gem5-dev@gem5.org> > > wrote:
> > >
> > >
> > > Sounds like a good idea to me.
> > > ---
> > >
> > > Dr. Bobby R. Bruce
> > > Room 2235,
> > > Kemper Hall, UC Davis
> > > Davis,
> > > CA, 95616
> > >
> > >
> > > web: https://www.bobbybruce.net
> > >
> > >
> > >
> > > On Wed, Mar 3, 2021 at 10:11 AM Daniel Carvalho via gem5-dev
> > > mailto:gem5-dev@gem5.org>
> > <mailto:gem5-dev@gem5.org <mailto:gem5-dev@gem5.org> > > wrote:
> > >
> > >
> > > +1
> > >
> > >
> > > Em quarta-feira, 3 de março de 2021 14:35:57 BRT

[gem5-dev] Re: Kokoro bit

[Jason Lowe-Power via gem5-dev]

Hey Boris,

Sorry about that. Gabe is on vacation for a few weeks, which is why no one
noticed :). Feel free to add me or Bobby on changes that just need a
maintainer +1.

If there are others that need a maintainer, please let us know.

Cheers,
Jason

On Thu, Jun 24, 2021 at 6:32 AM Boris Shingarov via gem5-dev <
gem5-dev@gem5.org> wrote:

> Gabe,
>
> Following the discussion in
> https://gem5-review.googlesource.com/c/public/gem5/+/40883
>
> >>> You and I did discuss this in 37295, where you explained that the
> >>> maintainer-bit and running-of-regressions is separate on purpose, as
> >>> "using kokoro resources is subject to abuse, the ability to set that
> >>> bit is given to a fairly small number of people".
>
> >> Yes, but since you are a maintainer you have a level of trust greater
> >> than a random anonymous person that just signed up for a gerrit
> >> account :-). I can set that bit now if you can't, but we should look
> >> into making it so you can.
>
> > Thia probably makes sense as there is lots of work ahead on POWER.
> > I'll merge and close 40883 now, therefore we should move this
> > discussion to email or something.
>
> I think it's about time to start being active about it, this is creating
> unneeded load on you and getting in the way of work.  For example
> https://gem5-review.googlesource.com/c/public/gem5/+/40896
> is still sitting static since I reviewed it on June 3.
>
> I tried reading various pieces on Gerrit to try and understand what's
> going on, but because I am not any kind of admin there is really not
> much that's visible to me (especially in the area of interfacing to
> kokoro).  I am not sure who the correct person to talk to is -- maybe
> Jason?
>
> Best,
> Boris
> ___
> 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: test breakage for GCN3 on ToT?

[Jason Lowe-Power via gem5-dev]

We shouldn't remove that test! It's a important feature that people rely on.

The solution would be to run the test within a "known" environment. The
docker containers we provide should work perfectly for that.

Cheers,
Jason

On Mon, May 24, 2021 at 11:54 AM Bobby Bruce via gem5-dev 
wrote:

> Hey Gabe,
>
> When you say the 'hello' binary is dynamically linked, we're talking about
> the 'hello64-dynamic' binary? I agree these tests should probably be
> removed. (Does anyone have any objection to this?)
>
> This only appears to be half your problem though, as you've got
> "MatchStdoutNoPerf" tests failing also. Did you ever figure out why these
> tests are failing for you? These tests fail when the STDOUT of the test has
> changed (each test has a "ref" file somewhere recording what the output
> should be. It's more or less a simple diff).
>
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Sat, May 22, 2021 at 4:17 AM Gabe Black via gem5-dev 
> wrote:
> >
> > Well, I think I figured out the problem. The GCN3 hello world executable
> is dynamically linked, and I'm assuming it's pulling in libraries from my
> system. That seems to use a system call that's not implemented, see below.
> These tests should *not* be dependent on the host system to work correctly!
> I will not be able to run regressions on my machine until this is fixed...
> >
> > $ cat
> ./testing-results/SuiteUID:test-hello64-dynamic-DerivO3CPU-GCN3_X86-x86_64-opt/TestUID:test-hello64-dynami
> > c-DerivO3CPU-GCN3_X86-x86_64-opt/simerr
> > 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`
> > build/GCN3_X86/mem/mem_interface.cc:785: warn: DRAM device capacity
> (8192 Mbytes) does not match the address range assigned (512 Mb
> > ytes)
> > 0: system.remote_gdb: listening for remote gdb on port 7001
> > build/GCN3_X86/sim/simulate.cc:104: info: Entering event queue @ 0.
> Starting simulation...
> > build/GCN3_X86/arch/x86/cpuid.cc:177: warn: x86 cpuid family 0x:
> unimplemented function 13
> > build/GCN3_X86/sim/syscall_emul.cc:70: warn: ignoring syscall access(...)
> > build/GCN3_X86/sim/mem_state.cc:440: info: Increasing stack size by one
> page.
> > build/GCN3_X86/sim/syscall_emul.cc:63: fatal: syscall newfstatat (#262)
> unimplemented.
> > Memory Usage: 653788 KBytes
> >
> > On Sat, May 22, 2021 at 3:35 AM Gabe Black  wrote:
> >>
> >> Even that failed... Maybe something ended up damaged in one of the
> docker images? I don't think those are used, but I'm not sure what else it
> could be... I'll have docker clear all those and try again.
> >>
> >> Gabe
> >>
> >> On Sat, May 22, 2021 at 3:17 AM Gabe Black 
> wrote:
> >>>
> >>> Hmm, I thought this might be that something was stale, but I did a
> fresh checkout and the same tests fail at ToT there too. I'm trying on a
> much older checkout since hopefully I'll be able to get back to a point
> where the tests pass... If not, then there's something screwy about my
> setup, although I'm at a loss to say what.
> >>>
> >>> Gabe
> >>>
> >>> On Sat, May 22, 2021 at 12:51 AM Gabe Black 
> wrote:
> 
>  This isn't a build issue, this is failing tests (see below). It's
> hard to extract more information than that from the test runs, so I can't
> say much more. It could be something got messed up in my local environment
> somehow? I'm still trying to find a revision that works, but there may be
> something stale in my build directory which is causing problems which I'm
> trying to clear out.
> 
>  Gabe
> 
>  Test: test-hello64-static-TimingSimpleCPU-GCN3_X86-x86_64-opt Passed
>  Test:
> test-hello64-static-TimingSimpleCPU-GCN3_X86-x86_64-opt-MatchStdoutNoPerf
> Failed
>  Redirecting stdout to /tmp/gem5outijxfv1tq/simout
>  Redirecting stderr to /tmp/gem5outijxfv1tq/simerr
>  Test: test-hello64-static-AtomicSimpleCPU-GCN3_X86-x86_64-opt Passed
>  Test:
> test-hello64-static-AtomicSimpleCPU-GCN3_X86-x86_64-opt-MatchStdoutNoPerf
> Failed
>  Redirecting stdout to /tmp/gem5outeg1h1b3e/simout
>  Redirecting stderr to /tmp/gem5outeg1h1b3e/simerr
>  Test: test-hello64-static-DerivO3CPU-GCN3_X86-x86_64-opt Passed
>  Test:
> test-hello64-static-DerivO3CPU-GCN3_X86-x86_64-opt-MatchStdoutNoPerf Failed
>  Redirecting stdout to /tmp/gem5outfcqm4wyl/simout
>  Redirecting stderr to /tmp/gem5outfcqm4wyl/simerr

[gem5-dev] Re: software floating point library(s)

[Jason Lowe-Power via gem5-dev]

I think we can use softfloat for everything now. Years ago, softfloat
wasn't BSD. So, we somewhat rolled our own to get the Arm instructions
working, but it wasn't comprehensive. Since softfloat was added in the past
few months, no one has yet migrated the old code. As far as I know, this
would be a safe thing to do.

Cheers,
Jason

On Fri, May 14, 2021 at 4:15 AM Gabe Black via gem5-dev 
wrote:

> Hi folks. I've taken a little time recently to go macro hunting, and while
> doing that I noticed what I think are three different software floating
> point implementations in gem5. There is ext/fputils which has support for
> 80 bit floats, arch/arm/insts/fplib.hh and .cc which I'm assuming ARM uses,
> and ext/softfloat which RISCV uses.
>
> I can't think of a good reason for us to need three different solutions to
> the same problem. Is there a good reason for this, or was each just not
> aware of the others? Can we fold one (or two) of these into a preferred
> implementation and get rid of the extra(s)?
>
> 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: Build failed in Jenkins: compiler-checks #72

[Jason Lowe-Power via gem5-dev]

I think the main question for (not) dropping support is the LTS for Ubuntu
and RHEL. It looks like Ubuntu 16.04 just dropped out of standard support,
so we can probably drop support for the default there, now.

https://wiki.ubuntu.com/Releases

TBH, I can't really tell what's currently supported for RHEL. I think 7 is
nearing the end of "normal" support. Someone else can try to decipher the
documentation :).

https://access.redhat.com/support/policy/updates/errata

Jason

On Thu, May 13, 2021 at 4:08 PM Gabe Black via gem5-dev 
wrote:

> If we were willing to bump clang support all the way up to version 9 (a
> big leap, released 19 September 2019) we would get support for
> __builtin_LINE and __builtin_FILE, which are there to support
> std::source_location which is a c++20 feature but which can be used without
> enabling c++20. That would be really helpful in turning macros which
> capture file/line information like panic() and warn() into normal functions.
>
> Gabe
>
> On Thu, May 13, 2021 at 3:58 PM Gabe Black  wrote:
>
>> I have no objection to moving the compiler versions up. I don't really
>> know what benchmark we use to decide when that's ok to do. If we do move
>> up, it would be nice to move to a version which would let us use c++17.
>>
>> For gcc, the oldest version with any support is 5, there seems to be
>> pretty solid support by version 7, pretty much complete compiler support by
>> 8, pretty much complete library support by 9, and it's the default version
>> by 11. If we remove support for 5 and 6, I think that might bring us into
>> position to use c++17 with 7, and I think if we move to 8 it's pretty safe.
>>
>> Version 5.2 was released on July 16, 2015
>> Version 7.3 was released on January 25, 2018
>> Version 8.1 was released on May 2, 2018
>> Version 11.1 was released very recently on  April 27, 2021.
>>
>> For clang, it seems to be a little more straightforward, and we'd just
>> need version 5. This was released on 7 September 2017.
>>
>> So, with no other data points, I'd vote for updating to gcc version 7.3
>> (or just 7+), and clang 5, and then enabling c++17.
>>
>>
>> https://en.cppreference.com/w/cpp/compiler_support/17
>> https://www.gnu.org/software/gcc/projects/cxx-status.html#cxx17
>> https://clang.llvm.org/cxx_status.html
>> https://en.wikipedia.org/wiki/Clang#Status_history
>> https://gcc.gnu.org/releases.html
>>
>> On Thu, May 13, 2021 at 1:43 PM Bobby Bruce via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> These two patchset should fix most of this:
>>> https://gem5-review.googlesource.coThism/c/public/gem5/+/45479
>>> ,
>>> https://gem5-review.googlesource.com/c/public/gem5/+/45481
>>>
>>> Unfortunately, we currently can't compile with GCC 5 as deprecation of
>>> enum values were only introduced in GCC 6. So this change is problematic:
>>> https://gem5.googlesource.com/public/gem5/+/6d7c3afcd44843fb93578d63ad1f5401906d17ad/src/sim/aux_vector.hh#100,
>>> and will continue to break the compilation tests.
>>>
>>> Perhaps this is worthy of discussion: how long do we want to continue
>>> supporting GCC 5? What's our policy here? The GCC 5 and 6 release series
>>> are no longer supported, but I wouldn't go as far to say these are old
>>> compilers completely unused in the wider world.
>>>
>>> --
>>> Dr. Bobby R. Bruce
>>> Room 3050,
>>> Kemper Hall, UC Davis
>>> Davis,
>>> CA, 95616
>>>
>>> web: https://www.bobbybruce.net
>>>
>>>
>>> On Tue, May 11, 2021 at 11:45 PM jenkins-no-reply--- via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
 See <
 https://jenkins.gem5.org/job/compiler-checks/72/display/redirect?page=changes
 >

 Changes:

 [shingarov] arch-power: Fix precedence of register operands

 [shingarov] arch-power: Add fields for DS form instructions

 [m] arch-x86: Implement ACPI root tables

 [m] arch-x86: Add ACPI support for MADT

 [m] configs: Use MADT in x86 full system simulation

 [shingarov] arch-power: Refactor load-store instructions

 [gabe.black] arch,cpu: Rename arch/registers.hh to arch/vecregs.hh.

 [gabe.black] tests: Delete the nmtest "UnitTest".

 [gabe.black] tests: Remove the stattest "UnitTest".

 [gabe.black] misc: Delete the unittest/genini.py script.

 [gabe.black] scons,tests: Delete support for the UnitTest scons
 class/function.

 [gabe.black] arch-x86: Fix x86 build.

 [gabe.black] arch-x86: Let individual reg uops specialize their
 arguments.

 [gabe.black] arch-x86: Factor out duplication in the new RegOp base
 classes.

 [gabe.black] arch-x86: Generalize the RegOp operands.

 [gabe.black] arch-x86: Use the new op bases for memory microops.

 [gabe.black] arch-x86: Remove static code from debug.isa and fix style.

 [gabe.black] arch-x86: Use the *Op classes with FP microops.

 [gabe.black] arch-x86: 

[gem5-dev] Re: gem5 namespace

[Jason Lowe-Power via gem5-dev]

Thanks for putting this all together, Daniel!

IMO, we should do our best with providing deprecation notices, but not bend
over backwards. For things that are easy to add deprecations to (e.g.,
function names / class names) we should do it, and for things that have a
big impact on our users we should provide the warnings. However, if it's
very difficult to provide the notice *and* if it's for something that is
unlikely to affect users, then the deprecation warnings are less important.

Example: if we change `panic` to `gem5_panic` (or `GEM5_PANIC`?) we
definitely need a deprecation warning. This will significantly impact
users. If, on the other hand, we change a macro that is used in exactly one
place, it's probably less important

Thanks for coming up with a way to do namespaces! This will be useful.

Cheers,
Jason

On Thu, May 6, 2021 at 7:06 AM Daniel Carvalho via gem5-dev <
gem5-dev@gem5.org> wrote:

> Glad to see that we are reaching a consensus! Then we will create the
> "gem5" namespace, rename (most) macros to use a "GEM5_" prefix, and will
> rename all namespaces to snake case.
>
>
> I agree that we should do the renaming on a case-by-case basis. I've
> created a new Jira Epic to cover converting all namespaces to snake case:
> https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-974 .
>
>
> Regarding deprecating namespaces, aliases cannot be assigned attributes
> (thus they cannot be marked as deprecated), but I believe this will do the
> trick:
>
>
> #define GEM5_DEPRECATE_NAMESPACE(old_namespace, new_namespace) \
> namespace [[gnu::deprecated("Please use the new namespace: '" \
> #new_namespace "'")]] old_namespace { \
> using namespace new_namespace; \
> }
>
>
> Example:
>
>
> // Suppose we want to rename a namespace from Test to test
> namespace test {
> int var;
> }
> // This can be added to the base file (i.e., the one we know everybody
> will include)
> GEM5_DEPRECATE_NAMESPACE(Test, test)
>
> ...
>
> // In code, somewhere:
> test::var = 2; // Does not show deprecation warning
> Test::var = 2; // Shows deprecation warning
>
>
> Cheers,
>
> Daniel
> Em quarta-feira, 5 de maio de 2021 23:28:31 BRT, Gabe Black via gem5-dev <
> gem5-dev@gem5.org> escreveu:
>
>
> Yeah, we don't have a ton of namespaces already, but having two copies of
> all of them for a while might be messy. I also don't think you can really
> mark a namespace as deprecated without even more macro trickery.
>
> Using snake case for the namespaces would be a change to acclimate to and
> I'm not *excited* to make a big change like that, especially to something
> I'm so used to, but importantly it would maintain consistency which is
> arguably more important. It would bring us in line with namespaces like
> "std" too, which, given how common it is, wouldn't be the worst thing.
>
> We would have to be careful that short, simple namespace names like
> "loader" don't conflict with existing local variable names. Given the
> potential for problems there and that we only have a handful of namespaces
> currently, it might make sense to convert each namespace one by one, which
> might make it easier to deal with fallout.
>
> Gabe
>
> On Wed, May 5, 2021 at 6:45 AM Giacomo Travaglini via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
> Hi all,
>
> I agree with Daniel's analysis and solution, as enforcing snake_case for
> namespaces would probably make everyone happy.
> We could in theory adopt namespace aliases for backward compatibility, to
> transition smoothly from one "convention" (PascalCase for namespaces is not
> mentioned in our coding style) to the other, but I think it will complicate
> things even further.
>
> Kind Regards
>
> Giacomo
>
> > -Original Message-
> > From: Jason Lowe-Power via gem5-dev 
> > Sent: 03 May 2021 21:27
> > To: gem5 Developer List 
> > Cc: Jason Lowe-Power 
> > Subject: [gem5-dev] Re: gem5 namespace
> >
> > Hey Daniel,
> >
> > Sorry, I didn't mean to add to the confusion :). I may have gotten my
> case
> > names confused! Also, I really appreciate the thoughtfulness and effort
> > you're putting into this conversation! I believe I agree with your email
> below.
> >
> >
> > I think that most people don't care that much (which is why we haven't
> heard
> > from many). From my experience, our users only care when they get merge
> > conflicts :D. That said, I'm not sure if "straightforward" is a way most
> of our
> > users ever feel about merge confl

[gem5-dev] Re: gem5 namespace

[Jason Lowe-Power via gem5-dev]

Hey Daniel,

Sorry, I didn't mean to add to the confusion :). I may have gotten my case
names confused! Also, I really appreciate the thoughtfulness and effort
you're putting into this conversation! I believe I agree with your email
below.

I think that most people don't care that much (which is why we haven't
heard from many). From my experience, our users only care when they get
merge conflicts :D. That said, I'm not sure if "straightforward" is a way
most of our users ever feel about merge conflicts. IMO, stability and ease
of update should be high priority. If we are going to be changing names,
etc. in a way that means external users of gem5 will have compiler errors,
we should probably provide backwards compatibility and warnings. Most of
our users are not software engineers and do not have as much experience
with git, compilers, etc. as we do.

Cheers,
Jason

On Mon, May 3, 2021 at 12:40 PM Daniel Carvalho via gem5-dev <
gem5-dev@gem5.org> wrote:

> I'm confused, Jason. I thought you were in favor of adopting snake case as
> a "general convention" (i.e., "the google way"), so by adopting snake case
> we would be adopting the "general convention", not forging our own path.
> However, if by "general convention" you mean "the convention vastly adopted
> by gem5", I don't have the exact numbers, but I'd guess it is 70% pascal,
> 30% snake case - i.e., IMHO, not a "general convention", just a preference.
> Adding "gem5" or "Gem5" would only extend this mess, not add an exception.
>
> Regarding changing the name of the variable, indeed, it is not a necessary
> step.
>
> Again, as stated before, I don't care which solution is taken. The
> important thing is to come to a decision that appeases most community
> members; however, it is hard to reach a consensus when we seem to have
> strong opinions on both sides, yet we only have 5 votes. That is why I have
> suggested officially adopting snake case namespaces: it would solve the
> "gem5 VS Gem5" problem, it is feasible to do it without having exceptions
> (at least as of now), Giacomo expressed preference towards lowercase
> namespaces, Jason suggested affinity with the google approach (snake case)
> and "gem5", Bobby prefers "gem5", and Gabe and I like consistency/patterns.
> The (huge) downside to this solution is that it would affect users, but 1)
> we'd already be affecting users anyway with the new namespace, and 2)
> solving the merge conflicts would be straightforward if the patches were
> created with that in mind.
>
> Regards,
> Daniel
> Em segunda-feira, 3 de maio de 2021 15:44:46 BRT, Jason Lowe-Power <
> ja...@lowepower.com> escreveu:
>
>
> Just a few quick replies below. Overall, I think we're being too focused
> on "standards" and not on enough on ease of use. It's not a problem if
> there are exceptions to guidance, if there's good reasons for the
> exceptions.
>
>
> On Mon, May 3, 2021 at 11:36 AM Daniel Carvalho via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
> As mentioned by Gabe in the Jira issue, some of the namespaces using snake
> declared in the codebase case are defined as parts of a standard, and thus
> cannot be modified. Realistically, this means that if we wanted to follow a
> namespace naming convention, it'd be snake case: despite having way more
> occurrences of pascal case namespaces, they are all "ours"; this means
> that, although inconvenient, it would be doable to standardize all of them.
>
>
> If we just say "all namespaces should be PascalCase. gem5, the name of
> this project, is an exception" would be OK with me.
>
>
> Would you be willing to adopt to enforce a snake case namespace naming
> convention? From the previous replies to this thread, it seems that this
> solution would appease most - if not all - participants.
>
>
> I really don't think this is too important. I would definitely prefer to
> follow the *general* conventions rather than forging our own path.
>
>
>
> For this change to take place, we need to (not necessarily sorted):
> 1) Rename the python variables named "gem5" in
> src/systemc/tlm_bridge/TlmBridge.py (or remove them - I don't remember
> finding where they are used);
>
>
> Why does this need to be done? These are class names, not namespaces.
>
>
>
> 2) Add a section to our coding style mandating snake case for namespaces;
>
> 3) Change all existing namespaces to snake case;
>
> 4) Create a verifier to enforce this convention.
>
> 5) Rename/Move elements starting with gem5X/m5X as gem5::X
>
>
> Finally, regarding macro names, we could improve the corresponding Jira
> issue by listing all current macros so that we can start applying the
> change and raise objections to particular instances.
>
> Cheers,
> Daniel
>
> ___
> 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] Re: gem5 namespace

[Jason Lowe-Power via gem5-dev]

Just a few quick replies below. Overall, I think we're being too focused on
"standards" and not on enough on ease of use. It's not a problem if there
are exceptions to guidance, if there's good reasons for the exceptions.


On Mon, May 3, 2021 at 11:36 AM Daniel Carvalho via gem5-dev <
gem5-dev@gem5.org> wrote:

> As mentioned by Gabe in the Jira issue, some of the namespaces using snake
> declared in the codebase case are defined as parts of a standard, and thus
> cannot be modified. Realistically, this means that if we wanted to follow a
> namespace naming convention, it'd be snake case: despite having way more
> occurrences of pascal case namespaces, they are all "ours"; this means
> that, although inconvenient, it would be doable to standardize all of them.
>

If we just say "all namespaces should be PascalCase. gem5, the name of this
project, is an exception" would be OK with me.


> Would you be willing to adopt to enforce a snake case namespace naming
> convention? From the previous replies to this thread, it seems that this
> solution would appease most - if not all - participants.
>

I really don't think this is too important. I would definitely prefer to
follow the *general* conventions rather than forging our own path.


>
> For this change to take place, we need to (not necessarily sorted):
> 1) Rename the python variables named "gem5" in
> src/systemc/tlm_bridge/TlmBridge.py (or remove them - I don't remember
> finding where they are used);
>

Why does this need to be done? These are class names, not namespaces.


> 2) Add a section to our coding style mandating snake case for namespaces;
>
3) Change all existing namespaces to snake case;
>
4) Create a verifier to enforce this convention.
>
5) Rename/Move elements starting with gem5X/m5X as gem5::X
>

> Finally, regarding macro names, we could improve the corresponding Jira
> issue by listing all current macros so that we can start applying the
> change and raise objections to particular instances.
>
> Cheers,
> Daniel
> ___
> 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 namespace

[Jason Lowe-Power via gem5-dev]

;> Room 2235,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>>
>>
>> On Sun, Apr 18, 2021 at 3:44 PM Daniel Carvalho via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>> Overall, there are way more uses of "gem5" than "Gem5" in the codebase,
>> and most of the instances that break the identity rule could be easily
>> fixed; however, there are cases that generate inconvenience: classes
>> starting with lowercase, and situations where gem5 is in the middle of the
>> var name (like "haveGem5Extension") make the code harder to
>> read/understand. In this sense, the uppercase version generates better
>> code.
>>
>>
>> I still favor namespace gem5 - it'd be the "external external" API, i.e.
>> we probably wouldn't be using it within src/ that much, and it would be
>> used by other simulators and within our SystemC bridge (more on that later)
>> - however, since we already have some exceptions, it wouldn't be the end
>> of the world having it start with a capital letter.
>>
>>
>> In the end, I personally do not care about which approach is taken, but
>> the decision taken must be taken as a community. Therefore, it would be
>> nice if we could have participation from other contributors to make the
>> final decision less susceptible to changes/complaints in the future.
>>
>>
>> Regarding when to use it:
>> IMHO (and not thoroughly thought out), all .cc and .hh and objects within
>> src/ should be subject to the namespace. Objects declared there are
>> declared and maintained by gem5. Because of that there would probably be
>> very few instances of namespace resolution within src/, so we should keep
>> avoiding "using namespace" and being verbose about it. Finally, we also
>> probably want to encourage users to define their objects inside the gem5
>> namespace to make it less unlikely that they will give up on uploading
>> their contributions due to the different styles, and the laziness to adapt
>> code. This means that disturbance in user code would be minimal: they would
>> simply add "namespace (G|g)em5 {" in the beginning and "} // namespace
>> (G|g)em5" at the end, instead of multiple "(G)|gem5::" instances.
>>
>>
>> Regards,
>>
>> Daniel
>> For the record, if the namespaces you found using snake_case start with
>> sc_, those are for systemc and are mandated by that standard. The one
>> exception, sc_gem5, is one I made up which is closely associated with the
>> other systemc namespaces and is named similarly to them for consistency.
>>
>> Gabe
>>
>> On Thu, Apr 15, 2021 at 1:51 AM Giacomo Travaglini <
>> giacomo.travagl...@arm.com> wrote:
>>
>> My vote goes to 1 and A as well
>>
>> My sole argument is consistency; in general I'd rather start a namespace
>> with a lowercase. So that when we have something
>> like a scope resolution we know we are dealing with a namespace and not a
>> class. But that's off-topic.
>>
>> Namespace names are anyway not covered by our coding style, so it's
>> probably worth adding an entry.
>>
>> https://www.gem5.org/documentation/general_docs/development/coding_style/
>>
>> From a quick grep I can see most of our namespaces follow the PascalCase
>> type, though there are some namespaces using snake_case convention.
>>
>> Giacomo
>>
>> > -Original Message-
>> > From: Gabe Black via gem5-dev 
>> > Sent: 15 April 2021 09:03
>> > To: gem5 Developer List 
>> > Cc: Gabe Black 
>> > Subject: [gem5-dev] Re: gem5 namespace
>> >
>> > My vote is for 1 and A.
>> >
>> > We have style rules for a reason, and that is because not following them
>> > causes technical problems like name collisions, and makes it less
>> obvious
>> > when reading code what things are and what they're doing. It's a bit
>> > hypocritical to say that we should follow style rules and completely
>> ignore
>> > the aesthetic rule when capitalizing GEM5_, but then say that the
>> aesthetic
>> > rule should win when dealing with the namespace.
>> >
>> > This is further inconsistent with the Gem5Internal namespace, the Gem5
>> > class in SCons, the Gem5Op instruction format used for ARM, and the
>> > Gem5Imm constant used for ARM semihosting. It would also cause a
>> collision
>> > with any variable called gem5, a completely legal and reasonabl

[gem5-dev] Re: ISA object and ISA specific CPU components

[Jason Lowe-Power via gem5-dev]

At a high level, I think this is a good direction. Specifically, I like the
idea of making the ISA object a singleton for the simulation, or at least a
member of the system, instead of one per CPU is great. We should probably
make it per-system in case we want to support a simulation with multiple
ISAs at some point in the future.

The TLBs should not be part of the ISA. These are just "caches" and should
be ISA-agnostic just like the caches and memories are. While they may need
to store ISA-specific data (e.g., PTEs, ASIDs, etc. are ISA-specific), the
mechanism for a TLB is not ISA-specific. There was recently some push to go
this direction, we need to finish this at some point.

Cheers,
Jason

On Tue, Apr 27, 2021 at 6:12 PM Gabe Black via gem5-dev 
wrote:

> Hi folks. I can write up a more detailed document once there has been some
> discussion about this, but I've been thinking about how the ISA object
> works, and how the various ISA specific components of a CPU (decoder, TLBs,
> interrupt object, ISA object itself) are hooked into each other.
>
> As of today, each context of execution has its own copy of the decoder,
> the TLBs, the interrupt object (the local APIC in x86, basically ISA
> specific interrupt handling logic), and the ISA object (home of MiscRegs,
> some other stuff).
>
> My initial idea behind creating the ISA object was that it could be a home
> for settings which affect the ISA itself, like what optional features were
> enabled, what specific version of the ISA was in effect, etc. It made sense
> to build that into the thing handling MiscRegs, since the value of and
> behavior of those registers.
>
> All of these objects could, at least in theory, have configuration
> parameters associated with them (size of the TLB, ISA parameters for
> supported features, etc), and are generally represented by SimObjects which
> are separately configured, and then plugged into the CPU in python.
>
> One problem with having the ISA object hold ISA specific configuration
> comes from the fact that it's set up per thread, and there isn't a
> centralized collection point for settings that should be common across
> several threads. ARM currently solves this problem by creating a custom
> System class, I believe the only one still in use in gem5 now, which holds
> those settings and then distributes them to the ISA objects (I believe?).
> This also creates a problem where there needs to be a custom System object,
> and it needs to communicate with the ISA objects and keep each other in
> sync.
>
>
> What I think might make more sense is to adjust the role of the ISA object
> a bit and expand it to be a single object which is assigned to a System. It
> could then absorb all the ISA specific properties which are now part of the
> ARM custom System class. Then, every time a ThreadContext is registered
> with the System, the ISA object would have a chance to register its own
> objects with it, including adding thread specific information like an
> interrupts object, a decoder, a local object to handle MiscReg accesses,
> etc., which could, as necessary, have ties back to the common ISA object.
>
> There would need to be a balance here between things which come from the
> ISA object and things which do need to come from each CPU in the system,
> like a way to set different TLB sizes for differently spec-ed cores for
> instance. Maybe the ISA has some settings for those objects, and it sets
> them post-facto when setting up a thread?
>
> Additionally, the new ISA regClassInfo array which describes what register
> types there are and their properties could then be common to all threads
> instead of duplicated in each ISA instance, and could be installed in the
> ThreadContext by the ISA object, instead of having to be fetched from the
> ISA object by everybody else as needed.
>
> You can probably tell that I haven't thought this out completely, but I
> wanted to throw this out there for people to see and respond to, so please
> see it and respond to 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] Re: gem5 roadmap!

[Jason Lowe-Power via gem5-dev]

Last call! Let me know if there's anything else to add. Otherwise, I'll
push this on Monday.

Cheers,
Jason

On Tue, Apr 20, 2021 at 4:00 PM Jason Lowe-Power 
wrote:

> Hi all,
>
> It's that time again to create a roadmap for the next gem5 release! I've
> put together a draft with the things that we are planning to work on here
> at UCD and a couple of other things that are on Jira.
>
> Please let the community know what you're planning on working on over the
> next couple of months. By letting the community know what you're planning
> on working on it can help us all be more productive and allow gem5 to be an
> even better tool!
>
> Feel free to reply here with a couple of sentences of what you're planning
> on doing and I'll put it in the document. Or, you can add a comment on the
> gerrit page and I'll update. You can see the draft below for some examples
> of what we're planning.
>
> Draft: https://gem5-review.googlesource.com/c/public/gem5-website/+/44705
>
> It would also be great to create Jira epics or issues for different parts
> of the project so that we can all follow what everyone is working on!
>
> Happy developing!
>
> Cheers,
> 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] Re: Gem5-GCN3 Checkpointing Support

[Jason Lowe-Power via gem5-dev]

Hi Paul,

I've included gem5-dev mailing list here. If you're not subscribed, I would
suggest sending these kinds of questions there where the gem5-gcn/AMD
developers will see things.

To answer your question, adding checkpointing should be relatively
straightforward. The main changes are exactly as you described: saving the
architectural state of the GPU threads. There are probably a few other
pieces of GPU state that need to be saved too (e.g., the control processor,
etc.). Hopefully one of the devs at AMD can reply with more details.

You'll have to add the serialize/unserialize functions, and you'll probably
have to also implement a drain() function to flush out the current
in-progress instructions. I imagine you'll at least want to finish the
in-progress wavefronts, and you may want to wait until the currently
scheduled workgroups are finished as well.

As far as Ruby goes, as long as the protocol you're using support
checkpointing, it will "just work". To support checkpointing, I believe all
the protocol needs to do is implement the flush RubyRequestMsg. I'm not
sure if VIPER supports this or not.

Finally, the only other detail is whether or not the current implementation
of SE mode fully supports checkpointing. Right now, this isn't something we
regularly test, so it's possible that there are some details that are
broken.

Hopefully the current devs at AMD will correct me where I'm wrong! Let us
know on gem5-dev if there's any questions we can answer, etc. We would
greatly appreciate this contribution!

Cheers,
Jason

On Wed, Apr 21, 2021 at 6:55 PM Tschirhart, Paul K [US] (MS) <
paul.tschirh...@ngc.com> wrote:

> Hello Professor Lowe-Power,
>
>
>
> Thank you for your helpful replies to the emails from some other members
> of my group regarding various aspects of the Gem5 simulator.
>
>
>
> I have been working with Gem5-GCN3 and I was wondering if you knew
> anything about the status of checkpointing support for that model. I saw in
> a post that adding checkpoints was something that was planned but I have
> not seen anything since.
>
>
>
> Is there a significant technical challenge involved with expanding Gem5’s
> checkpointing mechanism to support the GCN3 model or is this just a matter
> of writing the necessary serialize/unserialize functions? In other words,
> is this something that someone with experience making significant
> modifications to Gem5 might be able to tackle by implementing an approach
> that is similar to the one used in the O3 model?
>
>
>
> If the modifications should be mostly straightforward , do you know of
> anything that needs to be done besides adding the functions to
> serialize/unserialize threads in the GCN3 model? It seems like
> modifications might be required to support checkpointing for the VIPER
> protocol in Ruby but I don’t see where I need to make the changes. Am I
> missing something either in Ruby or elsewhere in the simulator?
>
>
>
> Thanks again for all of your help.
>
>
>
> Paul
>
>
>


-- 
Jason Lowe-Power (he/him/his)
Assistant Professor, Computer Science Department
University of California, Davis
3049 Kemper Hall
https://arch.cs.ucdavis.edu/
___
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 roadmap!

[Jason Lowe-Power via gem5-dev]

Hi all,

It's that time again to create a roadmap for the next gem5 release! I've
put together a draft with the things that we are planning to work on here
at UCD and a couple of other things that are on Jira.

Please let the community know what you're planning on working on over the
next couple of months. By letting the community know what you're planning
on working on it can help us all be more productive and allow gem5 to be an
even better tool!

Feel free to reply here with a couple of sentences of what you're planning
on doing and I'll put it in the document. Or, you can add a comment on the
gerrit page and I'll update. You can see the draft below for some examples
of what we're planning.

Draft: https://gem5-review.googlesource.com/c/public/gem5-website/+/44705

It would also be great to create Jira epics or issues for different parts
of the project so that we can all follow what everyone is working on!

Happy developing!

Cheers,
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] LTO causing headaches for users

[Jason Lowe-Power via gem5-dev]

Hi all,

It seems the recent change to enable LTO by default is causing more harm
than good. Especially for people debugging, it's a large overhead to wait
2-5 minutes for gem5 to link in opt mode. I even have encountered this with
a 6 core 3.5+GHz Ryzen. It's quite annoying. We've gotten at least 3
different posts on gem5-users and gem5-dev complaining about this. I think
this is a strong sign we need to change something.

I suggest *only enabling* LTO for fast builds and not for any other.

Thoughts?

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] Re: gem5 namespace

[Jason Lowe-Power via gem5-dev]

t;> > To: gem5 Developer List 
>> > Cc: Gabe Black 
>> > Subject: [gem5-dev] Re: gem5 namespace
>> >
>> > My vote is for 1 and A.
>> >
>> > We have style rules for a reason, and that is because not following them
>> > causes technical problems like name collisions, and makes it less
>> obvious
>> > when reading code what things are and what they're doing. It's a bit
>> > hypocritical to say that we should follow style rules and completely
>> ignore
>> > the aesthetic rule when capitalizing GEM5_, but then say that the
>> aesthetic
>> > rule should win when dealing with the namespace.
>> >
>> > This is further inconsistent with the Gem5Internal namespace, the Gem5
>> > class in SCons, the Gem5Op instruction format used for ARM, and the
>> > Gem5Imm constant used for ARM semihosting. It would also cause a
>> collision
>> > with any variable called gem5, a completely legal and reasonable name
>> to use,
>> > *especially* in code outside of gem5 which might be using it to refer to
>> > something related to gem5 which it is interacting with.
>> >
>> > There are no other instances where we let superficial aesthetic
>> conventions
>> > like this overrule technical considerations. We don't add _tm to the
>> end of
>> > trademarked names, we don't call AtomicSimpleCPU the atomic simple CPU
>> > since that's not a valid class name, and a hundred other examples of
>> where
>> > prose takes a back seat because this is not prose, this is a conceptual
>> machine
>> > people happen to be able to read.
>> >
>> > Our website is the place for branding and identity and marketing, our
>> code is
>> > not.
>> >
>> > Gabe
>> >
>> > On Wed, Apr 14, 2021 at 7:28 AM Jason Lowe-Power via gem5-dev > > d...@gem5.org <mailto:gem5-dev@gem5.org> > wrote:
>> >
>> >
>> > Thanks for putting this all together, Daniel!
>> >
>> > My opinion is the same as yours: option 2 and macro A.
>> >
>> > One other thing we need to do is to standardize and document when
>> > and where you need to use the gem5 namespace. For instance, do we need
>> > to update *all* headers to be in the gem5 namespace? If not, when is an
>> > object in the gem5 namespace and when it is not? What about `using
>> > namespace gem5`? Can/must all .cc files include this?
>> >
>> > Since this is a relatively big change to the coding standards which
>> > could cause significant frustration to our users, we should be sure to
>> > document and standardize *before* we make any code changes.
>> >
>> > Cheers,
>> > Jason
>> >
>> >
>> > On Wed, Apr 14, 2021 at 6:48 AM Daniel Carvalho via gem5-dev
>> > mailto:gem5-dev@gem5.org> > wrote:
>> >
>> >
>> > Hello, devs,
>> >
>> >
>> >
>> > We currently have a recurring issue, which is the lack of a
>> > gem5 namespace.
>> > This generates collision with other libraries and user code.
>> >
>> >
>> >
>> > A Jira ticket has been created to point out the issue last year:
>> >
>> >
>> > https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/G
>> > EM5-730
>> >
>> >
>> > And this topic has been brought up a few times:
>> >
>> >
>> > https://www.mail-archive.com/gem5-
>> > d...@gem5.org/msg37770.html
>> >
>> > https://gem5-
>> > review.googlesource.com/c/public/gem5/+/40878
>> >
>> > https://www.mail-archive.com/gem5-
>> > d...@gem5.org/msg36453.html
>> >
>> >
>> > Finally, there were already patches that were consequences
>> > of lack of a gem5
>> > namespace:
>> >
>> >
>> > https://gem5-
>> > review.googlesource.com/c/public/gem5/+/32175
>> >
>> > https://gem5-
>> > review.googlesource.com/c/public/gem5/+/40878
>> >
>> >
>> > A similar issue exists for macros, and an existing proposal to
>> > solve it already
>> > exists, which is to add a "GEM5_" prefix. It follows the coding
>> > style, which
>> > dictates that "preprocessor symbols (constants and macros)
>> > should be all
>> > caps with underscores":
>> >
>> >
>> >
>> > https://gem5.atlassian.net/jira/software/c/projects/GEM5/iss

[gem5-dev] Re: tutorial docs

[Jason Lowe-Power via gem5-dev]

Just a quick note, Gabe: there are a set of tests for the Learning gem5
tutorial scripts which run in the CI tests (
https://gem5.googlesource.com/public/gem5/+/refs/heads/stable/tests/gem5/learning_gem5/).
However, when people update those scripts in the gem5 source code they have
not been updating the documentation. If you have ideas on how to keep
prose-based documentation in step with the source code (other than asking
people politely to update the docs), I would love to hear it!

Mike, we'll look into the segfault. Could you point to which example is
segfaulting for you?

Cheers,
Jason



On Thu, Apr 15, 2021 at 10:52 PM Gabe Black  wrote:

> If you (or the documentation) expect things to work in a particular way,
> one thing I've seen in some technical books I've read is that the examples
> they have in the text are actually runnable, and they have a process which
> goes through and runs them to make sure they work. Alternatively (and more
> simply), you could just write unit tests which do what's in the
> documentation, and if something changes then either that will be updated or
> kokoro will reject the change. If you want something to keep working, it's
> wise to write a test for it.
>
> Gabe
>
> On Thu, Apr 15, 2021 at 1:58 PM mike upton via gem5-dev 
> wrote:
>
>>
>> I have verified that the tutorial works in its original form on 20.0.0.3
>> and in its new form on 20.1.0.5
>>
>> It segfaults on the current stable master: 21.0.0.0
>>
>>
>>
>> On Thu, Apr 15, 2021 at 8:18 AM Jason Lowe-Power 
>> wrote:
>>
>>> Hi Mike,
>>>
>>> It's a bit embarrassing how out of date our documentation is.
>>> Unfortunately, we have a really hard time finding the resources or
>>> convincing developers to update the documentation as the code changes.
>>>
>>> The canonical documentation can be found here:
>>> http://www.gem5.org/documentation/
>>> and the Learning gem5 material here:
>>> http://www.gem5.org/documentation/learning_gem5/introduction/
>>>
>>> There's definitely mistakes and things that have changed. We would
>>> greatly appreciate contributions. The code is available here:
>>> https://gem5.googlesource.com/public/gem5-website/+/refs/heads/stable/
>>> and it's reviewed the same way as regular gem5 code.
>>>
>>> Let me know if you have any questions about contributing, etc.
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Thu, Apr 15, 2021 at 8:04 AM mike upton via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
 Hi,
 do we (I) have edit permissions on the tutorial documentation?

 I tried to follow the first steps of the tutorial, and the instructions
 are out of date for the develop head. Some googling resulted in the
 solution, but for me it still does not execute correctly.

 It looks like there are Jira issues documenting the needed updates.

 I have some issue where the tutorial is segfaulting.

 Can someone else verify that the tutorial actually works?
 ___
 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: tutorial docs

[Jason Lowe-Power via gem5-dev]

Hi Mike,

It's a bit embarrassing how out of date our documentation is.
Unfortunately, we have a really hard time finding the resources or
convincing developers to update the documentation as the code changes.

The canonical documentation can be found here:
http://www.gem5.org/documentation/
and the Learning gem5 material here:
http://www.gem5.org/documentation/learning_gem5/introduction/

There's definitely mistakes and things that have changed. We would greatly
appreciate contributions. The code is available here:
https://gem5.googlesource.com/public/gem5-website/+/refs/heads/stable/ and
it's reviewed the same way as regular gem5 code.

Let me know if you have any questions about contributing, etc.

Cheers,
Jason

On Thu, Apr 15, 2021 at 8:04 AM mike upton via gem5-dev 
wrote:

> Hi,
> do we (I) have edit permissions on the tutorial documentation?
>
> I tried to follow the first steps of the tutorial, and the instructions
> are out of date for the develop head. Some googling resulted in the
> solution, but for me it still does not execute correctly.
>
> It looks like there are Jira issues documenting the needed updates.
>
> I have some issue where the tutorial is segfaulting.
>
> Can someone else verify that the tutorial actually works?
> ___
> 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 namespace

[Jason Lowe-Power via gem5-dev]

Thanks for putting this all together, Daniel!

My opinion is the same as yours: option 2 and macro A.

One other thing we need to do is to standardize and document when and where
you need to use the gem5 namespace. For instance, do we need to update
*all* headers to be in the gem5 namespace? If not, when is an object in the
gem5 namespace and when it is not? What about `using namespace gem5`?
Can/must all .cc files include this?

Since this is a relatively big change to the coding standards which could
cause significant frustration to our users, we should be sure to document
and standardize *before* we make any code changes.

Cheers,
Jason

On Wed, Apr 14, 2021 at 6:48 AM Daniel Carvalho via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hello, devs,
>
>
> We currently have a recurring issue, which is the lack of a gem5 namespace.
> This generates collision with other libraries and user code.
>
>
> A Jira ticket has been created to point out the issue last year:
>
> https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-730
>
>
> And this topic has been brought up a few times:
>
> https://www.mail-archive.com/gem5-dev@gem5.org/msg37770.html
>
> https://gem5-review.googlesource.com/c/public/gem5/+/40878
>
> https://www.mail-archive.com/gem5-dev@gem5.org/msg36453.html
>
>
> Finally, there were already patches that were consequences of lack of a
> gem5
> namespace:
>
> https://gem5-review.googlesource.com/c/public/gem5/+/32175
>
> https://gem5-review.googlesource.com/c/public/gem5/+/40878
>
>
> A similar issue exists for macros, and an existing proposal to solve it
> already
> exists, which is to add a "GEM5_" prefix. It follows the coding style,
> which
> dictates that "preprocessor symbols (constants and macros) should be all
> caps with underscores":
>
> https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-912
>
>
> It does not seem to be controversial to add this namespace; however, there
> is
> still one blocker to greenlight its creation: what will be its name. There
> are
> no explicit rules regarding namespace naming; however, they are typically
> declared starting with an uppercase letter followed by lowercase letters.
> So,
> theoretically, gem5's namespace should be "Gem5". This, however, conflicts
> with gem5's identity: "“gem5” should always have a lowercase “g”"
> (see http://www.gem5.org/getting_started/).
>
>
> We should decide as a community what is the best approach to take, so I'll
> list the options and will request you to cast your votes. If you would like
> to add remarks to the discussion, feel free to do so.
>
>
> NAMESPACE:
>
> *1 - namespace Gem5 {}*
>
> *2 - namespace gem5 {}*
>
>
> MACROS:
>
> *A - GEM5_MACRO_NAME*
>
> *B - gem5_MACRO_NAME*
>
>
> Personally, I think that identity precedes coding style, so **option 2**
> should
> be taken. Yet, in a slightly inconsistent manner, I would vote for macro
> **option A**. My argument being that it would be more convenient to type
> it
> with all caps, and that it would be implied from the identity that it
> refers to
> instances of the identity containing lowercase letters, which is not the
> case
> of "GEM5_".
>
> Best,
> Daniel
> ___
> 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: Weekly #14

[Jason Lowe-Power via gem5-dev]

I think https://gem5-review.googlesource.com/c/public/gem5/+/43287 change
caused the breakage. Should be a simple fix to the GPU scripts.

Cheers,
Jason

On Fri, Mar 26, 2021 at 3:17 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See 
>
> Changes:
>
> [Bobby R. Bruce] scons: Fixing build errors with scons 4.0.1 and 4.1.0
>
> [Bobby R. Bruce] misc: Updated the RELEASE-NOTES and version number
>
> [petery.hin] arch-riscv: Fixing RISC-V remote GDB MIP and MIE accesses.
>
> [Bobby R. Bruce] base-stats,python: Add missing "group" in `_prepare_stats`
>
> [gabe.black] systemc: Stop using std::gets in systemc.h.
>
> [gabe.black] scons,tlm: Update the gem5-within-systemc SConstruct to use
> c++14.
>
> [gabe.black] systemc,util: Update sc_master_port.cc now that params()
> returns a ref.
>
> [gabe.black] systemc,util: Fix a bad port of a change from gem5 proper to
> here.
>
> [gabe.black] scons,util: Make the tlm SConstruct put SConsign in the build
> dir.
>
> [gabe.black] sim,systemc: Use slightly non-standard constructors for
> custom create()
>
> [gabe.black] cpu: Delete unnecessary create() methods.
>
> [gabe.black] scons,python: Always generate default create() methods.
>
> [Andrea.Mondelli] arch-riscv: Fixed CPU switching and PLIC issue with
> MinorCPU
>
> [Giacomo Travaglini] configs: Remove icache from HTMSequencer
>
> [Giacomo Travaglini] dev-arm: Fix SMMUv3BaseCache Stats
>
> [Giacomo Travaglini] dev-arm: Fix WalkCache stats
>
> [Giacomo Travaglini] dev-arm: Remove unused SMMUv3 WalkCache variables
>
> [Giacomo Travaglini] configs: Use integer division in
> MESI_Three_Level_HTM.py
>
> [tiago.muck] scons,mem-ruby: export need_partial_func_reads in SConstruct
>
> [tiago.muck] configs,mem-ruby: CHI-based Ruby protocol
>
> [odanrc] base-stats: Fix Watt Unit
>
> [Bobby R. Bruce] python: Fix incorrect prefixes is m5.utils.convert
>
> [Bobby R. Bruce] arch-arm: Fix atomics permission checks in TLB
>
> [Bobby R. Bruce] configs: Use integer division in MESI_Three_Level_HTM.py
>
> [Bobby R. Bruce] misc: Updated the RELEASE-NOTES and version number
>
> [Giacomo Travaglini] configs, mem: MemInterface generating its own
> controller
>
> [odanrc] misc: Fix coding style for class-opening braces
>
> [odanrc] util: Add verifier for opening braces of classes
>
> [odanrc] misc: Fix coding style for struct's opening braces
>
> [Giacomo Travaglini] configs: Remove simpleSystem factory function
>
> [odanrc] util: Add verifier for opening braces of structs
>
> [gabe.black] mem: Fix style in addr_mapper.hh.
>
> [gabe.black] arch,cpu: Collapse away TheISA::advancePC.
>
> [gabe.black] arch,cpu: Move TheISA::copyRegs to TheISA::ISA::copyRegsFrom.
>
> [gabe.black] arch,cpu,kern,sim: Eliminate the utility.hh switching header.
>
> [odanrc] misc: Fix coding style for enum's opening braces
>
> [odanrc] util: Add verifier for opening braces of enums
>
> [odanrc] misc: Fix coding style for union's opening braces
>
> [odanrc] base-stats: Add unit test for Stats::Units
>
> [odanrc] base-stats: Make Rate's compilation smarter
>
> [odanrc] util: Add verifier for opening braces of unions
>
> [daecheol.you] mem-garnet: Added packet distribution stats
>
> [gabe.black] arch-arm: Consolidate register related files into a directory.
>
> [gabe.black] arch: Eliminate the GuestByteOrder constant.
>
> [Giacomo Travaglini] configs: Add a BaseSimpleSystem
>
> [Giacomo Travaglini] configs, tests: Ruby.create_system cpus option
>
> [Giacomo Travaglini] configs: RubySimpleSystem and simple ruby_fs.py script
>
> [mattdsinclair] dev-hsa: Fix size of HSA Queue
>
> [yazakram] arch-riscv,util: fix the default cross compiler for riscv
>
> [mattdsinclair] gpu-compute: Support dynamic scratch allocations
>
> [mattdsinclair] gpu-compute: Remove unused functions
>
> [odanrc] dev-hsa: Fix includes
>
>
> --
> [...truncated 943.76 KB...]
>  [SHCC] softfloat/f64_mulAdd.c -> .os
>  [SHCC] softfloat/f64_mul.c -> .os
>  [SHCC] softfloat/f64_rem.c -> .os
>  [SHCC] softfloat/f64_roundToInt.c -> .os
>  [SHCC] softfloat/f64_sqrt.c -> .os
>  [SHCC] softfloat/f64_sub.c -> .os
>  [SHCC] softfloat/f64_to_f128.c -> .os
>  [SHCC] softfloat/f64_to_f16.c -> .os
>  [SHCC] softfloat/f64_to_f32.c -> .os
>  [SHCC] softfloat/f64_to_i32.c -> .os
>  [SHCC] softfloat/f64_to_i32_r_minMag.c -> .os
>  [SHCC] softfloat/f64_to_i64.c -> .os
>  [SHCC] softfloat/f64_to_i64_r_minMag.c -> .os
>  [SHCC] softfloat/f64_to_ui32.c -> .os
>  [SHCC] softfloat/f64_to_ui32_r_minMag.c -> .os
>  [SHCC] softfloat/f64_to_ui64.c -> .os
>  [SHCC] softfloat/f64_to_ui64_r_minMag.c -> .os
>  [SHCC] softfloat/i32_to_f128.c -> .os
>  [SHCC] softfloat/i32_to_f16.c -> .os
>  [SHCC] softfloat/i32_to_f32.c -> .os
>  [SHCC] softfloat/i32_to_f64.c -> .os
>  [SHCC] softfloat/i64_to_f128.c -> .os
>  [SHCC] 

[gem5-dev] Re: Python level port indirection

[Jason Lowe-Power via gem5-dev]

Hi Gabe,

Why have a new special "port" and not just a function (e.g., connectCPU or
connectMemory depending on if you're CPU or memory-side focused)?

I would strongly prefer to have descriptive names and not something like
"Export" which could mean many things.

Jason

On Wed, Mar 17, 2021 at 9:05 PM Gabe Black via gem5-dev 
wrote:

> Hi folks. I've been thinking about a new type of port which only exists in
> python, and which just proxies for another port which belongs to some other
> object. If you're familiar with systemc, I think this is pretty similar to
> the "export" object. The major use case for this would be to, for instance,
> add some to a SubSystem class (which is nothing but a blank box to hold
> other things) to expose ports within the SubSystem without having to dig
> around inside it. For instance, if you have a CPU complex with internal
> structure, you might want to wrap it all in a SubSystem and add a port for
> data, instruction, cached, uncached, etc. That would provide a lot more
> uniformity between CPUs, and help avoid having special little methods to
> hook up ports or say what port to use when connecting to a bus.
>
> The name is a little tricky since port proxy is already a well known
> thing. Maybe just Export? That name has precedence, but I've always thought
> it wasn't immediately clear what it was.
>
> 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] Some gem5 infrastructure down

[Jason Lowe-Power via gem5-dev]

Hi all,

We're having an issue with the billing for our Google cloud infrastructure.
There may be intermittent issues with gem5 infrastructure for a little
while. We hope to get this resolved within a few hours.

Cheers,
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] Re: RFC: run python Black on gem5 python code

[Jason Lowe-Power via gem5-dev]

Hi all,

Some responses inline below. The other thing I'll mention is that I believe
we can integrate it in a way where it's completely invisible to most
developers. You can edit a file with whatever style you want, then after
you run black it will be in the PEP8 style. From my experience, the only
things that need to be manually changed are quoted strings that are more
than 80 characters.

On Thu, Mar 4, 2021 at 6:49 AM Giacomo Travaglini via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hi Jason,
>
> This is great news. When you say it is not configurable, do you mean it is
> not possible to suppress warning/errors or do you
> mean it is not possible to come up with custom rules?
>

There is a way to suppress changes by modifying the file with a comment `#
fmt: off`. You can also exclude files with a dotfile (like .gitignore).


>
> As I presume it's the first case, I am wondering if a different linter
> might provide such capabilities:
>
>
> https://books.agiliq.com/projects/essential-python-tools/en/latest/linters.html
>
> Is there a reason to prefer black over other linters?
>

It's owned by the python software foundation, which makes it seem
"official". Though the real reason is that it's the first one I looked at
and the only one I investigated.


>
> Kind regards
>
> Giacomo
>
> > -Original Message-
> > From: Gabe Black via gem5-dev 
> > Sent: 04 March 2021 03:59
> > To: gem5 Developer List 
> > Cc: Gabe Black 
> > Subject: [gem5-dev] Re: RFC: run python Black on gem5 python code
> >
> > I'm a little worried about the no exceptions part of that, since we
> might have
> > some weird restrictions that we have to do weird things to work around,
> but I
> > can't really think of an example of that off hand. I'd want to look at
> it to see
> > how much wiggle room there is in the style, since I think ironclad rules
> which
> > make no accommodation for occasional common sense are maybe more
> > trouble than they're worth. I'm not opposed to having at least some
> stated
> > standard for python though, and the "official" one seems like a pretty
> > reasonable choice. I guess it's fine with me, up until it causes me some
> sort of
> > problem :-)
>

I actually think it's a feature not a bug. With an "uncompromising Python
code formatter" there can be no arguments in code review about the style.


> >
> > Maybe the right thing to do would be to give it a shot but not make it
> > compulsory until we have a feeling for how much trouble it is.
> >
> >
> > Gabe
> >
> > On Wed, Mar 3, 2021 at 11:24 AM Bobby Bruce via gem5-dev  > d...@gem5.org <mailto:gem5-dev@gem5.org> > wrote:
> >
> >
> > Sounds like a good idea to me.
> > ---
> >
> > Dr. Bobby R. Bruce
> > Room 2235,
> > Kemper Hall, UC Davis
> > Davis,
> > CA, 95616
> >
> >
> > web: https://www.bobbybruce.net
> >
> >
> >
> > On Wed, Mar 3, 2021 at 10:11 AM Daniel Carvalho via gem5-dev
> > mailto:gem5-dev@gem5.org> > wrote:
> >
> >
> > +1
> >
> >
> > Em quarta-feira, 3 de março de 2021 14:35:57 BRT, Jason
> > Lowe-Power via gem5-dev mailto:gem5-
> > d...@gem5.org> > escreveu:
> >
> >
> > Hi all,
> >
> > Right now, we don't have an official style guide for python.
> > Our style guide
> > (http://www.gem5.org/documentation/general_docs/development/coding_st
> > yle/) is very C++ focused.
> >
> > I would like to propose adopting a relatively strict PEP 8 style
> > guide: https://www.python.org/dev/peps/pep-0008. This is the "official"
> style
> > guide for python (as much as there is anything official). I say
> "relatively strict"
> > to mean that we will limit our exceptions *as much as possible*.
> >
> > To implement this, Andreas S. recently pointed me to the
> > "Black" package (https://pypi.org/project/black/) which automatically
> fixes
> > code style. I just tried it out with gem5art (patch coming soon) and
> found that
> > it works really well. The only downside is that it's not configurable at
> all.
> > Adding special cases would be almost impossible.
> >
> > Concrete and specific proposal:
> > - Adopt PEP 8 as our official style guide
> > - Use black to reformat all python code in src/
> > - Use black to reformat code in configs/
> > - Use black to reformat other python code
> >
> > - Use black as part of our commit hook to make sure all future
> > python is form

[gem5-dev] RFC: run python Black on gem5 python code

[Jason Lowe-Power via gem5-dev]

Hi all,

Right now, we don't have an official style guide for python. Our style
guide (
http://www.gem5.org/documentation/general_docs/development/coding_style/)
is very C++ focused.

I would like to propose adopting a relatively strict PEP 8 style guide:
https://www.python.org/dev/peps/pep-0008. This is the "official" style
guide for python (as much as there is anything official). I say "relatively
strict" to mean that we will limit our exceptions *as much as possible*.

To implement this, Andreas S. recently pointed me to the "Black" package (
https://pypi.org/project/black/) which automatically fixes code style. I
just tried it out with gem5art (patch coming soon) and found that it works
really well. The only downside is that it's not configurable at all. Adding
special cases would be almost impossible.

Concrete and specific proposal:
- Adopt PEP 8 as our official style guide
- Use black to reformat all python code in src/
- Use black to reformat code in configs/
- Use black to reformat other python code
- Use black as part of our commit hook to make sure all future python is
formatted to PEP 8

Let me know what you think!

Cheers,
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] Re: review backlog

[Jason Lowe-Power via gem5-dev]

Hey Gabe,

Just FYI, those of use working on the release still have to test and fix
bugs that we find on the staging branch. In releases past, this has taken
2-4 weeks of 100% effort. We'll get to these new changes when we can!

Cheers,
Jason

On Mon, Mar 1, 2021 at 3:56 PM Gabe Black via gem5-dev 
wrote:

> Hi folks. Now that the release branch has been created, I'd appreciate it
> if we could start draining out the review backlog that has built up. I have
> the following series of changes out and ready for review if you're so
> inclined, link to the last change in the set.
>
> Eliminating the arch/utility.hh header (5 CLs)
> https://gem5-review.googlesource.com/c/public/gem5/+/39337
>
> Mostly eliminate the arch/types.hh header, and some other cleanups (12 CLs)
> https://gem5-review.googlesource.com/c/public/gem5/+/41893
>
> SCons cleanup (24 CLs)
> https://gem5-review.googlesource.com/c/public/gem5/+/41599
>
> Guest ABI implementation rework (1 CL)
> https://gem5-review.googlesource.com/c/public/gem5/+/41600
>
> Drain most of the contents out of arch/registers.hh (10 CLs)
> https://gem5-review.googlesource.com/c/public/gem5/+/41742
>
> Vector (predicate) register simplification, cleanup, streamlining (17 CLs)
> https://gem5-review.googlesource.com/c/public/gem5/+/42003
>
> Some of these ~70 CLs have been reviewed already, but are being held up by
> CLs ahead of them which have not. I've generally tried to pluck out CLs
> which are already reviewed and which can jump the queue, but I think I've
> already done that for all the CLs where it makes sense. Many of these are
> really simple CLs which just delete things which aren't being used, so they
> should be pretty easy to review.
>
> 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 v21.0.0.0 Staging branch created

[Jason Lowe-Power via gem5-dev]

I assume you mean "**NOW** begin running rigorous tests" ;)

Cheers,
Jason

On Mon, Mar 1, 2021 at 10:27 AM Bobby Bruce via gem5-dev 
wrote:

> Dear all,
>
> As of 10:30AM PST the gem5 Staging Branch for gem5 v21.0.0.0 has been
> created from the gem5 develop branch. We will not begin running rigorous
> tests on this branch to ensure the upcoming release is as stable and
> bug-free as possible. After this we will merge the release branch into the
> stable branch, thus officially releasing gem5.
>
> In line with our contribution guidelines (
> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/CONTRIBUTING.md),
> we permit alterations to be submitted to this staging branch though these
> should strictly be "last-minute" bug fixes, stability improvements, and
> small alterations that will not affect the functionality of the codebase
> (documentation/README improvements, etc.). All other changes should
> continue to be submitted to the gem5 develop branch. The staging branch
> will be periodically merged into the develop branch so bug fixes etc. are
> available to developers working on the develop branch.
>
> We would like to thank everyone for the contributions made over the past
> few months. This release would not be possible without your efforts.
>
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 2235,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
> ___
> 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: de-templating the O3 CPU

[Jason Lowe-Power via gem5-dev]

Hey Gabe,

I love this idea! It would be nice if you could document the code as you
go, too. It could serve as a good learning tool in the future.

Cheers,
Jason

On Mon, Mar 1, 2021 at 7:56 AM Giacomo Travaglini via gem5-dev <
gem5-dev@gem5.org> wrote:

> +2, +1, Merged
>
> 
>
> Giacomo
>
> > -Original Message-
> > From: Gabe Black via gem5-dev 
> > Sent: 27 February 2021 10:13
> > To: gem5 Developer List 
> > Cc: Gabe Black 
> > Subject: [gem5-dev] de-templating the O3 CPU
> >
> > Hi folks. The O3 CPU uses templates pretty heavily, I think nominally to
> make it
> > possible to switch in different parts of the CPU to change how, for
> example, a
> > pipeline stage is implemented.
> >
> > Realistically, the different parts of the CPU are probably too
> interdependent
> > for that to actually work, and all the templates and indirection make
> the code a
> > lot more complicated than it really needs to be.
> >
> > Also, there is a pseudo-generic dynamic instruction base class in
> > cpu/base_dyn_inst.hh which could, again theoretically, be used as a base
> class
> > for other CPUs to reuse. Unfortunately that too is probably too tied to
> its only
> > consumer, the O3 CPU, to be realistically reusable.
> >
> > I would like to merge the base dynamic instruction class into the O3
> version,
> > and then de-templatize the whole O3 CPU. I think that will make the code
> a lot
> > easier to work on, and I think our ability to maintain and update O3 is
> > something we need to improve in at least the medium term.
> >
> > Any thoughts? Objections? Votes of support?
> >
> > 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 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: Design doc for partial rework of instruction execution mechanism

[Jason Lowe-Power via gem5-dev]

Thanks for the effort here, Gabe! I'm excited to dive in.

Just FYI, I will probably not have the bandwidth to deeply look at this for
at least a few weeks. Between remote teaching and trying to get the release
out of the door, I'm completely swamped for the near term.

Cheers,
Jason

On Tue, Feb 23, 2021 at 12:00 AM Gabe Black via gem5-dev 
wrote:

> Oh, also, while implementing everything in this new doc would/will be a
> pretty big undertaking, I think forcing operands in the ISA descriptions to
> be explicitly sources or destinations but not both would be a major
> improvement. For most registers that should be pretty trivial (they are
> already called things like "Dest" or "Src1"), and for the rest the change
> should just be a lot of find/replace style changes. That could be a first
> step towards what's in the doc and could be done immediately, independent
> of anything else.
>
> Gabe
>
> On Mon, Feb 22, 2021 at 11:57 PM Gabe Black  wrote:
>
>> Hey folks.I have a design doc for a moderate in scope but significant in
>> impact rework of how instruction execution and tracing work in gem5. This
>> is something I've been thinking about for a while, but threw together just
>> now to get it out there:
>>
>>
>> https://docs.google.com/document/d/1IqxBYr_arZq5G51oqmXoL5I9HiiwWMQ_t-rvHA78YPE/edit?usp=sharing
>>
>> This is strongly informed by an earlier design doc I wrote about how
>> registers are handled here:
>>
>>
>> https://docs.google.com/document/d/1O_u_Xq14TgreYThuZcbM3kuXFCrKvaFHA2O9poCeHSk/edit#heading=h.r067bn3rmydo
>>
>> It is a lot more narrowly scoped though, focusing only on operands and
>> instruction execution at the StaticInst level, but also extends beyond what
>> was described in that original doc.
>>
>> I'm biased of course, but I think there's a lot of value in reworking
>> things as described in the doc. Please take a look at let me know what you
>> 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: removing partial linking hurts simulator performance, locality suspected

[Jason Lowe-Power via gem5-dev]

This is interesting! My takeaway: we need bigger i-caches to run gem5 ;).

Is the binary about the same size for the two conditions? Could it be
simply that the instruction working set is bigger when not using partial
linking?

That said, a 3% performance difference isn't a big problem, in my opinion.
This analysis also gives us some interesting directions for future
optimizations. I wonder how much the library version of pybind will help
since that will significantly reduce the instruction footprint.

Jason

On Tue, Feb 9, 2021 at 10:56 PM Gabe Black via gem5-dev 
wrote:

> I did some measurements before and after, and I noticed a few things.
> First, the iTLB-load-misses stat drops form 0.25% all the way down to
> 0.02%. The frontend and backend stall cycles went down from 1.72% => 1.27%
> and 13.90% => 10.62% respectively. The L1-icache-load-misses went *up* from
> 1.74% => 2.77%.
>
> So it looks like performance is generally about the same or a little
> better in most metrics, but for some reason icache hit rate drops.
>
> Performance measurements with partial linking:
>
> 429,882.68 msec task-clock:u  #1.000 CPUs utilized
>
>  0  context-switches:u#0.000 K/sec
>
>  0  cpu-migrations:u  #0.000 K/sec
>
>145,986  page-faults:u #0.340 K/sec
>
>  1,830,956,683,109  cycles:u  #4.259 GHz
>(35.71%)
> 31,472,946,642  stalled-cycles-frontend:u #1.72% frontend
> cycles idle (35.71%)
>254,440,746,368  stalled-cycles-backend:u  #   13.90% backend
> cycles idle  (35.71%)
>  4,117,921,862,700  instructions:u#2.25  insn per
> cycle
>   #0.06  stalled
> cycles per insn  (35.71%)
>773,059,098,367  branches:u# 1798.303 M/sec
>(35.71%)
>  2,775,345,450  branch-misses:u   #0.36% of all
> branches  (35.71%)
>  2,329,109,097,524  L1-dcache-loads:u # 5418.011 M/sec
>(35.71%)
> 24,907,172,614  L1-dcache-load-misses:u   #1.07% of all
> L1-dcache accesses  (35.71%)
>  LLC-loads:u
>
>  LLC-load-misses:u
>
>872,678,362,265  L1-icache-loads:u # 2030.038 M/sec
>(35.71%)
> 15,221,564,231  L1-icache-load-misses:u   #1.74% of all
> L1-icache accesses  (35.71%)
> 48,763,102,717  dTLB-loads:u  #  113.434 M/sec
>(35.71%)
> 75,459,133  dTLB-load-misses:u#0.15% of all dTLB
> cache accesses  (35.71%)
>  8,416,573,693  iTLB-loads:u  #   19.579 M/sec
>(35.72%)
> 20,650,906  iTLB-load-misses:u#0.25% of all iTLB
> cache accesses  (35.72%)
>
>  429.911532621 seconds time elapsed
>
>  428.611864000 seconds user
>0.199257000 seconds sys
>
>
> Performance measurements without partial linking:
>
> 444,598.61 msec task-clock:u  #1.000 CPUs utilized
>
>  0  context-switches:u#0.000 K/sec
>
>  0  cpu-migrations:u  #0.000 K/sec
>
>145,528  page-faults:u #0.327 K/sec
>
>  1,907,560,568,869  cycles:u  #4.291 GHz
>(35.71%)
> 24,156,412,003  stalled-cycles-frontend:u #1.27% frontend
> cycles idle (35.72%)
>202,601,144,555  stalled-cycles-backend:u  #   10.62% backend
> cycles idle  (35.72%)
>  4,118,200,832,359  instructions:u#2.16  insn per
> cycle
>   #0.05  stalled
> cycles per insn  (35.72%)
>773,117,144,029  branches:u# 1738.910 M/sec
>(35.72%)
>  2,727,637,567  branch-misses:u   #0.35% of all
> branches  (35.71%)
>  2,326,960,449,159  L1-dcache-loads:u # 5233.845 M/sec
>(35.71%)
> 26,778,818,764  L1-dcache-load-misses:u   #1.15% of all
> L1-dcache accesses  (35.71%)
>  LLC-loads:u
>
>  LLC-load-misses:u
>
>903,186,314,629  L1-icache-loads:u # 2031.465 M/sec
>(35.71%)
> 25,017,115,665  L1-icache-load-misses:u   #2.77% of all
> L1-icache accesses  (35.71%)
> 50,448,039,415  dTLB-loads:u  #  113.469 M/sec
>(35.71%)
> 78,186,127  dTLB-load-misses:u#0.15% of all dTLB
> cache accesses  (35.71%)
>  9,419,644,114  iTLB-loads:u  #   21.187 M/sec
>(35.71%)
>  1,479,281  iTLB-load-misses:u#0.02% of all iTLB
> cache accesses  (35.71%)
>
>  444.623341115 seconds time elapsed
>
>  443.313786000 seconds user
>0.256109000 seconds sys
>
> On Sat, Feb 6, 2021 at 5:20 AM Gabe Black  wrote:
>
>> Out of 

[gem5-dev] Re: Upstreaming power-gem5

[Jason Lowe-Power via gem5-dev]

Wow! Thanks for all of the work here! It's cool to see all of the
excitement around POWER support!

Just to be clear, because I think it was a little ambiguous in other
conversations, I'm very supportive of improving the POWER support in gem5
given that there are a significant number of people who want to use it. Not
long ago, there seemed to be little interest in POWER from the community,
which was influencing my push to limit the effort towards that ISA.

A couple of notes:
1. Per Bobby's recent email, we are *planning* (though plans can always
change) to mark a new gem5 release at the end of the month. In **one
week**, we are planning to create the staging branch which is the time that
no new features can be integrated for the release. If there's strong
support in the community, we can hold off for the improved POWER support,
but with all of the changes that need to be reviewed, it seems unlikely to
happen in 1 week. I suggest improved POWER support to be a main feature of
the next release (gem5-21.1 probably sometime in May or June).
2. Since we have a release coming up in 3 weeks, it is unlikely that I or
my team will have much time to look at these changes. With our limited
resources, we need to focus on finishing the features that we have started
and the general stability of gem5.

As I said, I'm very excited to see these improvements to gem5! And, I'm
looking forward to seeing the community grow!

Cheers,
Jason

On Sun, Feb 7, 2021 at 10:32 PM Sandipan Das via gem5-dev 
wrote:

> +CC: Luke
>
> On 08/02/21 10:26 am, Sandipan Das wrote:
> > Hello Boris, Gabe,
> >
> > I have rebased and pushed the changes to gerrit.
> > This is link to the first patch in the series:
> > https://gem5-review.googlesource.com/c/public/gem5/+/40880
> >
> >
> ___
> 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: Testlib six dependency

[Jason Lowe-Power via gem5-dev]

I don't know... We've had a few discussions about this. There's some
separation between the underlying infrastructure in testlib and the code
that uses it in tests. We could move it to tests/testlib, I guess. It would
make it more clear that there's no upstream version of it.

Either way is fine with me.

Jason

On Tue, Jan 26, 2021 at 9:45 AM Andreas Sandberg 
wrote:

> Hi Jason,
>
> Thanks for confirming that. I have posted an update here:
> https://gem5-review.googlesource.com/c/public/gem5/+/39759
>
> Since there is no upstream for testlib, should we move it into tests/
> somewhere instead of keeping it in ext/?
>
> Cheers,
> Andreas
> On 26/01/2021 16:21, Jason Lowe-Power wrote:
>
> Hi Andreas,
>
> There is no upstream for testlib. It's a purely gem5 project. We should
> fix it in tree.
>
> Jason
>
> On Tue, Jan 26, 2021 at 4:56 AM Andreas Sandberg via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Hi Everyone,
>>
>> I have just posted a series of patches [1] that get rid of 'six' as a
>> dependency in gem5. However, there is still a dependency on six coming
>> from testlib. What's the process there? Should we fix it upstream and
>> backport it or is testlib now effectively a gem5 project?
>>
>> Cheers,
>> Abdreas
>>
>> [1] https://gem5-review.googlesource.com/c/public/gem5/+/39758
>>
>> 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
>>
> 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: Testlib six dependency

[Jason Lowe-Power via gem5-dev]

Hi Andreas,

There is no upstream for testlib. It's a purely gem5 project. We should fix
it in tree.

Jason

On Tue, Jan 26, 2021 at 4:56 AM Andreas Sandberg via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hi Everyone,
>
> I have just posted a series of patches [1] that get rid of 'six' as a
> dependency in gem5. However, there is still a dependency on six coming
> from testlib. What's the process there? Should we fix it upstream and
> backport it or is testlib now effectively a gem5 project?
>
> Cheers,
> Abdreas
>
> [1] https://gem5-review.googlesource.com/c/public/gem5/+/39758
>
> 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 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: Nightly stuck

[Jason Lowe-Power via gem5-dev]

Thanks, Giacomo! We may be a bit slow to respond (it's a holiday here in
the states today and Bobby is off the next couple of days).

I don't think we want to do a global timeout since we have some tests that
take days. The compiler test takes about 3 days, IIRC. I think per-test
timeout is going to be required.

Cheers,
Jason

On Mon, Jan 18, 2021 at 9:43 AM Giacomo Travaglini via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hi all,
>
> This has been fixed and it's going to be merged today.
>
> This made me realize we might want to introduce a timeout for our
> regressions. A global, Jenkins level one is easy to add and doesn't require
> any code modifications.
>
> However a per-test timeout is probably the best approach. In this way we
> can:
>
> a) Understand which regression is deadlocking from the output log
> b) Killing the failing test earlier thus saving computational costs:
>
> e.g: I will kill the test after 6 minutes if it is supposed to complete in
> a minute, rather than having a global abort set up after 24 hours.
>
> How to do this is up do debate. This falls within the typical wall-clock
> time vs cpu time issue; setting up a timeout for wall-clock time is
> straightforward with python subprocess, but cpu time is what we would
> really care about...
> Though if we make sure our timing out margin is relatively high (loosening
> the safety net) we can probably get around the intrinsic difference between
> the two metrics and just use wall-clock time.
>
> Does anybody have any thoughts on this?
>
> Giacomo
>
> > -Original Message-
> > From: Giacomo Travaglini
> > Sent: 18 January 2021 10:22
> > To: gem5 Developer List 
> > Subject: Nightly stuck
> >
> > Hi devs,
> >
> > It seems like the following Nightly run #191 is stuck:
> >
> > https://jenkins.gem5.org/job/Nightly/191/
> >
> > I am running those tests locally to understand if it is a tool problem
> or broken
> > long regressions are currently broken Will keep you posted
> >
> > Kind Regards
> >
> > Giacomo
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> 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: Re-join debug flags headers

[Jason Lowe-Power via gem5-dev]

Thanks for bringing this up, Daniel!

I don't have a strong opinion, personally. I see how this makes things a
little easier for developers. No longer would we have to teach people that
to add a new debug flag you both declare it in the SConscript file and
include the named header file. Given that I've worked with gem5 for a long
time, I don't see that as much overhead, though.

This would increase the compile time (though, hopefully only rarely). And,
we recently found from the gem5 survey that people don't care that much
about the compile time (more info coming soon).

I think the biggest downside would be for those that use gem5 in teaching.
Students in architecture classes are the most likely to have underpowered
computers building gem5, and they are also likely to be adding debug flags.

Cheers,
Jason

On Fri, Jan 15, 2021 at 5:47 PM Daniel Carvalho via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hello all,
>
> I've uploaded a commit that re-joins the debug header files into a single
> one: https://gem5-review.googlesource.com/c/public/gem5/+/39255. This
> means that instead of having to include a different header for each and
> every debug flag used in a file, only one is needed. For example, in
> src/arch/arm/kvm/arm_cpu.cc
>
> #include "debug/Kvm.hh"
> #include "debug/KvmContext.hh"
> #include "debug/KvmInt.hh"
>
> would be replaced by
>
> #include "debug/flags.hh"
>
> Finally, since most of the code using these flags will use DPRINTF or a
> similar macro, this include could be added to base/trace.hh, so that most
> of the times it would be included transitively.
>
> The advantage of this change is that debugging becomes easier/faster: this
> file would behave as a library of supported flags and very few header
> files would suffice for all debugging needs. The disadvantage is that
> every time a commit introduces or removes a debug flag debug/flags.hh will
> be recompiled, which will cause an almost complete build. Luckily, debug
> flags are not frequently modified.
>
> Performance-wise both approaches are similar.
>
> What are your opinions in this matter?
>
> Cheers,
> Daniel
> ___
> 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: Testing fail on GCN3_X86 on Arm machine

[Jason Lowe-Power via gem5-dev]

Hi all,

It doesn't surprise me at all that GCN3 doesn't build on Arm. Nathanael,
you should be able to ignore those errors. We don't test that combination
of host-target and I have not heard of anyone trying to use that
combination of host-target.

If you're trying to use the GPU model, I'd suggest moving to an x86 host.
Unfortunately, right now the GPU model is intricately tied to the host OS.
Hence why the docker is all but required to get the GPU model working.

Cheers,
Jason

On Mon, Jan 11, 2021 at 10:59 AM Matt Sinclair via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hi Nathanael,
>
> I have personally never tested GCN3 on an ARM machine, so I can't say
> definitively if it will work there or not.  But if you are not, I strongly
> recommend testing anything you need to test with GCN3 inside the docker we
> created:
>
> -
> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/util/dockerfiles/gcn-gpu/README.md
> - http://www.gem5.org/2020/05/27/modern-gpu-applications.html
>
> Thanks,
> Matt
>
> On Mon, Jan 11, 2021 at 8:42 AM Nathanael Premillieu via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Hi,
>>
>>
>>
>> I’m currently working on some changes in gem5 and before submitting them,
>> I’m using the testing framework as required.
>>
>> However, even without my changes, I get failures when building GCN3_X86
>> (See the trace at the end).
>>
>> I guess it is linked to the fact that I’m working on an Arm machine. Do I
>> need to set up something to make it work?
>>
>>
>>
>> Thanks,
>>
>> Nathanael Premillieu
>>
>>
>>
>> The trace:
>>
>> /scratch/npremill/gem5_public.git/build/GCN3_X86/gem5.opt
>>
>> You may want to run with only a single ISA(--isa=), use --skip-build, or
>> use 'rerun'.
>>
>> MOESI_AMD_Base-dir.sm:220: Warning: Non-void return ignored, return type
>> is 'bool'
>>
>> MOESI_AMD_Base-dir.sm:1052: Warning: Non-void return ignored, return type
>> is 'Tick'
>>
>> MOESI_AMD_Base-dir.sm:1056: Warning: Non-void return ignored, return type
>> is 'Tick'
>>
>> MOESI_AMD_Base-dir.sm:1060: Warning: Non-void return ignored, return type
>> is 'Tick'
>>
>> MOESI_AMD_Base-dir.sm:1064: Warning: Non-void return ignored, return type
>> is 'Tick'
>>
>> MOESI_AMD_Base-dir.sm:1068: Warning: Non-void return ignored, return type
>> is 'Tick'
>>
>> MOESI_AMD_Base-dir.sm:1072: Warning: Non-void return ignored, return type
>> is 'Tick'
>>
>> MOESI_AMD_Base-dir.sm:1076: Warning: Non-void return ignored, return type
>> is 'Tick'
>>
>> MOESI_AMD_Base-dir.sm:586: Warning: Unused action: l_queueMemWBReq, Write
>> WB data to memory
>>
>> MOESI_AMD_Base-dir.sm:953: Warning: Unused action:
>> mwc_markSinkWriteCancel, Mark to sink impending VicDirty
>>
>> MOESI_AMD_Base-dir.sm:1051: Warning: Unused action: dl_deallocateL3,
>> deallocate the L3 block
>>
>> MOESI_AMD_Base-dir.sm:1087: Warning: Unused action:
>> yy_recycleResponseQueue, recycle response queue
>>
>> MOESI_AMD_Base-dma.sm:187: Warning: Non-void return ignored, return type
>> is 'Tick'
>>
>> MOESI_AMD_Base-dma.sm:191: Warning: Non-void return ignored, return type
>> is 'Tick'
>>
>> MOESI_AMD_Base-CorePair.sm:325: Warning: Non-void return ignored, return
>> type is 'bool'
>>
>> MOESI_AMD_Base-CorePair.sm:802: Warning: Non-void return ignored, return
>> type is 'Tick'
>>
>> MOESI_AMD_Base-CorePair.sm:806: Warning: Non-void return ignored, return
>> type is 'Tick'
>>
>> MOESI_AMD_Base-CorePair.sm:810: Warning: Non-void return ignored, return
>> type is 'Tick'
>>
>> MOESI_AMD_Base-CorePair.sm:814: Warning: Non-void return ignored, return
>> type is 'Tick'
>>
>> GPU_VIPER-TCP.sm:166: Warning: Non-void return ignored, return type is
>> 'bool'
>>
>> GPU_VIPER-TCP.sm:451: Warning: Non-void return ignored, return type is
>> 'Tick'
>>
>> GPU_VIPER-TCP.sm:455: Warning: Non-void return ignored, return type is
>> 'Tick'
>>
>> GPU_VIPER-TCP.sm:385: Warning: Unused action: norl_issueRdBlkOrloadDone,
>> local load done
>>
>> GPU_VIPER-SQC.sm:143: Warning: Non-void return ignored, return type is
>> 'bool'
>>
>> GPU_VIPER-SQC.sm:275: Warning: Non-void return ignored, return type is
>> 'Tick'
>>
>> GPU_VIPER-SQC.sm:279: Warning: Non-void return ignored, return type is
>> 'Tick'
>>
>> GPU_VIPER-TCC.sm:168: Warning: Non-void return ignored, return type is
>> 'bool'
>>
>> GPU_VIPER-TCC.sm:551: Warning: Non-void return ignored, return type is
>> 'Tick'
>>
>> GPU_VIPER-TCC.sm:555: Warning: Non-void return ignored, return type is
>> 'Tick'
>>
>> GPU_VIPER-TCC.sm:559: Warning: Non-void return ignored, return type is
>> 'Tick'
>>
>> GPU_VIPER-TCC.sm:583: Warning: Non-void return ignored, return type is
>> 'Tick'
>>
>> MOESI_AMD_Base-L3cache.sm:196: Warning: Non-void return ignored, return
>> type is 'bool'
>>
>> MOESI_AMD_Base-L3cache.sm:611: Warning: Non-void return ignored, return
>> type is 'Tick'
>>
>> MOESI_AMD_Base-L3cache.sm:615: Warning: Non-void return ignored, return
>> type is 'Tick'
>>
>> MOESI_AMD_Base-L3cache.sm:619: Warning: Non-void return ignored, return
>> type is 

[gem5-dev] Re: Build failed in Jenkins: Nightly #118

[Jason Lowe-Power via gem5-dev]

Hi all,

I'm pretty sure https://gem5-review.googlesource.com/c/public/gem5/+/34984
is the breaking change on last night's build.

It's unfortunate how much time/effort supporting MIPS and other ISAs
takes...

Cheers,
Jason

On Tue, Nov 3, 2020 at 11:03 PM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/Nightly/118/display/redirect?page=changes>
>
> Changes:
>
> [gabe.black] arch: Clean up the __init__s in (Sub)OperandList.
>
> [davide.basilio.bartolini] configs: Do not require default options for
> caches
>
> [giacomo.travaglini] cpu, fastmodel: Remove the old getDTBPtr/getITBPtr
> virtual methods
>
> [giacomo.travaglini] arch-arm: Add el2Enabled cached variable
>
> [giacomo.travaglini] arch-arm: Fix implementation of TLBI_VMALL
> instructions
>
> [giacomo.travaglini] arch-arm: TlbEntry flush to be considered as
> functional lookup
>
> [giacomo.travaglini] arch-arm: Do not use _flushMva for TLBI IPA
>
> [yuhsingw] configs: Add dtb-gen to fs_bigLITTLE.py
>
>
> --
> [...truncated 68.77 KB...]
>  [SO PARAM] DMA_Controller -> MIPS/params/DMA_Controller.hh
>  [MAKE INC] MIPS/mem/ruby/common/BoolVec.hh -> protocol/BoolVec.hh
>  [MAKE INC] MIPS/mem/ruby/structures/CacheMemory.hh ->
> protocol/CacheMemory.hh
>  [MAKE INC] MIPS/mem/ruby/system/DMASequencer.hh ->
> protocol/DMASequencer.hh
>  [MAKE INC] MIPS/mem/ruby/structures/DirectoryMemory.hh ->
> protocol/DirectoryMemory.hh
>  [MAKE INC] MIPS/mem/ruby/system/HTMSequencer.hh ->
> protocol/HTMSequencer.hh
>  [SO PARAM] RubyPrefetcher -> MIPS/params/RubyPrefetcher.hh
>  [MAKE INC] MIPS/mem/ruby/structures/RubyPrefetcher.hh ->
> protocol/RubyPrefetcher.hh
>  [MAKE INC] MIPS/mem/ruby/system/Sequencer.hh -> protocol/Sequencer.hh
>  [MAKE INC] MIPS/mem/ruby/common/Set.hh -> protocol/Set.hh
>  [MAKE INC] MIPS/mem/ruby/structures/TimerTable.hh ->
> protocol/TimerTable.hh
>  [SO PARAM] RubyWireBuffer -> MIPS/params/RubyWireBuffer.hh
>  [MAKE INC] MIPS/mem/ruby/structures/WireBuffer.hh ->
> protocol/WireBuffer.hh
>  [MAKE INC] MIPS/mem/ruby/common/WriteMask.hh -> protocol/WriteMask.hh
>  [MAKE INC] MIPS/mem/ruby/slicc_interface/AbstractCacheEntry.hh ->
> protocol/AbstractCacheEntry.hh
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Controller.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Event.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_State.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_TBE.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DMA_Wakeup.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/DirectoryRequestType.cc -> .o
>  [SO PARAM] Directory_Controller -> MIPS/params/Directory_Controller.hh
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Controller.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Entry.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Event.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_State.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_TBE.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/Directory_Wakeup.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/HtmCallbackMode.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/HtmFailedInCacheReason.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/InvalidateGeneratorStatus.cc -> .o
>  [SO PARAM] L1Cache_Controller -> MIPS/params/L1Cache_Controller.hh
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Controller.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Entry.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Event.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_State.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_TBE.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Transitions.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/L1Cache_Wakeup.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/LinkDirection.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/LockStatus.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MachineType.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MaskPredictorIndex.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MaskPredictorTraining.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MaskPredictorType.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MemoryControlRequestType.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MemoryMsg.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MemoryRequestType.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/MessageSizeType.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/PrefetchBit.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/RequestMsg.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/RequestStatus.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/ResponseMsg.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/RubyAccessMode.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/RubyRequestType.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/SequencerMsg.cc -> .o
>  [ CXX] MIPS/mem/ruby/protocol/SequencerRequestType.cc -> .o
>  [   

[gem5-dev] Re: SimObject params() method

[Jason Lowe-Power via gem5-dev]

Another simple proposal:
- Remove params() from the API (with deprecation)
- Update objects that can easily be updated and remove the params()
calls/casts. I think this is most cases of the params use outside of the
constructor.
- Don't worry about the others that use the params() function in many
places that require deeper updates
- Update the documentation to say that the "best practice" is to not use
the param function
- In the future, make sure that new objects don't store the params object.

Cheers,
Jason

On Thu, Oct 22, 2020 at 8:51 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:

> Let me add to the plate a simple proposal though still a bit verbose and
> probably not that different from a manual cast
>
>
>
> Defining a template method in SimObject:
>
>
>
> *template *
>
> *Obj params()*
>
>
> *{ return static_cast(_params);*
>
> *Or more secure:*
>
> *param =  dynamic_cast(_params);*
>
> *assert(param);*
>
> *return param;*
>
> *}*
>
>
>
> And delegate the type specification on the client side:
>
>
>
> For example in my shiny new
>
>
>
> Class MyObject : public SimObject {}
>
>
>
> I would use
>
>
>
> auto p = params();
>
>
>
> You still have to type your param type so that doesn’t make it the best
> but I believe it’s the simplest one
>
>
>
> Giacomo
>
>
>
> *From:* Jason Lowe-Power via gem5-dev 
> *Sent:* 22 October 2020 16:26
> *To:* gem5 Developer List 
> *Cc:* Gabe Black ; Jason Lowe-Power <
> ja...@lowepower.com>
> *Subject:* [gem5-dev] Re: SimObject params() method
>
>
>
> Hey Gabe,
>
>
>
> Thanks for bringing this up. I have also been bothered by the lack of
> consistency with how params are used. I can't think of an example of when
> you need to store the params object. I would be all for getting rid of the
> params() function and updating the documentation to say that it's best
> practice to *not* save the params struct after the constructor. If some
> object had a good reason to go against this best practice, that would be
> OK, and we wouldn't need to enforce any specific design or pattern on these
> exceptions. I would prefer to remove the params() function than add more
> template magic.
>
>
>
> On Thu, Oct 22, 2020 at 1:18 AM Gabe Black via gem5-dev 
> wrote:
>
> Hi folks. I'm looking at the SimObject header, and I see a few things in
> there which are marked as part of the API and maybe shouldn't be.
> Specifically I'm talking about the Params typedef, and the params() method.
> There is also the _params member variable which I can see being a part of
> the API since it can be used by other classes to make their own params()
> function (more on that below), but the Params typedef is more or less an
> implementation detail, and the params() method is essentially worthless
> because it returns a SimObjectParams which doesn't have anything except the
> object's name in it, and you can already get that with the name() method.
>
>
>
> I agree. I think the typedef is useless and shouldn't be in the API. It's
> unfortunate that the API proposals didn't get more reviews. I think it's
> probably OK to just drop that from the API, but the params() function
> itself is going to need to be deprecated.
>
>
>
>
>
> *Params pattern*
>
>
>
> This gets to the whole Params params() pattern which is sporadically
> implemented in some SimObjects in gem5. This pattern is that a given
> SimObject subclass will define a Params typedef which corresponds to its
> Params struct type, and then also define a params() method which returns
> the _params from SimObject cast up to that type.
>
>
>
> The Params typedef itself primarily makes the definition of the
> constructor a little more legible, since the FullFooTypeForTheArmISAParams
> can be really verbose.
>
>
>
> I think verbose is fine. I would vote to abolish all params typedefs.
>
>
>
>
>
> Storing the params struct itself could theoretically serve the purpose of
> having a bunch of parameters and not having to create a member variable for
> each one, spend a bunch of text copying values over in the constructor,
> etc. I think most of the time this is unnecessary, but if an object has
> tons of values in it for some reason this could make sense.
>
>
>
> I don't think there are any examples of this in the codebase. I think in
> all cases the params data is copied into member variables. If there are
> cases where data isn't copied, I doubt it was with a strong reason in mind.
> The one exception to this might be Ruby, but it's an exception for all the
> wrong reasons ;).
>
&g

[gem5-dev] Re: SimObject params() method

[Jason Lowe-Power via gem5-dev]

Hey Gabe,

Thanks for bringing this up. I have also been bothered by the lack of
consistency with how params are used. I can't think of an example of when
you need to store the params object. I would be all for getting rid of the
params() function and updating the documentation to say that it's best
practice to *not* save the params struct after the constructor. If some
object had a good reason to go against this best practice, that would be
OK, and we wouldn't need to enforce any specific design or pattern on these
exceptions. I would prefer to remove the params() function than add more
template magic.

On Thu, Oct 22, 2020 at 1:18 AM Gabe Black via gem5-dev 
wrote:

> Hi folks. I'm looking at the SimObject header, and I see a few things in
> there which are marked as part of the API and maybe shouldn't be.
> Specifically I'm talking about the Params typedef, and the params() method.
> There is also the _params member variable which I can see being a part of
> the API since it can be used by other classes to make their own params()
> function (more on that below), but the Params typedef is more or less an
> implementation detail, and the params() method is essentially worthless
> because it returns a SimObjectParams which doesn't have anything except the
> object's name in it, and you can already get that with the name() method.
>

I agree. I think the typedef is useless and shouldn't be in the API. It's
unfortunate that the API proposals didn't get more reviews. I think it's
probably OK to just drop that from the API, but the params() function
itself is going to need to be deprecated.


>
> *Params pattern*
>
> This gets to the whole Params params() pattern which is sporadically
> implemented in some SimObjects in gem5. This pattern is that a given
> SimObject subclass will define a Params typedef which corresponds to its
> Params struct type, and then also define a params() method which returns
> the _params from SimObject cast up to that type.
>
> The Params typedef itself primarily makes the definition of the
> constructor a little more legible, since the FullFooTypeForTheArmISAParams
> can be really verbose.
>

I think verbose is fine. I would vote to abolish all params typedefs.


>
> Storing the params struct itself could theoretically serve the purpose of
> having a bunch of parameters and not having to create a member variable for
> each one, spend a bunch of text copying values over in the constructor,
> etc. I think most of the time this is unnecessary, but if an object has
> tons of values in it for some reason this could make sense.
>

I don't think there are any examples of this in the codebase. I think in
all cases the params data is copied into member variables. If there are
cases where data isn't copied, I doubt it was with a strong reason in mind.
The one exception to this might be Ruby, but it's an exception for all the
wrong reasons ;).


>
> The params() method then makes the _params member available with the
> appropriate type, so that all the FooParams members are accessible. It also
> makes the params struct accessible outside the object which is used in a
> place or two to read parameters without there needing to be a member in the
> object, and probably some sort of accessor to read it.
>
> There are two main problems with this system. First, when used, it adds a
> small but not trivial amount of boilerplate to any given class. Second,
> it's very sporadically implemented. I think in a lot of places it's there
> just because people aren't sure what it's for or if they need it, so they
> just put one there regardless. I think I've done that in the past.
>
> *Alternative*
>
> The existence of the Params type and the params() method could be
> partially eliminated by defining a templated params() method which took a
> SimObject reference and/or pointer as its first parameter. It could then
> figure out what Params struct went with that SimObject type using
> typedef/template magic set up by the Params building code, and then perform
> the appropriate cast.
>
> This has three downsides, two minor and one more serious. The minor one is
> that when a class uses this method internally, it would have to do
> something like params(this) instead of just params(). That's a fairly minor
> difference and not that big a deal. For external consumers that would be
> less of a problem since it would change from foo->params() to params(foo).
>
> The second minor issue is that the name params() is very short, and likely
> to collide with other names. We could define that with SimObject as a
> static method, but then that would make foo->params() turn into the more
> verbose SimObject::params(foo), or (and I haven't checked if this is legal
> syntax) the more odd looking foo->params(foo). The params() class can't be
> a non-static method, because then the type of "this" would be fixed by
> where it was defined, meaning it would not cast _params to the right type.
> I was not able to find any