[gem5-users] Re: ARM model - load instruction reads non-zero data from an address which was not written out prior (as per traces)

[Gabe Black via gem5-users]

Hi Tom. The data could have been written there as the result of a system
call which would not have executed as instructions in gem5, or it could
have been part of the initial binary. The address looks like a stack
address, so there's a good chance it came from a system call.

I'm just guessing, but I would assume that the memory data that's printed
is just printing the lowest byte because it's easy to know how to print a
single byte, and you can assume there is always at least one. The load is
probably loading the entire register even if it's only printing the first
byte.

On Tue, Mar 22, 2022 at 6:18 AM tom jose via gem5-users 
wrote:

> Hi ,
> I have attached a shorter Exec trace to this message.
> If we look at lines:
> line 4:   ldr   x1, [sp]: MemRead :
>  D=0x0001 A=0x7efe70
> line 74  :   ldr   x1, [x0]: MemRead :
>  D=0x0010 A=0x7efe90
> line 88  :   ldr   x3, [x8, #3840]: MemRead :  D=0x0001
> A=0x498f00
> line 92  :   ldr   x7, [x10, #3896]  : MemRead :  D=0x0001
> A=0x499f38
> line 152:   ldr   x28, [x0, #8]: MemRead :  D=0x004471e3
> A=0x7efe98
>
> Prior to these lines, there was no MemWrite to the corresponding address.
> Could you please provide an insight on how these addresses are loaded with
> these data? Is it related to the Symbol Table?
>
> Any information on the same would hugely help. I have attached the binary
> file for reference as well.
> Thanks in advance for your help.
> Regards,
> Tom
>
> On Mon, Mar 21, 2022 at 11:32 AM tom jose 
> wrote:
>
>> Hi ,
>> I was going through the load and store instructions from the GEM5 traces
>> and i could see that at some instances, the load instruction reads from an
>> address which was not written with valid data before. How is it reading
>> non-zero data from an address which was not written to? (From the GEM5
>> traces, there was no store done to the address to which we are trying to
>> read later on)
>> Example:
>> ldr   x28, [x0, #8]
>> lets say address = 0x7efe28
>> and this results in reading 0x004471e3 and storing in x28
>> But there was no memory write to 0x7efe28 done prior. So how are we
>> getting  0x004471e3?
>>
>> Also, I tried running the simulation with Debug-Flags as "All" and i
>> could see :
>> system.cpu_cluster.cpus.execute: Memory data[0]: 0xe3
>> the e3 is the lower bits in the data which is read. So how is the upper
>> bits obtained?
>>
>> details on the run:
>> ./build/ARM/gem5.opt --debug-flags=All --debug-file=bm1_a77_trace
>> ./configs/example/arm/starter_se.py --cpu minor --cpu-freq 3.0GHz
>> --mem-type DDR4_2400_8x8 ./tests/bm1
>>
>> So is there a way to identify which process is writing data to these
>> addresses? Can i get them printed out to the GEM5 traces?
>>
>> Please let me know if you require more information from my end.
>> Regards,
>> Tom
>>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Failed to run tlm-gem5 cosimualtion examples in util/tlm

[Gabe Black via gem5-users]

I just built the gem5 library following the instructions in the README and
it built fine. What namespace errors did you see? That sounds to me like
some part of your code base isn't up to date, since gem5 reworked its
namespaces a little while ago. I do see that the errors in your
undefined-refence-error.txt were for the RISCV build of gem5, and not the
ARM version like you have above.

When you build gem5 to integrate into systemc, then you need to enable CXX
configuration since it won't be able to run python to set up the
simulation, and you need to disable the internal systemc kernel with
USE_SYSTEMC=0, since it will conflict with the external one otherwise.

I have no idea what's causing that run time error.

Gabe

On Tue, Mar 22, 2022 at 2:32 AM Peng, Ziyang via gem5-users <
gem5-users@gem5.org> wrote:

> Hi,
>
> I am working on combine external sc_models to Gem5. So I try to follow the
> tlm tutorial in gem5/util/tlm/README.
>
> Following the building steps in the REDME file, there is no issue on the
> first two line and end with normal gem5.opt output:
>
> >cd ../../
>
> >/usr/bin/env python3 `which scons` build/ARM/gem5.opt
>
>
>
> During the next command, serval error reported such as namespace error.
> After I fixed them, the shared library can be generated correctly, but new
> link errors happened in next command. (See undefined-reference-error.txt)
>
> > scons --with-cxx-config --without-python --without-tcmalloc
> USE_SYSTEMC=0 build/ARM/libgem5_opt.so
>
> > cd util/tlm && /usr/bin/env python3 `which scons`
>
>
>
> I tried hard walking arround and have no ideal on how to get throught. In
> README, it told me –with-cxx-config and USE_SYSTEMC are mutually exclusive.
> So I tried build libgemt5_opt.so in this command, and build util/tlm again.
> It passed build.
>
> > scons  --without-tcmalloc USE_SYSTEMC=1 build/ARM/libgem5_opt.so
>
> > cd util/tlm && /usr/bin/env python3 `which scons`
>
> (I also updated util/tlm/src/sim_control.cc, comment line76:
>  gem5::cxxConfigInit();)
>
>
>
> Gem5.sc which should be the target file for scons is generated. So I moved
> to next step.
>
> > ../../build/ARM/gem5.opt conf/tlm_{master,slave}.py
>
> > build/examples/{master,slave}_port/gem5.sc m5out/config.ini -e 100
>
>
>
> Then I meet a new question, here is the output: (see run-time-error.txt
> for detail)
>
>  EventQueue Dump  (cycle 0)
>
> 
>
> 
>
> 
>
> Config problem in sim object root: Can't find sim object
>
> double free or corruption (fasttop)
>
> Program aborted at tick 0 --- END LIBC BACKTRACE ---
>
> Aborted
>
> --- BEGIN LIBC BACKTRACE ---
>
> …
>
> --- END LIBC BACKTRACE ---
>
> Aborted
>
>
>
> I think it might be caused by cxx-config is disabled? But I have no ideal to 
> fix it. I guess it may be a common issue for those who’s trying to get 
> through this tutorial. Any advice on using the tlm utility of Gem5 will be 
> great helpful.
>
>
>
> Thanks + regards,
>
>
>
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: M5 Fs utility workbegin

[Gabe Black via gem5-users]

I don't think we ever transitioned from an assembly based mechanism to a C
based one, since we have always (as far as I know) used both, assembly to
actually invoke the call into gem5, and C to provide a friendly
interface/wrapper around the assembly. That said, yes, it looks like work
begin and work end are just not in the utility, but they are in the header
files and are implemented in gem5 itself.

Looking at this again triggered a vague memory where I think these didn't
make sense being called from the utility for some reason? Maybe they only
make sense in SE mode, or they should be called from code directly instead
of from a shell or script? I'm not very familiar with them so I can't say
for sure, but I vaguely remember there was something like that.

Gabe

On Wed, Mar 9, 2022 at 2:45 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:

> Hi George,
>
>
>
> Thanks for reporting this, I noticed the same issue. When we transitioned
> from the old m5 subsystem (assembly based) to the new C based one we forgot
> to provide an implementation for workbegin and workend I suppose. Putting
> Gabe on CC
>
>
>
> Kind Regards
>
>
>
> Giacomo
>
>
>
> *From: *George Michelogiannakis via gem5-users 
> *Date: *Wednesday, 9 March 2022 at 06:54
> *To: *gem5-users@gem5.org 
> *Cc: *George Michelogiannakis 
> *Subject: *[gem5-users] M5 Fs utility workbegin
>
> Hello Gem5 community,
>
>
>
> I'm trying to use the M5 utility meant for full system mode to signal work
> begin and end. I see in the documentation that the utility supports these
> parameters:
>
>
>
>- workbegin: Cause an exit evet of type, “workbegin”, that could be
>used to mark the begining of an ROI.
>- workend: Cause an exit event of type, “workend”, that could be used
>to mark the termination of an ROI.
>
> But when I run the utility in X86 after compiling it for X86 those two
> options aren't available as commands. There is a "fail" option with a
> parameter that isn't mentioned in the documentation. Is that the way to
> simulate workbegin and workend?
>
>
>
> Thanks in advance,
>
>   George M
>
>
>
>
> 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-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Difference between XBase and XURa .isa operands

[Gabe Black via gem5-users]

Those operands are set up in arch/arm/isa/operands.isa, and get their value
using very different indices. XBase uses the "base" field of the
instruction object, while XURa uses "ura". The "u" in "ura" most likely
comes from the fact that that register is "register a" as intended for use
in microcode. The "base" register is most likely an architecturally defined
register which is encoded in or implied by the actual instruction.

On Fri, Feb 11, 2022 at 9:09 PM Jason Z via gem5-users 
wrote:

> Hey Pedro,
>
> I ran into a similar issue with naming like that with trying to create new
> instructions, and the best I could tell it seems like the XUR are for
> microops, but I'm honestly just guessing based on what I saw previously,
> and I ended up just using XBase since I was creating a store instruction
> and modeling it after an STRX64 instruction, so I tried to stick to that
> framework...
>
> Sorry I don't have a better answer, but if anyone else has any insight to
> any reference to their meanings, I'd be interested in it as well...
>
> Respectfully,
>
> Jason Z.
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Destructor for BaseCPU

[Gabe Black via gem5-users]

*Very* superficially looking at this (just at what's in the emails here),
you might want to make sure the BaseCPU destructor is virtual, or at least
the destructor of a base class is. If it isn't currently, the destructor of
SimObject should probably be virtual. I don't know for sure whether that
would cause your problem, but that would be the first thing I would check.
I know not having a virtual destructor can cause problems where things
don't get cleaned up properly.

That said, if you just want something generic to happen at the end of the
simulation (vs something to clean up some new part of BaseCPU),
registerExitCallback that Jason pointed out is probably the way to go.

Gabe

On Wed, Feb 9, 2022 at 5:24 PM Jason Lowe-Power via gem5-users <
gem5-users@gem5.org> wrote:

> Hi Scott,
>
> If you want something to execute before gem5 is completed, you can call
> `registerExitCallback`. See
> http://doxygen.gem5.org/release/current/namespacegem5.html#abcf3056836ee522620e5b14d9392ea87
>
> I *think* that will solve your problem, but let me know if not. I don't
> think there's a clean way to have a SimObject's destructor guaranteed to be
> called.
>
> Cheers,
> Jason
>
> On Wed, Feb 9, 2022 at 4:47 PM Scott Blankenberg via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hello,
>>
>> In src/cpu/base.cc we have the following destructor:
>>
>> BaseCPU::~BaseCPU()
>> {
>> }
>>
>> By default nothing is inside of it. However, when I put code inside, it
>> does not seem to be executed at any point. Based on some previous threads I
>> have seen on the forums, it seems that the destructor for BaseCPU is not
>> being called at the end of the simulation.
>>
>> Has anyone found a way to make sure this destructor is called when the
>> simulation ends?
>>
>> Similarly, has anyone written a tracer which is a subclass of InstTracer
>> that has a destructor which is successfully called at the end of
>> simulation?
>>
>> Basically my objective is to make sure the destructor to my customTracer
>> is called at the end of the simulation.
>>
>> Thanks,
>>
>> Scott Blankenberg
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: gem5 build extra

[Gabe Black via gem5-users]

Hi Yao, please include the actual error message when asking about these
sorts of things, since without it it's much harder to tell what happened.

That said, this sounds like a problem with {} brackets somewhere in an
included file, where things ended up inside scopes and/or namespaces they
weren't supposed to be.

Gabe

On Tue, Dec 28, 2021 at 12:43 AM yaogang via gem5-users 
wrote:

> Hi,
>
>
>
> I have a device which incorporated another model in the GEM5 interface.
> This is put into another directory and I use EXTRAS to include the
> directory. It seems working fine until compiling to this extra
>
>
>
>
>
> #include "dev/io_device.hh"
>
>
>
> class BaseGpu : public BasicPioDevice
>
>
>
> It appears the gem5 struggle to recognize the BasicPioDevice as the base
> class. Where it is located of the BasicPioDevice?
>
>
>
>
>
>
>
> Regards
>
> Yao
>
>
>
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: gem5

[Gabe Black via gem5-users]

Hi Yao, please copy text into emails and don't use screenshots. What SCons
is doing is that it's trying to compile a small program which includes
sys/mman.h, links against either no additional library or the "rt" library,
and includes a call to shm_open().

https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/mem/SConsopts#35

If that does not compile for some reason, then gem5 will print that
message. You can find a log of the output of when gem5 tried to compile
that program in your build directory in build/scons_config.log where you
can check for any error messages.

I'm not sure exactly what you mean by adding it to your path variable, but
if you mean PATH, that's not how include files are found. Since this also
potentially tries tries to link against librt, it could be that it finds
the header just fine but can't link against the library for some reason. In
any case, if you look at that log file, it should give you an error message
which will help you get started figuring this out.

Gabe

On Thu, Jan 6, 2022 at 2:27 AM yaogang via gem5-users 
wrote:

> Hi,
>
>
>
> My gem5 used to work fine but suddenly can not build due to the following
> warning I  think( it will complain shm_open not finding the library)
>
>
>
>
>
>
>
> I set the /usr/include into my path variable and it should be there . I
> saw there is a jira ticket on it but it doesn’t seem to solve the issue
> https://gem5-review.googlesource.com/c/public/gem5/+/47659/7..8
>
>
>
> Regards
>
> Yao
>
>
>
>
>
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Compiling gem5 on ARM Based Host

[Gabe Black via gem5-users]

As far as why opt is smaller than fast, that could be because the compiler
is optimizing more aggressively for performance at the cost of binary size
with those settings? Just a guess.

Gabe

On Fri, Jan 7, 2022 at 10:45 AM Thomas, Samuel via gem5-users <
gem5-users@gem5.org> wrote:

> Hi Jason,
>
> Weirdly, only a few fast binaries exceed 5MB in size:
>
> 5.6Mbuild/ARM/arch/arm/generated/generic_cpu_exec_2.fo
> 6.0Mbuild/ARM/arch/arm/generated/generic_cpu_exec_5.fo
> 6.0Mbuild/ARM/arch/arm/generated/inst-constrs-1.fo
> 6.1Mbuild/ARM/arch/arm/generated/generic_cpu_exec_4.fo
> 6.8Mbuild/ARM/arch/arm/generated/generic_cpu_exec_3.fo
> 8.0Mbuild/ARM/arch/arm/generated/inst-constrs-2.fo
> 9.5Mbuild/ARM/arch/arm/linux/se_workload.fo
> 15M build/ARM/arch/arm/generated/generic_cpu_exec_1.fo
> 16M build/ARM/arch/arm/generated/generic_cpu_exec_6.fo
> 45M build/ARM/arch/arm/generated/inst-constrs-3.fo
>
> Perhaps even weirder is that the “opt” target compiles and links
> correctly. Could you speculate as to why this may be the case?
>
> At least for the purposes of my project, I can use gem5.opt - so my issue
> is resolved even if the larger problem is still open. Thanks for your help!
>
> Best,
> Sam
>
> On Fri, Jan 7, 2022 at 12:57 PM Jason Lowe-Power 
> wrote:
> >
> > Hi Sam,
> >
> > I was wondering when this problem would come up again. Here's a Jira
> issue to track the same thing in a different context:
> https://gem5.atlassian.net/browse/GEM5-1003
> >
> > Could you do something like `du -h build/ | sort -h` to see what objects
> are the biggest? I'm going to guess that there are ~100+ .o files that are
> more than 20MB. At least, that was the case with RISC-V when I ran into
> this problem.
> >
> > We never did figure out why so many files were so big. The hypothesis
> was something to do with pybind, but no one was able to provide solid
> evidence of this. We did find that using a different compiler version,
> having different libraries installed on the system, and removing
> unnecessary includes seemed to make a difference, though. You may be able
> to use this to at least work around the problem.
> >
> > Here's the changeset that fixed it for RISC-V. However, I doubt it's
> going to fix it again in your case.
> https://gem5-review.googlesource.com/c/public/gem5/+/46820
> >
> > You can also try this abandoned change, though it probably won't apply
> cleanly or straightforwardly:
> https://gem5-review.googlesource.com/c/public/gem5/+/46380
> >
> > Cheers,
> > Jason
> >
> > On Fri, Jan 7, 2022 at 9:39 AM Samuel Thomas via gem5-users <
> gem5-users@gem5.org> wrote:
> >>
> >> Hi all,
> >>
> >> I typically work on an x86 machine, but I’m trying to submit gem5 jobs
> to a cluster that runs ARM based hosts. Each source script compiles, I run
> into the following error when linking:
> >>
> >> /tmp/gem5.fast.unstripped.PI0JsN.ltrans45.ltrans.o: in function
> `ArmV8KvmCPU::updateThreadContext()':
> >> :(.text+0x25884): relocation truncated to fit:
> R_AARCH64_ADR_PREL_PG_HI21 against `.rodata’collect2: error: ld returned 1
> exit status
> >>
> >> It makes sense that the .text segment of the binary will be very large,
> and I see that there is a note on gem5’s architecture support documentation
> that it is out dated. I assume that I can try disassembling the binary and
> seeing if there is an alternative command to avoid this particular linker
> error, but I figured I would also ping the mailing list to see if there is
> an easier fix as well.
> >>
> >> Thank you all for your help!
> >>
> >> Best,
> >> Sam
> >> ___
> >> gem5-users mailing list -- gem5-users@gem5.org
> >> To unsubscribe send an email to gem5-users-le...@gem5.org
> >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Aarch64 stack access strangeness in SE mode.

[Gabe Black via gem5-users]

In SE mode, there are going to be at least small (and perhaps large)
differences between how a program runs in gem5 vs a real system. Some of
those will be from system calls which are not implemented exactly right in
gem5, or are slightly different because they're actually happening on your
host machine. Some will inevitably be different, like if the program checks
the system time. Comparing execution one to one like this can help find
bugs, but it has to be very carefully tuned and may never give usable
information. That's also assuming that all the system calls the program
uses are even implemented in gem5 to begin with.

Gabe

On Wed, Jan 5, 2022 at 9:47 PM Balazs Gerofi via gem5-users <
gem5-users@gem5.org> wrote:

> Dear gem5 users/devs,
>
> We are using gem5 for some architectural exploration on top of the Fujitsu
> A64FX chip (based on the O3_Arm model).
> We are running into a mysterious error, where a relatively simple program
> fails with a page fault on gem5, but it runs fine on the real hardware.
> With a few extensions to gem5's gdb stub to make it work in SE mode we
> narrowed down the issue to the following problem.
>
> The application code around the failure is:
>
>0x004041ec <+1828>:  b.le0x4046d4 
>0x004041f0 <+1832>:  and x14, x10, #0x7
>0x004041f4 <+1836>:  adrpx13, 0x422000 
>0x004041f8 <+1840>:  ldr x0, [x13, #160]
>0x004041fc <+1844>:  neg x17, x14
>0x00404200 <+1848>:  str x17, [sp, #120]
>0x00404204 <+1852>:  ldr w17, [sp, #104]
>0x00404208 <+1856>:  sxtwx12, w2
>
> Setting a breakpoint to 0x00404208, we observe the following
> register state:
> Breakpoint 2, 0x00404208 in diff () at
> omp-tasks/alignment/alignment_for/alignment.c:338
> 338   RR[N] = hh = t = t-gh;
> (gdb) i r
> x0 0x432380440
> x1 0x4383654424549
> x2 0x4b75
> x3 0x2638
> x4 0xffa6  4294967206
> x5 0x0 0
> x6 0x4210844329604
> x7 0x7e0b68549755685736
> x8 0x2638
> x9 0xffdb  4294967259
> x100x2638
> x110x0 0
> x120xffda  4294967258
> x130x4220004333568
> x140x6 6
> x150x7cd1f0549755605488
> x160x0 0
> x170x0 0
> x180x7d1fe8549755625448
> x190xfe4f  4294966863
> x200xf9bb  4294965691
> x210xfd31  4294966577
> x220x43aeb84435640
> x230xfc23  4294966307
> x240xf9bb  4294965691
> x250x1 1
> x260x956   2390
> x270x2537
> x280x7d6ecc549755645644
> x290x7dbcec549755665644
> x300x0 0
> sp 0x7cd1700x7cd170
> pc 0x4042080x404208 
> cpsr   0x0 [ EL=0 ]
> fpsr   
> fpcr   
>
> As seen from the code above, the previous instruction (at
> 0x00404204) loads $sp+104 into $w17, however, the memory contents
> and the register value differ:
> (gdb) p *(int *)($sp+104)
> $651 = 1
> (gdb) p $w17
> $652 = 0
>
> Setting a breakpoint to the same location on real HW we get 1 in $w17 (as
> expected based on the memory content).
>
> Any idea/suggestion what might be causing this and how we could
> potentially fix it?
>
>
> Thanks and bests,
> Balazs
>
> -
> Balazs Gerofi
> Research Scientist
> High-Performance Artificial Intelligence Systems Research Team
> RIKEN Center for Computational Science, Japan
> https://bgerofi.github.io/
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: some problem about IO device's write or read function's return tick

[Gabe Black via gem5-users]

I think this may not be quite right, or I'm misunderstanding what Jason is
saying. The Tick number returned in atomic mode is supposed to approximate
how long the access took, and it's up to the caller to do something with
that. Often the caller does throw away the number, but that's what it's
supposed to mean.

In timing mode, there is no returned Tick value, and it's up to the device
servicing the access (the thing *implementing* the read or write) to delay
the response to the access by whatever length of time it would take. This
is also done by all the steps along the way as the access is propagated, so
the interconnect, caches, etc. Cumulatively those all add up to how long
the access takes, which is what the atomic mode return value is supposed to
approximate.

When using atomic mode, performance is very loosely modeled. When using
timing mode, your device should implement delays by scheduling events for
in the future which actually send a response to a given access.

Gabe

On Mon, Dec 27, 2021 at 3:59 PM Jason Lowe-Power via gem5-users <
gem5-users@gem5.org> wrote:

> Hello,
>
> If you are using *atomic* memory mode, then the tick number is mostly
> ignored. If you're using *timing* mode, then the tick number should be used
> by whatever object calls the read/write function and the delay is inserted
> there. Also, if your program doesn't have a direct dependence on the I/O
> device, the latency may be hidden. Enabling various debug flags should help
> you track this down.
>
> Cheers,
> Jason
>
> On Thu, Dec 23, 2021 at 8:58 AM lin via gem5-users 
> wrote:
>
>> Hi
>>
>> I make an IO device link to the membus and complete the Tick
>> read(PacketPtr pkt) and the write() function .But I find that no matter how
>> many ticks ( the funciton return n*tick) I set,the simSeconds no change.If
>> it normal?If not , what can I do to set the return ticks of the read() or
>> write() function?
>>
>> Thanks everyone!
>>
>>
>>
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: some problem about util/tlm in gem5v20.1.0.5

[Gabe Black via gem5-users]

The issue in Jira is a known issue where the cxx config mechanism works in
a fundamentally not quite correct way, and while it usually works out, it
doesn't for the systemc stuff. You can use the cxx config mechanism or the
(built in) systemc, but not both.

Given that these instructions build gem5 as a whole into a systemc
simulation which will have its own systemc kernel already, you really
wouldn't want to have another competing systemc kernel inside gem5 also, so
it's not really a limitation to have to choose between cxx config and
systemc, since in this case you need the cxx config and would definitely
want to disable the built in systemc support.

What I built (and what is exercised regularly at Google) is to run systemc
models inside of gem5 using its own built in systemc kernel, which is
distinct and separate from this other method. As far as I know there are no
tests for the gem5-as-a-black-box-inside-systemc setup, so it's not *that*
surprising that it's bitrot a bit. I haven't looked at what's going wrong,
but there's a good chance it will be fairly easy to fix.

Gabe

On Mon, Dec 27, 2021 at 6:15 PM Bobby Bruce  wrote:

> Also, in looking into this problem I encountered the following bug:
>
> https://gem5.atlassian.net/browse/GEM5-1141
>
> i haven't dived much deeper than what's logged in the Jira.
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Mon, Dec 27, 2021 at 3:07 PM Bobby Bruce  wrote:
>
>> You are right, the instructions provided in the utils/tlm/README will not
>> generate the gem5.sc file.
>>
>> @gabe: How do you go about doing this?
>>
>> --
>> Dr. Bobby R. Bruce
>> Room 3050,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>>
>>
>> On Mon, Dec 20, 2021 at 11:19 PM lin via gem5-users 
>> wrote:
>>
>>> Hi
>>> I read the README in util/tlm and follow the  following command:
>>> >cd ../..
>>> >scons build/ARM/gem5.opt
>>> >scons --with-cxx-config --without-python --without-tcmalloc
>>> build/ARM/libgem5_opt.so
>>> >cd util/tlm
>>>
>>> Then I run the command:
>>>
>>> >../../build/ARM/gem5.opt conf/tlm_slave.py
>>>
>>> It report that:
>>>
>>>   fatal: Can't find port handler type 'tlm_master', just like the README 
>>> said.
>>>
>>> But when I run the following command:
>>>
>>> >build/examples/master_port/gem5.sc m5out/config.ini -e 100
>>>
>>>
>>> The error is that
>>>
>>> bash:build/examples/master_port/gem5.sc :No such file or directory.
>>>
>>>
>>> How can I solve this problem?
>>>
>>> Thanks!
>>>
>>> ___
>>> gem5-users mailing list -- gem5-users@gem5.org
>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Questions about simulating ARM SVE with gem5

[Gabe Black via gem5-users]

Hi Xiaokang.

1. All of those CPU models will be able to execute the same set of
instructions since they use the same instruction implementations. The HPI
CPU is really just the O3CPU with some of the configuration set a certain
way, I think.
2. I don't know for sure, but there are some constants related to it in
src/arch/arm/regs/vec.hh.
3. SE mode vs FS mode isn't really related to the benchmark's size, it's
more about how much the benchmark or other program depends on the operating
system, and how complex its interactions are. Also, SE mode is usually a
little simpler to set up since you don't need to build a disk image, get
the OS set up, etc, but FS is more realistic since it actually simulates
the OS components and hardware.

Gabe

On Wed, Dec 8, 2021 at 1:54 AM Xiaokang Fan via gem5-users <
gem5-users@gem5.org> wrote:

> Hi guys,
>
> I am new to the gem5 simulator. I have a few questions about simulating
> ARM SVE using gem5:
>
> 1. Which cpu model should I use? DerivO3CPU, MinorCPU, O3CPU, HPI? Or
> another cpu model?
> 2. How do I set the sve vector length?
> 3. Which simulation mode should I use if I want to run some large
> benchmarks like spec, SE mode or FS mode?
>
> Thanks a lot!
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: how gem5 loads binaries on SE mode?

[Gabe Black via gem5-users]

Hi Hiromichi, there isn't really any documentation for how that system
works. You can find much of the code for it in the src/base/loader
directory, and in the Process subclasses for the different architectures in
src/arch/.

Gabe

On Wed, Dec 8, 2021 at 11:47 PM hiromichi.haneda--- via gem5-users <
gem5-users@gem5.org> wrote:

> Hello, everyone.
>
> I'm interested in memory encryption. I am interested in memory encryption,
> and I came across the problem of memory initialization. I would like to
> encrypt the binary in 128 bit units when it is loaded into the memory.
> Is there any document on how gem5 loads binaries on SE mode?
>
> Thank you.
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Guest Binaries for X86

[Gabe Black via gem5-users]

Hi James, there are not. I put a little time into making it easier to build
your own images with known good configurations and tools, but there's a lot
to do there still.

Gabe

On Wed, Dec 8, 2021 at 10:49 PM jamesbondtia--- via gem5-users <
gem5-users@gem5.org> wrote:

> Hi,
>
> I noticed that the gem5 website only has guest binaries for ARM to run in
> full system mode, which are up to date and work well.
> I wonder if it is possible to have Full System guest Binaries for X86 and
> the other architectures.
>
> Best
>
> James
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: ARM Microop vs Macroop

[Gabe Black via gem5-users]

Hi Jason. Some instructions need to be broken down into microops because
they might not be realistic to do all at once, or because they need to
perform multiple memory accesses. Other instructions don't, so they're
implemented as regular instructions which are not broken down into microops.

Gabe

On Wed, Dec 8, 2021 at 4:22 PM Jason Z via gem5-users 
wrote:

> Hello Everyone,
>
> I hope you are all doing well!
>
> I am trying to implement a store instruction in ARM that has Post-index,
> Pre-index, and Signed-offset versions, and I'm using a normal store (i.e.,
> STRX64) as a model to start, but I am running into some confusion with
> regard to which versions are microops, macroops, and neither, so I was
> wondering if anyone had any clarification on the issue
>
> I am seeing information about the differences in X86, but I haven't been
> able to find anything about it in ARM
>
> Here is what I've gathered so far:
>
> STRX64_REG   →neither (not IsMicroop/IsMacroop)
> STRX64_PRE   →IsMacroop (uses microop MicroAddXiUop)
> STRX64_POST →IsMacroop (uses microop MicroAddXiUop)
> STRX64_IMM→neither (not IsMicroop/IsMacroop)
> STRX64_PREAcc →IsMicroop
> STRX64_POSTAcc   →IsMicroop
>
> From my understanding, the macroop is broken down into microops, but I am
> confused as to why some of the others are listed as microops and some are
> listed as neither. If anyone has any insight into how these are different
> and how they are used, it would be greatly appreciated
>
> Thank you for your time!
>
> Respectfully,
>
> Jason Z
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Unrecognized register class when using the "Exec" debug flag

[Gabe Black via gem5-users]

+Bobby Bruce 

On Fri, Dec 3, 2021 at 6:45 PM Gabe Black  wrote:

> I think you want this change:
>
> https://gem5-review.googlesource.com/c/public/gem5/+/49183
>
> On Fri, Dec 3, 2021 at 4:26 PM Nirmit Jallawar  wrote:
>
>> Hi Gabe,
>>
>>
>>
>> Here is the backtrace using gdb:
>>
>>
>>
>> 7335000: system.cpu: T0 : 0x7801bbdd @_end+140737354234813. 4 :
>> CALL_NEAR_I : wrip   t7, t1 : IntAlu :
>>
>> 7447000: system.cpu: T0 : 0x7801d080 @_end+140737354240096: hint
>>
>> 7447000: system.cpu: T0 : 0x7801d080 @_end+140737354240096. 0 :
>> HINT_NOP : fault   NoFault : No_OpClass :
>>
>> 7447000: system.cpu: T0 : 0x7801d084 @_end+140737354240100: mov
>> eax, 0xc
>>
>> 7447000: system.cpu: T0 : 0x7801d084 @_end+140737354240100. 0 :
>> MOV_R_I : limm   eax, 0xc : IntAlu :  D=0x000c
>>
>> build/X86/arch/x86/insts/static_inst.cc:254: panic: Unknown register
>> class: 1500478240
>>
>> Memory Usage: 643980 KBytes
>>
>>
>>
>> Program received signal SIGABRT, Aborted.
>>
>> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
>>
>> 50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>>
>>
>>
>> (gdb) bt
>>
>> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
>>
>> #1  0x76bcb859 in __GI_abort () at abort.c:79
>>
>> #2  0x557269b8 in gem5::Logger::exit_helper (this=0x59b34a20)
>> at build/X86/base/logging.hh:124
>>
>> #3  0x5574b537 in gem5::X86ISA::X86StaticInst::printReg (os=...,
>> reg=..., size=4) at build/X86/arch/x86/insts/static_inst.cc:254
>>
>> #4  0x5584a934 in
>> gem5::X86ISAInst::SyscallInst::generateDisassembly[abi:cxx11](unsigned
>> long, gem5::loader::SymbolTable const*) const (this=0x596f6e70,
>> PC=140737354256521, symtab=0x57fb2ea0 )
>> at build/X86/arch/x86/generated/decoder-ns.cc.inc:81
>>
>> #5  0x55e0d881 in
>> gem5::StaticInst::disassemble[abi:cxx11](unsigned long,
>> gem5::loader::SymbolTable const*) const (this=0x596f6e70,
>> pc=140737354256521, symtab=0x57fb2ea0 )
>> at build/X86/cpu/static_inst.cc:79
>>
>> #6  0x55e054cd in gem5::Trace::ExeTracerRecord::traceInst
>> (this=0x59a39b90, inst=..., ran=true) at build/X86/cpu/exetrace.cc:105
>>
>> #7  0x55e05c22 in gem5::Trace::ExeTracerRecord::dump
>> (this=0x59a39b90) at build/X86/cpu/exetrace.cc:177
>>
>> #8  0x55ec4b91 in gem5::o3::Commit::commitHead
>> (this=0x5949b880, head_inst=..., inst_num=0) at
>> build/X86/cpu/o3/commit.cc:1273
>>
>> #9  0x55ec2e43 in gem5::o3::Commit::commitInsts
>> (this=0x5949b880) at build/X86/cpu/o3/commit.cc:1020
>>
>> #10 0x55ec249d in gem5::o3::Commit::commit (this=0x5949b880)
>> at build/X86/cpu/o3/commit.cc:906
>>
>> #11 0x55ec0a3b in gem5::o3::Commit::tick (this=0x5949b880) at
>> build/X86/cpu/o3/commit.cc:663
>>
>> #12 0x55ed4254 in gem5::o3::CPU::tick (this=0x59498000) at
>> build/X86/cpu/o3/cpu.cc:522
>>
>> #13 0x55ed0995 in gem5::o3::CPUoperator()(void)
>> const (__closure=0x59498370) at build/X86/cpu/o3/cpu.cc:76
>>
>> #14 0x55edb884 in std::_Function_handler> gem5::o3::CPU::CPU(const gem5::O3CPUParams&):: >::_M_invoke(const
>> std::_Any_data &) (__functor=...) at
>> /usr/include/c++/9/bits/std_function.h:300
>>
>> #15 0x557570ae in std::function::operator()() const
>> (this=0x59498370) at /usr/include/c++/9/bits/std_function.h:688
>>
>> #16 0x557543d0 in gem5::EventFunctionWrapper::process
>> (this=0x59498338) at build/X86/sim/eventq.hh:1141
>>
>> #17 0x56531f5c in gem5::EventQueue::serviceOne
>> (this=0x587fbd40) at build/X86/sim/eventq.cc:223
>>
>> #18 0x56559cc3 in gem5::doSimLoop (eventq=0x587fbd40) at
>> build/X86/sim/simulate.cc:219
>>
>> #19 0x565598c3 in gem5::simulate
>> (num_cycles=18446744073709551615) at build/X86/sim/simulate.cc:132
>>
>> #20 0x564feb48 in pybind11::detail::argument_loader> long>::call_impl> gem5::GlobalSimLoopExitEvent* (*&)(unsigned long), 0ul,
>> pybind11::detail::void_type>(gem5::GlobalSimLoopExitEvent* (*&)(unsigned
>> long), std::integer_sequence,
>> pybind11::detail::void_type&&) && (this=0x7fffd028, f=@0x58dd00c8:
>> 0x56559589 ) at
>> ext/pybind11/include/pybind11/cast.h:2042
>>
>> #21 0x564fce1e in pybind11::detail::argument_loader> long>::call> gem5::GlobalSimLoopExitEvent* (*&)(unsigned
>> long)>(gem5::GlobalSimLoopExitEvent* (*&)(unsigned long)) &&
>> (this=0x7fffd028, f=@0x58dd00c8: 0x56559589
>> ) at
>> ext/pybind11/include/pybind11/cast.h:2014
>>
>> #22 0x564f9183 in
>> pybind11::cpp_function::initialize> (*&)(unsigned long), gem5::GlobalSimLoopExitEvent*, unsigned long,
>> pybind11::name, pybind11::scope, pybind11::sibling,
>> pybind11::arg_v>(gem5::GlobalSimLoopExitEvent* (*&)(unsigned long),
>> gem5::GlobalSimLoopExitEvent* (*)(unsigned long), pybind11::name const&,
>> pybind11::scope const&, 

[gem5-users] Re: Unrecognized register class when using the "Exec" debug flag

[Gabe Black via gem5-users]

I think you want this change:

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

On Fri, Dec 3, 2021 at 4:26 PM Nirmit Jallawar  wrote:

> Hi Gabe,
>
>
>
> Here is the backtrace using gdb:
>
>
>
> 7335000: system.cpu: T0 : 0x7801bbdd @_end+140737354234813. 4 :
> CALL_NEAR_I : wrip   t7, t1 : IntAlu :
>
> 7447000: system.cpu: T0 : 0x7801d080 @_end+140737354240096: hint
>
> 7447000: system.cpu: T0 : 0x7801d080 @_end+140737354240096. 0 :
> HINT_NOP : fault   NoFault : No_OpClass :
>
> 7447000: system.cpu: T0 : 0x7801d084 @_end+140737354240100: mov
> eax, 0xc
>
> 7447000: system.cpu: T0 : 0x7801d084 @_end+140737354240100. 0 :
> MOV_R_I : limm   eax, 0xc : IntAlu :  D=0x000c
>
> build/X86/arch/x86/insts/static_inst.cc:254: panic: Unknown register
> class: 1500478240
>
> Memory Usage: 643980 KBytes
>
>
>
> Program received signal SIGABRT, Aborted.
>
> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
>
> 50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>
>
>
> (gdb) bt
>
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
>
> #1  0x76bcb859 in __GI_abort () at abort.c:79
>
> #2  0x557269b8 in gem5::Logger::exit_helper (this=0x59b34a20)
> at build/X86/base/logging.hh:124
>
> #3  0x5574b537 in gem5::X86ISA::X86StaticInst::printReg (os=...,
> reg=..., size=4) at build/X86/arch/x86/insts/static_inst.cc:254
>
> #4  0x5584a934 in
> gem5::X86ISAInst::SyscallInst::generateDisassembly[abi:cxx11](unsigned
> long, gem5::loader::SymbolTable const*) const (this=0x596f6e70,
> PC=140737354256521, symtab=0x57fb2ea0 )
> at build/X86/arch/x86/generated/decoder-ns.cc.inc:81
>
> #5  0x55e0d881 in
> gem5::StaticInst::disassemble[abi:cxx11](unsigned long,
> gem5::loader::SymbolTable const*) const (this=0x596f6e70,
> pc=140737354256521, symtab=0x57fb2ea0 )
> at build/X86/cpu/static_inst.cc:79
>
> #6  0x55e054cd in gem5::Trace::ExeTracerRecord::traceInst
> (this=0x59a39b90, inst=..., ran=true) at build/X86/cpu/exetrace.cc:105
>
> #7  0x55e05c22 in gem5::Trace::ExeTracerRecord::dump
> (this=0x59a39b90) at build/X86/cpu/exetrace.cc:177
>
> #8  0x55ec4b91 in gem5::o3::Commit::commitHead
> (this=0x5949b880, head_inst=..., inst_num=0) at
> build/X86/cpu/o3/commit.cc:1273
>
> #9  0x55ec2e43 in gem5::o3::Commit::commitInsts
> (this=0x5949b880) at build/X86/cpu/o3/commit.cc:1020
>
> #10 0x55ec249d in gem5::o3::Commit::commit (this=0x5949b880)
> at build/X86/cpu/o3/commit.cc:906
>
> #11 0x55ec0a3b in gem5::o3::Commit::tick (this=0x5949b880) at
> build/X86/cpu/o3/commit.cc:663
>
> #12 0x55ed4254 in gem5::o3::CPU::tick (this=0x59498000) at
> build/X86/cpu/o3/cpu.cc:522
>
> #13 0x55ed0995 in gem5::o3::CPUoperator()(void)
> const (__closure=0x59498370) at build/X86/cpu/o3/cpu.cc:76
>
> #14 0x55edb884 in std::_Function_handler gem5::o3::CPU::CPU(const gem5::O3CPUParams&):: >::_M_invoke(const
> std::_Any_data &) (__functor=...) at
> /usr/include/c++/9/bits/std_function.h:300
>
> #15 0x557570ae in std::function::operator()() const
> (this=0x59498370) at /usr/include/c++/9/bits/std_function.h:688
>
> #16 0x557543d0 in gem5::EventFunctionWrapper::process
> (this=0x59498338) at build/X86/sim/eventq.hh:1141
>
> #17 0x56531f5c in gem5::EventQueue::serviceOne
> (this=0x587fbd40) at build/X86/sim/eventq.cc:223
>
> #18 0x56559cc3 in gem5::doSimLoop (eventq=0x587fbd40) at
> build/X86/sim/simulate.cc:219
>
> #19 0x565598c3 in gem5::simulate (num_cycles=18446744073709551615)
> at build/X86/sim/simulate.cc:132
>
> #20 0x564feb48 in pybind11::detail::argument_loader long>::call_impl gem5::GlobalSimLoopExitEvent* (*&)(unsigned long), 0ul,
> pybind11::detail::void_type>(gem5::GlobalSimLoopExitEvent* (*&)(unsigned
> long), std::integer_sequence,
> pybind11::detail::void_type&&) && (this=0x7fffd028, f=@0x58dd00c8:
> 0x56559589 ) at
> ext/pybind11/include/pybind11/cast.h:2042
>
> #21 0x564fce1e in pybind11::detail::argument_loader long>::call gem5::GlobalSimLoopExitEvent* (*&)(unsigned
> long)>(gem5::GlobalSimLoopExitEvent* (*&)(unsigned long)) &&
> (this=0x7fffd028, f=@0x58dd00c8: 0x56559589
> ) at
> ext/pybind11/include/pybind11/cast.h:2014
>
> #22 0x564f9183 in
> pybind11::cpp_function::initialize (*&)(unsigned long), gem5::GlobalSimLoopExitEvent*, unsigned long,
> pybind11::name, pybind11::scope, pybind11::sibling,
> pybind11::arg_v>(gem5::GlobalSimLoopExitEvent* (*&)(unsigned long),
> gem5::GlobalSimLoopExitEvent* (*)(unsigned long), pybind11::name const&,
> pybind11::scope const&, pybind11::sibling const&, pybind11::arg_v
> const&)::{lambda(pybind11::detail::function_call&)#3}::operator()(pybind11::detail::function_call&)
> const (this=0x0, call=...) at 

[gem5-users] Re: Unrecognized register class when using the "Exec" debug flag

[Gabe Black via gem5-users]

Hey Nirmit, thanks for the backtrace, but could you please run this under
gdb and get the backtrace that way? It will figure out what the function
names are, etc, where gem5's built in backtrace just has offsets.

Gabe

On Thu, Dec 2, 2021 at 3:37 PM Nirmit Jallawar  wrote:

> Hi Matt, Gabe,
>
>
>
> Running in the develop branch the code, seems to run without any errors. I
> suppose this is due to the fact that things have been reworked in develop.
>
>
>
> The backtrace generated by the debug build on the stable branch is:
>
>
>
> 7335000: system.cpu: T0 : 0x7801bbdd @_end+140737354234813. 3 :
> CALL_NEAR_I : subi   rsp, rsp, 0x8 : IntAlu :  D=0x7fffed48
>
> 7335000: system.cpu: T0 : 0x7801bbdd @_end+140737354234813. 4 :
> CALL_NEAR_I : wrip   t7, t1 : IntAlu :
>
> 7447000: system.cpu: T0 : 0x7801d080 @_end+140737354240096: hint
>
> 7447000: system.cpu: T0 : 0x7801d080 @_end+140737354240096. 0 :
> HINT_NOP : fault   NoFault : No_OpClass :
>
> 7447000: system.cpu: T0 : 0x7801d084 @_end+140737354240100: mov
> eax, 0xc
>
> 7447000: system.cpu: T0 : 0x7801d084 @_end+140737354240100. 0 :
> MOV_R_I : limm   eax, 0xc : IntAlu :  D=0x000c
>
> build/X86/arch/x86/insts/static_inst.cc:254: panic: Unknown register
> class: 1066703648
>
> Memory Usage: 643980 KBytes
>
> Program aborted at tick 7455000
>
> --- BEGIN LIBC BACKTRACE ---
>
> ../build/X86/gem5.debug(+0xfcebed)[0x55f53b785bed]
>
> ../build/X86/gem5.debug(+0xff1b11)[0x55f53b7a8b11]
>
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x15420)[0x7fdcfff9f420]
>
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7fdcff14618b]
>
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x12b)[0x7fdcff125859]
>
> ../build/X86/gem5.debug(+0x1d29b8)[0x55f53a9899b8]
>
> ../build/X86/gem5.debug(+0x1f7537)[0x55f53a9ae537]
>
> ../build/X86/gem5.debug(+0x2f6934)[0x55f53aaad934]
>
> ../build/X86/gem5.debug(+0x8b9881)[0x55f53b070881]
>
> ../build/X86/gem5.debug(+0x8b14cd)[0x55f53b0684cd]
>
> ../build/X86/gem5.debug(+0x8b1c22)[0x55f53b068c22]
>
> ../build/X86/gem5.debug(+0x970b91)[0x55f53b127b91]
>
> ../build/X86/gem5.debug(+0x96ee43)[0x55f53b125e43]
>
> ../build/X86/gem5.debug(+0x96e49d)[0x55f53b12549d]
>
> ../build/X86/gem5.debug(+0x96ca3b)[0x55f53b123a3b]
>
> ../build/X86/gem5.debug(+0x980254)[0x55f53b137254]
>
> ../build/X86/gem5.debug(+0x97c995)[0x55f53b133995]
>
> ../build/X86/gem5.debug(+0x987884)[0x55f53b13e884]
>
> ../build/X86/gem5.debug(+0x2030ae)[0x55f53a9ba0ae]
>
> ../build/X86/gem5.debug(+0x2003d0)[0x55f53a9b73d0]
>
> ../build/X86/gem5.debug(+0xfddf5c)[0x55f53b794f5c]
>
> ../build/X86/gem5.debug(+0x1005cc3)[0x55f53b7bccc3]
>
> ../build/X86/gem5.debug(+0x10058c3)[0x55f53b7bc8c3]
>
> ../build/X86/gem5.debug(+0xfaab48)[0x55f53b761b48]
>
> ../build/X86/gem5.debug(+0xfa8e1e)[0x55f53b75fe1e]
>
> ../build/X86/gem5.debug(+0xfa5183)[0x55f53b75c183]
>
> ../build/X86/gem5.debug(+0xfa51ee)[0x55f53b75c1ee]
>
> ../build/X86/gem5.debug(+0xaedbb5)[0x55f53b2a4bb5]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x2a8718)[0x7fdd00255718]
>
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x8dd8)[0x7fdd0002af48]
>
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalCodeWithName+0x8fb)[0x7fdd00177ecb]
>
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyFunction_Vectorcall+0x94)[0x7fdd002550f4]
>
> --- END LIBC BACKTRACE ---
>
>
>
> I am leaning towards Gabe’s idea that the real bug is that the RegID
> itself is bogus since different ones are being generated each run.
>
>
>
> I am sorry for the late response.
>
>
>
> Nirmit
>
>
>
> *From:* mattdsinclair.w...@gmail.com 
> *Sent:* Wednesday, December 1, 2021 11:07 PM
> *To:* Gabe Black 
> *Cc:* gem5 users mailing list ; Nirmit Jallawar <
> jalla...@wisc.edu>
> *Subject:* Re: [gem5-users] Unrecognized register class when using the
> "Exec" debug flag
>
>
>
> Thanks Gabe.  Good catch about the actual value -- I just saw a negative
> number and assumed -1, whoops.  Based on what Nirmit is seeing, it seems
> like HINT_NOP or MOV_R_I must be the instruction causing the fault, but
> yeah a backtrace will probably help confirm.
>
>
>
> Nirmit, can you please try running stable with a debug build (to get a
> backtrace) and develop with a release build and let us know what you see?
>
>
>
> Matt
>
>
>
> On Wed, Dec 1, 2021 at 10:47 PM Gabe Black  wrote:
>
> I realize this is probably a hard question to answer with Exec being
> broken, but do you know what instruction is causing the problem? HINT_NOP?
> Probably the first thing that someone should do (if they haven't already)
> is to run this under gdb and see what the backtrace looks like, since that
> would give us a lot more info to work with.
>
>
>
> Looking at the info we have here, I see that the return from classValue()
> is -854770912 (not -1?) which to me looks like junk. I think probably
> what's happening is that the RegId being passed to the instruction's
> printReg function is from a bad pointer of some sort which is why it
> 

[gem5-users] Re: Variable Meanings in ISA files

[Gabe Black via gem5-users]

Hi Jason. The instruction definitions in gem5 can be quite complex, and
it's unlikely you'll find a lot of information about specific details like
this through Google. Probably a good place to start is to try to understand
how the ISA description files work in general, since that will give you
more context on how they're being used in this particular case. You can
find some info about its basic structure here:

https://www.gem5.org/documentation/general_docs/architecture_support/isa_parser/

And you might want to take a look at one of the simpler ISAs like MIPS or
SPARC to see these in use without as much complexity getting in the way and
obscuring what's really going on.

For some of these variables like wbDecl and pcDecl, I think they are just
shuttling information around in the python code which is part of the ISA
description. For some others like use_wb and use_pc, these are used in the
instruction templates which are basically (but not just) format strings
which tell the ISA parser how to generate the C++ which implements a given
instruction.

Gabe

On Tue, Nov 30, 2021 at 12:45 PM Jason Z via gem5-users 
wrote:

> Hello everyone, I hope you are all doing well!
>
> I apologize for this question if it seems simple, but I am still fairly
> new to gem5 and still trying to finalize my understanding, so any help
> would be greatly appreciated
>
> I am working on changing some instructions in the ISA files (i.e.,
> src/arch/arm/isa/insts/str64.isa), and I am coming across a few variables
> that I am not entirely certain of their meaning, and it's causing some
> confusion with what I am trying to implement and I haven't been able to
> find anything about them through searching the gem5 code base, the gem5
> discussion pages, or even just a general Google search
>
> So I was wondering if there was perhaps a listing of these variables
> somewhere or if anyone had any more insight into them
>
> Specifically, I wondering about the following variables and their
> interpretation/meaning:
>
> - wbDecl
> - pcDecl
> - use_wb
> - use_pc
> - rasPop
>
> I am assuming the following:
>
> - wbDecl --> writeback Declare
> - pcDecl --> program counter Declare
> - use_wb --> use writeback
> - use_pc --> use program counter
> - rasPop --> return address stack pop
>
> But I am only assuming that this might be what these variables are
> referencing and I am still not certain of their use in the bigger context
> of creating instructions in the ISA files, so if anyone has any more
> insight, it would be greatly appreciated, thank you for your time!
>
> Respectfully,
>
> Jason Z
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Unrecognized register class when using the "Exec" debug flag

[Gabe Black via gem5-users]

I realize this is probably a hard question to answer with Exec being
broken, but do you know what instruction is causing the problem? HINT_NOP?
Probably the first thing that someone should do (if they haven't already)
is to run this under gdb and see what the backtrace looks like, since that
would give us a lot more info to work with.

Looking at the info we have here, I see that the return from classValue()
is -854770912 (not -1?) which to me looks like junk. I think probably
what's happening is that the RegId being passed to the instruction's
printReg function is from a bad pointer of some sort which is why it
doesn't know how to print the register name. The RegId in this case refers
to a particular register/operand, not the instruction as a whole. For
instance, when the previous instruction prints out eax, that would be a
RegId with classValue() (member regClass) set to IntRegClass, and regIdx
set to INTREG_RAX.

This works a little differently now and is in the process of being
significantly reworked, although the gist is largely the same, particularly
in the details involved here. The RegId structure tells you what type of
register you're dealing with, aka its class, and also which particular
register within that space you're referring to. The printReg method is
trying to figure out what the name of that register is so it can be printed
as part of the disassembly.

I think the real bug is going to be that the RegId itself is bogus, and so
when it's operated on, it's random junk will lead to random behavior or
errors. It could be, for instance, that the instruction is trying to print
a register name in its disassembly, but it doesn't actually *have* a
register value set up in that slot and so is using uninitialized values.
Typically the instructions would try to print out, say, destination
register 0 when forming the disassembly string. Alternatively, O3 could
have done something whacky and could be trying to do something with a
nonsense instruction. I would personally lean towards the first option, but
without more info it's hard to tell.

I would also suggest trying this with develop. I don't think that's a
*solution* to the problem, but it would possibly help isolate a cause. Like
I said, how things work in develop are a little bit different, so we might
get more info by also seeing what happens in those slightly different
circumstances.

Gabe

On Wed, Dec 1, 2021 at 8:30 PM Matt Sinclair 
wrote:

> Hi Gabe,
>
> I was trying to dig through the RegClass code earlier to figure out why
> the value is -1 for this instruction, and the only thing that I can think
> of is HINT_NOP needs a RegClass value set for it, but it isn't set for some
> reason (which is not 100% clear to me).  You know this code much better
> than I do though, hence I was hoping you might see something I'm not seeing.
>
> Since this error is happening on a clean checkout of gem5 on stable, it
> seems like a bug that anyone could face if they use the Exec debug flag.
>
> Thanks,
> Matt
>
> -- Forwarded message -
> From: Nirmit Jallawar via gem5-users 
> Date: Wed, Dec 1, 2021 at 10:25 PM
> Subject: [gem5-users] Unrecognized register class when using the "Exec"
> debug flag
> To: gem5-users@gem5.org 
> Cc: Nirmit Jallawar 
>
>
> Hi all,
>
>
>
> I was trying to run a gem5 simulation using the O3CPU but encountered
> problems with gem5 “panic” when running with the “Exec” debug flags
> enabled. I have built gem5 for the x86 ISA, and am using the stable branch.
>
> The full log can be found in the zip linked below (crash_debug_log).
>
> The error in the log seems to be related to this:
>
> build/X86/arch/x86/insts/static_inst.cc:253: panic: Unrecognized register
> class.
>
>
>
> On further debugging, it seems that the register class value is being set
> to -1:
>
> ….
>
> 7335000: system.cpu: T0 : 0x7801bbdd @_end+140737354234813. 2 :
> CALL_NEAR_I : stis   t7, SS:[rsp + 0xfff8] : MemWrite :
>  D=0x7801bbe2 A=0x7fffed48
>
> 7335000: system.cpu: T0 : 0x7801bbdd @_end+140737354234813. 3 :
> CALL_NEAR_I : subi   rsp, rsp, 0x8 : IntAlu :  D=0x7fffed48
>
> 7335000: system.cpu: T0 : 0x7801bbdd @_end+140737354234813. 4 :
> CALL_NEAR_I : wrip   t7, t1 : IntAlu :
>
> 7447000: system.cpu: T0 : 0x7801d080 @_end+140737354240096: hint
>
> 7447000: system.cpu: T0 : 0x7801d080 @_end+140737354240096. 0 :
> HINT_NOP : fault   NoFault : No_OpClass :
>
> 7447000: system.cpu: T0 : 0x7801d084 @_end+140737354240100: mov
> eax, 0xc
>
> 7447000: system.cpu: T0 : 0x7801d084 @_end+140737354240100. 0 :
> MOV_R_I : limm   eax, 0xc : IntAlu :  D=0x000c
>
> build/X86/arch/x86/insts/static_inst.cc:254: panic: Unknown register
> class: -854770912 (reg.classValue())
>
> Memory Usage: 632228 KBytes
>
> Program aborted at tick 7455000
>
> --- BEGIN LIBC BACKTRACE ---
>
> ….
>
> The error does not appear when using no debug flags or using flags like
> 'IEW'.
>
> The command used 

[gem5-users] Re: Basic question on gem5 configuration script for multi-threaded workload

[Gabe Black via gem5-users]

Hi Sachin. Without looking at the output, this sounds like a null pointer
to a structure or object within your workload, where the thing within being
accessed is at offset 0x14 from the start of the struct/object. You can use
GDB to debug code within gem5 using the remote GDB stub:

https://www.gem5.org/documentation/general_docs/debugging_and_testing/debugging/debugging_simulated_code

On Sun, Nov 21, 2021 at 6:43 PM Sachin Vijay Kumar 
wrote:

> Hi Gabe,
>  Thanks for the suggestion, it worked. I used "se.py" file and submitted
> workload. It seems that for multithreaded work load, if number of threads
> is equal to number of cores, things work. I used --debug flag to verify
> whether both cores are running. But unfortunately, I have ran into another
> problem. This seem to work for number of cores and threads equal to 2. When
> I use more than 2, I get an panic error "panic: panic condition !handled
> occurred: Page table fault when accessing virtual address 0x14".
>
> I have attached the console output for working ( n=2) and non working
> (n=3) case, do you have any suggestion on where I should look into in
> solving this problem? I spent lot of time on this with out making any
> progress.
>
> Thanks,
> Sachin
>
>
> On Mon, Nov 15, 2021 at 5:51 PM Gabe Black via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> I'm not 100% sure this is right, but I think what you do is assign the
>> same process object to each core you want a thread to run on.
>>
>> Gabe
>>
>> On Mon, Nov 15, 2021 at 10:25 AM Sachin Vijay Kumar via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> Hi all,
>>>
>>>   I have some basic question about assigning a multithreaded program
>>> into different cores of ARM in gem5 simulation.
>>> Basically, I have hashmark benchmark file which is built for arm core
>>> with "m5 threads".
>>>  The  executable takes number of threads to create and a input file as
>>> argument. Now when I run simulations, I have to assign each thread of this
>>> benchmark program to each core of the processor. How can I do that?
>>> I have gone through "se.py" and I understand, how different program
>>> could be loaded into different cores. I also understand, how different
>>> programs can be loaded into multi-threaded single core (by looking at same
>>> script file).
>>> But I do not get, How can I assign a thread of a benchmark application
>>> to a core of the processor, Can some one please provide some pointers?
>>>
>>> Thanks,
>>> Sachin
>>> ___
>>> gem5-users mailing list -- gem5-users@gem5.org
>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Basic question on gem5 configuration script for multi-threaded workload

[Gabe Black via gem5-users]

I'm not 100% sure this is right, but I think what you do is assign the same
process object to each core you want a thread to run on.

Gabe

On Mon, Nov 15, 2021 at 10:25 AM Sachin Vijay Kumar via gem5-users <
gem5-users@gem5.org> wrote:

> Hi all,
>
>   I have some basic question about assigning a multithreaded program into
> different cores of ARM in gem5 simulation.
> Basically, I have hashmark benchmark file which is built for arm core with
> "m5 threads".
>  The  executable takes number of threads to create and a input file as
> argument. Now when I run simulations, I have to assign each thread of this
> benchmark program to each core of the processor. How can I do that?
> I have gone through "se.py" and I understand, how different program could
> be loaded into different cores. I also understand, how different programs
> can be loaded into multi-threaded single core (by looking at same script
> file).
> But I do not get, How can I assign a thread of a benchmark application to
> a core of the processor, Can some one please provide some pointers?
>
> Thanks,
> Sachin
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: help ------------ the cross compiler version of MIPS

[Gabe Black via gem5-users]

The first error is because that is a big endian binary, and gem5 only
supports the little endian version of MIPS. The second error is not because
of the cross compiler, it's because something is wrong with the
configuration (or gem5 itself) and an error is detected while running.
Specifically, the CPU is making sure it's actually running before
suspending itself as requested, but it finds that it isn't.

Gabe

On Sun, Nov 14, 2021 at 1:58 AM Dubhe via gem5-users 
wrote:

> Hello, I'd like to know the cross compiler version of MIPS. The
> dockcross/linux-mips and dockcross/linux-mipsel is wrong。 If you can, you
> can provide me with a MIPS cross compiler, thank you.
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: m5 pesudo

[Gabe Black via gem5-users]

Please take a look at util/m5/README.md for information about when the
different modes will work.

On Mon, Nov 1, 2021 at 8:14 AM Liyichao via gem5-users 
wrote:

> Thanks for your reply.
>
> But when I work on the Gem5 v20.0.0.3，
> m5 —addr exit doesn‘t take effect on O3，
> and it just takes affect on KVM in fs.
>
> So on v21.0.1.0，
>  how can I let the m5 exit only takes effect on KVM and does not take effect 
> on O3
> ？
>
>
>
>
> --
>
> 李翼超 Li Yichao
> Mobile：+86-15858232899
> Email：liyic...@huawei.com
>
>
> *发件人： *Jason Lowe-Power
> *收件人： *gem5 users mailing list
> *抄送： *Liyichao
> *主题： *Re: [gem5-users] m5 pesudo
> *时间： *2021-11-01 22:56:48
>
> Hello,
>
> The m5 magic operations (either via magic instructions or addresses) will
> work with all CPU models.
>
> Cheers,
> Jason
>
> On Sat, Oct 30, 2021 at 8:31 PM Liyichao via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi All:
>>
>>  Does “m5 --addr 0x1001 exit” take effect in the O3 system?
>>
>>
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: UART communication

[Gabe Black via gem5-users]

gem5 does not write UART output to the console, it writes it to a file in
the m5out directory, and makes it available if you connect to the console
output socket using m5term (or any other telnet client). If you use
aggressive debug flags like ExecAll, that will slow down execution
dramatically and may prevent you from getting to the code you're interested
in in a reasonable amount of time.

Gabe

On Sun, Oct 31, 2021 at 4:51 PM Arrvindh Shriraman via gem5-users <
gem5-users@gem5.org> wrote:

> Hi —
>
> I am trying to set up a bare-metal execution for RISC-V.
> I am using the following template
>
> https://github.com/s094392/riscv-bare-metal
>
> However the bytes I send to the uart do not appear on gem5 terminal
> output. Not sure if they are getting to the uart either
> - uart (
> https://github.com/s094392/riscv-bare-metal/blob/master/inc/uart.h)
>
> I am trying this on the gem5 21.
> $ ./build/RISCV/gem5.opt --debug-start=0 --debug-file=trace.out
> --debug-flags=Event,ExecAll,FmtFlag ./configs/example/riscv/fs_linux.py
> --bare-metal --kernel ../riscv-bare-metal/kernel.elf
>
>
> On qemu the exact same program results in the following output.
> qemu-system-riscv64 -M virt -kernel kernel.img -bios none -serial stdio
> -display none
> Timer Interrupt: 1
> Timer Interrupt: 2
> Timer Interrupt: 3
> Timer Interrupt: 4
> Timer Interrupt: 5
> Timer Interrupt: 6
>
>
>
> Not sure why the example works on qemu but not gem5 atomic. Any
> suggestions welcome.
>
> Regards,
> Arrvindh Shriraman
> Associate Professor
> Computer Science
> Simon Fraser University
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: How to enable KVM unitest on ARM server

[Gabe Black via gem5-users]

I found it in the revision history. If you're building the "NULL" target,
you should not set USE_KVM to true. If you do, then it will try to verify
that the simulated architecture and the host architecture is the same,
which is the only time KVM will work. This "Info" print out is just telling
you that there's a mismatch between no ISA and the ARM ISA, and that KVM is
not available.

In general, unless it says "error", it's not an error and you don't need to
be overly concerned about it.

Gabe

On Fri, Oct 29, 2021 at 9:35 PM Liyichao  wrote:

> If I build gem5.opt of ARM on X86 server, the print “Info: KVM for null
> not supported on arm host.” will also be presented
>
>
>
> *发件人:* Gabe Black via gem5-users [mailto:gem5-users@gem5.org]
> *发送时间:* 2021年10月29日 11:43
> *收件人:* gem5 users mailing list 
> *抄送:* Gabe Black 
> *主题:* [gem5-users] Re: How to enable KVM unitest on ARM server
>
>
>
> Hi, I just grepped through all of gem5's source, and, even ignoring
> capitalization, the string "KVM for" does not appear outside of a couple
> comments. I have no idea where that string is coming from, but it doesn't
> seem to be from gem5 itself.
>
>
>
> Gabe
>
>
>
> On Thu, Oct 28, 2021 at 8:04 PM Liyichao via gem5-users <
> gem5-users@gem5.org> wrote:
>
> Hi All:
>
> My GEM5 V21.1.0.2 running on aarch64 server, but when I compile
> bitunion.test.opt, the compilation print will show “Info: KVM for null not
> supported on arm host.”
>
>
>
> scons build/NULL/base/bitunion.test.opt -j120
>
> scons: Reading SConscript files ...
>
> Checking for linker -Wl,--as-needed support... (cached) yes
>
> Warning: While checking protoc version: [Errno 2] No such file or
> directory: 'protoc'
>
> Warning: Protocol buffer compiler (protoc) not found.
>
>  Please install protobuf-compiler for tracing support.
>
> Checking for compiler -gz support... (cached) yes
>
> Checking for linker -gz support... (cached) yes
>
> Info: Using Python config: python3-config
>
> Checking for C header file Python.h... (cached) yes
>
> Checking for C library python3.8... (cached) yes
>
> Checking for C library crypt... (cached) yes
>
> Checking for C library pthread... (cached) yes
>
> Checking for C library dl... (cached) yes
>
> Checking for C library util... (cached) yes
>
> Checking for C library m... (cached) yes
>
> Checking Python version... (cached) 3.8.5
>
> Checking for accept(0,0,0) in C++ library None... (cached) yes
>
> Checking for zlibVersion() in C++ library z... (cached) yes
>
> Checking for C header file valgrind/valgrind.h... (cached) no
>
> Checking for clock_nanosleep(0,0,NULL,NULL) in C library None... (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 for C library tcmalloc... (cached) yes
>
> Checking for char temp; backtrace_symbols_fd((void *), 0, 0) in C
> library None... (cached) yes
>
> Checking for C header file fenv.h... (cached) yes
>
> Checking for C header file png.h... (cached) yes
>
> Checking for C header file linux/kvm.h... (cached) yes
>
> Checking for C header file linux/if_tun.h... (cached) yes
>
> Checking for member exclude_host in struct perf_event_attr...(cached) yes
>
> Checking for H5Fcreate("", 0, 0, 0) in C library hdf5... (cached) no
>
> Warning: Couldn't find any HDF5 C++ libraries. Disabling HDF5 support.
>
> Checking whether __i386__ is declared... (cached) no
>
> Checking whether __x86_64__ is declared... (cached) no
>
> Warning: Unrecognized architecture for systemc.
>
> Building in /home/l00515693/KSim_LightESL/build/NULL
>
> Variables file /home/l00515693/KSim_LightESL/build/variables/NULL not
> found,
>
>   using defaults in /home/l00515693/KSim_LightESL/build_opts/NULL
>
> *Info: KVM for null not supported on arm host.*
>
> scons: done reading SConscript files.
>
> scons: Building targets ...
>
>
>
>
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: How to enable KVM unitest on ARM server

[Gabe Black via gem5-users]

Hi, I just grepped through all of gem5's source, and, even ignoring
capitalization, the string "KVM for" does not appear outside of a couple
comments. I have no idea where that string is coming from, but it doesn't
seem to be from gem5 itself.

Gabe

On Thu, Oct 28, 2021 at 8:04 PM Liyichao via gem5-users 
wrote:

> Hi All:
>
> My GEM5 V21.1.0.2 running on aarch64 server, but when I compile
> bitunion.test.opt, the compilation print will show “Info: KVM for null not
> supported on arm host.”
>
>
>
> scons build/NULL/base/bitunion.test.opt -j120
>
> scons: Reading SConscript files ...
>
> Checking for linker -Wl,--as-needed support... (cached) yes
>
> Warning: While checking protoc version: [Errno 2] No such file or
> directory: 'protoc'
>
> Warning: Protocol buffer compiler (protoc) not found.
>
>  Please install protobuf-compiler for tracing support.
>
> Checking for compiler -gz support... (cached) yes
>
> Checking for linker -gz support... (cached) yes
>
> Info: Using Python config: python3-config
>
> Checking for C header file Python.h... (cached) yes
>
> Checking for C library python3.8... (cached) yes
>
> Checking for C library crypt... (cached) yes
>
> Checking for C library pthread... (cached) yes
>
> Checking for C library dl... (cached) yes
>
> Checking for C library util... (cached) yes
>
> Checking for C library m... (cached) yes
>
> Checking Python version... (cached) 3.8.5
>
> Checking for accept(0,0,0) in C++ library None... (cached) yes
>
> Checking for zlibVersion() in C++ library z... (cached) yes
>
> Checking for C header file valgrind/valgrind.h... (cached) no
>
> Checking for clock_nanosleep(0,0,NULL,NULL) in C library None... (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 for C library tcmalloc... (cached) yes
>
> Checking for char temp; backtrace_symbols_fd((void *), 0, 0) in C
> library None... (cached) yes
>
> Checking for C header file fenv.h... (cached) yes
>
> Checking for C header file png.h... (cached) yes
>
> Checking for C header file linux/kvm.h... (cached) yes
>
> Checking for C header file linux/if_tun.h... (cached) yes
>
> Checking for member exclude_host in struct perf_event_attr...(cached) yes
>
> Checking for H5Fcreate("", 0, 0, 0) in C library hdf5... (cached) no
>
> Warning: Couldn't find any HDF5 C++ libraries. Disabling HDF5 support.
>
> Checking whether __i386__ is declared... (cached) no
>
> Checking whether __x86_64__ is declared... (cached) no
>
> Warning: Unrecognized architecture for systemc.
>
> Building in /home/l00515693/KSim_LightESL/build/NULL
>
> Variables file /home/l00515693/KSim_LightESL/build/variables/NULL not
> found,
>
>   using defaults in /home/l00515693/KSim_LightESL/build_opts/NULL
>
> *Info: KVM for null not supported on arm host.*
>
> scons: done reading SConscript files.
>
> scons: Building targets ...
>
>
>
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: How to map elf section to physical memory

[Gabe Black via gem5-users]

Oh, I see, I didn't realize you were trying to call it from python, or even
that that was exposed to python. It would probably be possible to expose
that parameter as well, although that would require a change to gem5. I
think that change would be worth doing, but may be a bit of a tangent from
what you're doing. Alternatively, you could define a different Workload
class in C++ which would do your extra set up there, where you can use the
extra argument.

Gabe

On Tue, Oct 26, 2021 at 5:30 PM Monsalve, Jose Manuel 
wrote:

> Sorry for the typo. I meant Gabe.
>
> Jose Monsalve
> --
> *From:* Gabe Black 
> *Sent:* Tuesday, October 26, 2021 7:27:58 PM
> *To:* gem5 users mailing list 
> *Cc:* Jason Lowe-Power ; Tianshuo Su <
> t...@uchicago.edu>; Andronicus Samsundar Rajasukumar <
> androni...@uchicago.edu>; Andrew A. Chien ;
> Monsalve, Jose Manuel 
> *Subject:* Re: [gem5-users] Re: How to map elf section to physical memory
>
> You can also take a look at the "clobber" argument which will tell the
> mapping function to overwrite existing mappings. You can see in the panic
> that that's what it's checking, ie it found an overlap and it wasn't told
> to go ahead and clobber those, so it has to give up.
>
> Gabe
>
> On Tue, Oct 26, 2021 at 5:13 PM Monsalve, Jose Manuel via gem5-users <
> gem5-users@gem5.org> wrote:
>
> Jason,
>
>
>
> Thanks for the answer.
>
>
>
> Let me take a look into this idea and I will get back to you.
>
>
>
> Jose
>
>
>
> *From: *Jason Lowe-Power 
> *Date: *Tuesday, October 26, 2021 at 5:58 PM
> *To: *gem5 users mailing list 
> *Cc: *Tianshuo Su , Andronicus Samsundar Rajasukumar <
> androni...@uchicago.edu>, "Andrew A. Chien" ,
> "Monsalve, Jose Manuel" 
> *Subject: *Re: [gem5-users] How to map elf section to physical memory
>
>
>
> Hi Jose,
>
>
>
> This is an interesting question! My quick suggestion would be to "hack"
> the loader/page table to skip the mapping portion when loading the elf
> section.
>
>
>
> I don't fully understand exactly what the underlying "problem" is. That
> said, we may be able to solve it "correctly" by generally skipping the
> mapping during the elf loading if it's already been manually mapped by the
> process.map function. This may be useful to upstream if this idea works.
>
>
>
> Cheers,
>
> Jason
>
>
>
> On Fri, Oct 22, 2021 at 4:30 PM Monsalve, Jose Manuel via gem5-users <
> gem5-users@gem5.org> wrote:
>
> Hi everyone,
>
>
>
> I am working on developing the simulation of a system that contains two
> different regions of memory. One that maps to the cachable system memory
> (including cache hierarchy) but another region that is non-cachable, and
> which goes to a different memory (similar to scratchpad memory for the sake
> of this question). Additionally, in the executing code, I am trying to
> allocate some objects into this scratchpad memory address space from a
> section in the elf file. While running in SE mode. So, for example:
>
>
>
> System Memory address range -> 0x-0 to 0x00FFF
>
> Scratchpad memory address range -> 0x01000 to 0xF
>
>
>
> And in the linker script I place some sections in this region like:
>
>
>
> . = 0x1000
>
> .scratchpad {
>
>/* all symbols */
>
> }
>
>
>
> Then to use the __attribute__((section(“.scratchpad”)) in a given
> definition.
>
>
>
> However, when the loader loads this elf file, the virtual memory is
> assigned correctly, but it is mapped to another physical memory range that
> is different to the physical memory of the SPmem device.
>
>
>
> I know I can use the *.map()* method in the process like this (in python)
>
>
>
> process.map(Addr(args.mem_size),
>
> Addr(args.mem_size),
>
> SPMemorySize,
>
> False)
>
>
>
> This will only work if I don’t use sections in the linker script, and
> instead, manually assign the value of a pointer. (e.g. int **a = (int**)
> 0x1000;)
>
>
>
> But when I run it with the elf sections I get the error:
>
> build/RISCV/mem/page_table.cc:60: panic: panic condition !clobber
> occurred: EmulationPageTable::allocate: addr 0xc000 already mapped
>
>
>
> Because by the moment I reach the second map, the loader has already
> mapped the region before.
>
>
>
> I would appreciate if someone can share nay pointers on how to properly do
> this mapping between virt and physical.
>
>
>
> Thanks!
>
>
>
> Jose M Monsalve Diaz
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org

[gem5-users] Re: How to map elf section to physical memory

[Gabe Black via gem5-users]

You can also take a look at the "clobber" argument which will tell the
mapping function to overwrite existing mappings. You can see in the panic
that that's what it's checking, ie it found an overlap and it wasn't told
to go ahead and clobber those, so it has to give up.

Gabe

On Tue, Oct 26, 2021 at 5:13 PM Monsalve, Jose Manuel via gem5-users <
gem5-users@gem5.org> wrote:

> Jason,
>
>
>
> Thanks for the answer.
>
>
>
> Let me take a look into this idea and I will get back to you.
>
>
>
> Jose
>
>
>
> *From: *Jason Lowe-Power 
> *Date: *Tuesday, October 26, 2021 at 5:58 PM
> *To: *gem5 users mailing list 
> *Cc: *Tianshuo Su , Andronicus Samsundar Rajasukumar <
> androni...@uchicago.edu>, "Andrew A. Chien" ,
> "Monsalve, Jose Manuel" 
> *Subject: *Re: [gem5-users] How to map elf section to physical memory
>
>
>
> Hi Jose,
>
>
>
> This is an interesting question! My quick suggestion would be to "hack"
> the loader/page table to skip the mapping portion when loading the elf
> section.
>
>
>
> I don't fully understand exactly what the underlying "problem" is. That
> said, we may be able to solve it "correctly" by generally skipping the
> mapping during the elf loading if it's already been manually mapped by the
> process.map function. This may be useful to upstream if this idea works.
>
>
>
> Cheers,
>
> Jason
>
>
>
> On Fri, Oct 22, 2021 at 4:30 PM Monsalve, Jose Manuel via gem5-users <
> gem5-users@gem5.org> wrote:
>
> Hi everyone,
>
>
>
> I am working on developing the simulation of a system that contains two
> different regions of memory. One that maps to the cachable system memory
> (including cache hierarchy) but another region that is non-cachable, and
> which goes to a different memory (similar to scratchpad memory for the sake
> of this question). Additionally, in the executing code, I am trying to
> allocate some objects into this scratchpad memory address space from a
> section in the elf file. While running in SE mode. So, for example:
>
>
>
> System Memory address range -> 0x-0 to 0x00FFF
>
> Scratchpad memory address range -> 0x01000 to 0xF
>
>
>
> And in the linker script I place some sections in this region like:
>
>
>
> . = 0x1000
>
> .scratchpad {
>
>/* all symbols */
>
> }
>
>
>
> Then to use the __attribute__((section(“.scratchpad”)) in a given
> definition.
>
>
>
> However, when the loader loads this elf file, the virtual memory is
> assigned correctly, but it is mapped to another physical memory range that
> is different to the physical memory of the SPmem device.
>
>
>
> I know I can use the *.map()* method in the process like this (in python)
>
>
>
> process.map(Addr(args.mem_size),
>
> Addr(args.mem_size),
>
> SPMemorySize,
>
> False)
>
>
>
> This will only work if I don’t use sections in the linker script, and
> instead, manually assign the value of a pointer. (e.g. int **a = (int**)
> 0x1000;)
>
>
>
> But when I run it with the elf sections I get the error:
>
> build/RISCV/mem/page_table.cc:60: panic: panic condition !clobber
> occurred: EmulationPageTable::allocate: addr 0xc000 already mapped
>
>
>
> Because by the moment I reach the second map, the loader has already
> mapped the region before.
>
>
>
> I would appreciate if someone can share nay pointers on how to properly do
> this mapping between virt and physical.
>
>
>
> Thanks!
>
>
>
> Jose M Monsalve Diaz
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: BasicPioDevice read() / write() not responding

[Gabe Black via gem5-users]

I agree with Hoa that you're using virtual addresses, and those are
unrelated to the physical addresses you're trying to access. The second
method is probably moving an immediate constant into the register, and not
loading from a memory address. mmap-ing the physical pages you're
interested in would help. Also you should use the "volatile" keyword to
tell the compiler that this isn't just memory, and it shouldn't assume that
the value won't change out from under it, and hence it needs to read from
it or write to it for real every time you tell it to. If you're using
caches, you'll also want to make sure that range is not cached, or the
accesses will be handled by the cache and not actually make it out to the
rest of the memory system.

Gabe

On Sat, Oct 23, 2021 at 7:02 PM Hoa Nguyen via gem5-users <
gem5-users@gem5.org> wrote:

> Hi Andreas,
>
> My guess is that for Method 1, the pointer is of a virtual address so
> there's a page fault there.
>
> I'm not sure why the write() function wasn't invoked on Method 2. I got
> into the same problem recently where I used mmap() to write to a physical
> address, which should be handled by a Pio device. Even though the generated
> binary has a store instruction to that address, the write() function wasn't
> called. I solved that problem by using printf() to print the value at that
> physical address. I think using volatile keyword should have worked as well.
>
> I'm quite rusty on bare metal programming so I might be wrong :)
>
> Regards,
> Hoa Nguyen
>
> On Sat, Oct 23, 2021, 4:37 PM diavastos--- via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi all,
>>
>> I implemented a device using the BasicPioDevice class but I can't seem to
>> get the read() & write() calls to work.
>> I assigned a pioAddr=0x2 and a pioSize=4096 and I try to write to
>> the device directly using these two methods:
>>
>> Method 1:
>> ---
>>
>> uint32_t inp_params2 = 14;
>> uint64_t *driver = (uint64_t*)0x2;
>> *driver = inp_params2;
>>
>> Method 2:
>> ---
>>
>> asm volatile (
>> "mov %0,0x2\n"
>> :
>> : "r" (inp_params2)
>> :
>> );
>>
>> With the Method 2, the simulation completes with no error but the write()
>> is never called on the device, With Method 1 I get the following error:
>> panic: panic condition !handled occurred: Page table fault when accessing
>> virtual address 0x2
>>
>> Any help would be greatly appreciated!
>>
>> Many Thanks,
>> andreas
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Error with syscall 318 for gem5, when executing with a multi agent reinforcement learning algorithm

[Gabe Black via gem5-users]

Hi Gogineni. By adding extra entries to x86's system call table, all you
did was tell gem5 those system calls existed so that it could print a more
informative message about them not being implemented. Your second change,
when you added getrandomFunc to the getrandom entry, would work, except you
have to actually implement a getrandomFunc. You can look at the
implementations in src/sim/syscall_emul.hh and src/sim/syscall_emul.cc to
get an idea how to do that.

You are welcome to try to run the python interpreter in SE mode, and you
might get it to work. The python interpreter is large and complex though,
and you might end up spending a lot of time and effort trying to implement
missing system calls, etc, and it may not be worth the trouble. You might
want to try running it in FS mode instead, where the simulated OS handles
all the system calls, etc, like it would on a real machine.

Gabe

On Mon, Oct 18, 2021 at 8:47 AM gogineni kailashnath via gem5-users <
gem5-users@gem5.org> wrote:

> I'm trying to execute a python algorithm 
> (*https://github.com/shariqiqbal2810/maddpg-pytorch
> *) on gem5 in se mode
> in X86. But, at first I got an *error syscall 318 out of range*. So, I
> tried to import the get random function into the syscalltlb64 source code,
> like this:
>
> { 313, "finit_module" },
> { 314, "sched_setattr" },
> { 315, "sched_getattr" },
> { 316, "renameat2" },
> { 317, "seccomp" },
> { 318, "getrandom"},
> { 319, "memfd_create" },
> { 320, "kexec_file_load" },
> { 321, "bpf" },
>
> I'm trying to execute a python algorithm 
> (*https://github.com/shariqiqbal2810/maddpg-pytorch
> *) on gem5 in se mode
> in X86. But, at first I got an *error syscall 318 out of range*. So, I
> tried to import the get random function into the syscalltlb64 source code,
> like this:
>
> { 313, "finit_module" },
> { 314, "sched_setattr" },
> { 315, "sched_getattr" },
> { 316, "renameat2" },
> { 317, "seccomp" },
> { 318, "getrandom"},
> { 319, "memfd_create" },
> { 320, "kexec_file_load" },
> { 321, "bpf" },
>
> Again, I got an error saying syscall 318 unimplemented. So, I just did:
>
>   { 318, "getrandom", getrandomFunc},
>
> Again, the problem continues as I got an error saying:
>
> {318, "getrandom", }, {319, "memfd_create"}, {320, 
> "kexec_file_load"}, {321, "bpf"}}' from '' 
> to 'gem5::SyscallDescTable'
>   374 | };
>   | ^
>   | |
>   | 
> scons: *** [build/X86/arch/x86/linux/syscall_tbl64.o] Error 1
> scons: building terminated because of errors.
> *** Summary of Warnings ***
> Can anyone help me how to solve this problem?
> Note: My linux kernel version is 5.4.0-88-generic and I'm using ubuntu 20.04 
> LTS.
> Thanks for the help
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: How to turn off Gem5 git commit script?

[Gabe Black via gem5-users]

It sounds to me like you've somehow installed the gem5 git hooks for
everything on your machine through either the user global or a machine
global git config. What you want to do is install the hooks (scripts or
links in .git/hooks) in the gem5 repository itself. SCons will prompt you
to do this if you're checkout isn't set up.

Gabe

On Thu, Sep 23, 2021 at 11:40 PM Todd Bezenek via gem5-users <
gem5-users@gem5.org> wrote:

> That works. Thank you, Pedro.
>
> On Thu, Sep 23, 2021 at 11:36 PM Pedro Henrique Exenberger Becker <
> pe...@ac.upc.edu> wrote:
>
>> You can try `git commit -m "my message" - n`
>>
>> -n is the short version of - -no-verify flag.
>> https://git-scm.com/docs/git-commit
>>
>> However your commits won't be compliant with gem5 standards. I guess this
>> can be a problem if you want to push your code/modifications to the main
>> repo some day, but I'm not sure.
>>
>> Pedro.
>>
>> Em sex, 24 de set de 2021 07:48, Todd Bezenek via gem5-users <
>> gem5-users@gem5.org> escreveu:
>>
>>> (Please be sure to look at my question at the bottom of this message.
>>> Also, please excuse the length of the message--I want it to be complete.)
>>>
>>> You were assigned to review my first Gem5 check-in, so you are getting
>>> this annoying email. I'm sorry about that, but I do not know who would be a
>>> better person. :)
>>>
>>> In order to satisfy the requirements for a proper Gem5 check-in, I had
>>> to do a couple of things that changed the way git works on my machine. As a
>>> result, when I do a "git commit" on a different repository from the
>>> machine, the required background stuff for Gem5 is launching. How do I turn
>>> this off?
>>>
>>> The problem is likely because I am creating my own local Gem5 repository
>>> to play with on the same machine that has the repository I used to create
>>> the reviewable check-in. Now when I try to do a commit to the "play with"
>>> repository, the script which helps to set up the Gem5 reviewable check-in
>>> launches and I get this message:
>>> -
>>> toddb@zippy $ git commit -m "After my change was sent to Gem5."
>>> Invalid commit header
>>> The commit has been cancelled, but a copy of it can be found in
>>> .git/COMMIT_EDITMSG :
>>>
>>>
>>> --
>>>
>>> After my change was sent to Gem5.
>>>
>>> Change-Id: I8f1ef29ab9af589bf433806b5483571728bb0998
>>>
>>>
>>>
>>> --
>>>
>>>
>>> The first line of a commit must contain one or more gem5 tags separated
>>> by
>>> commas (see MAINTAINERS.yaml for the possible tags), followed by a colon
>>> and
>>> a commit title. There must be no leading nor trailing whitespaces.
>>>
>>> This header line must then be followed by an empty line. A detailed
>>> message,
>>> although highly recommended, is not mandatory and can follow that empty
>>> line.
>>>
>>> e.g.:
>>> cpu: Refactor branch predictors
>>>
>>> Refactor branch predictor code to improve its readability, moving
>>> functions
>>> X and Y to the base class...
>>>
>>> e.g.:
>>> mem,mem-cache: Improve packet class readability
>>>
>>> The packet class...
>>>
>>> Thu Sep 23 08:38:17 ~/Work/Gem5
>>> -
>>>
>>> My question is, how do I get rid of whatever is happening in the
>>> background for this other repository on the same machine where the repo I
>>> have for reviewable check-ins is?
>>>
>>> If you cannot answer this easily, I will spend more time trying to
>>> figure it out myself.
>>>
>>> Thank you for your patience. The first check-in is always troublesome. :)
>>>
>>> -Todd
>>> ___
>>> gem5-users mailing list -- gem5-users@gem5.org
>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>
>> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Query: Valgrind speed in FS

[Gabe Black via gem5-users]

It's normal for valgrind to slow things down a lot. One thing you can do to
at least improve the quality of the errors you get is to use the
suppressions file in util/valgrind-suppressions. The python interpreter
does a lot of things which upset valgrind, and this tells valgrind mostly
to ignore things it sees there. Also, make sure you build gem5 with the
--without-tcmalloc scons option. tcmalloc is an alternative heap
implementation which replaces the one valgrind instruments, so if you don't
do that, you won't actually check anything.

Gabe

On Tue, Sep 7, 2021 at 2:19 PM Sindhuja Gopalakrishnan Elango via
gem5-users  wrote:

> Hi Community,
>
> I ran into bad_alloc issues in GEM5 with the full system simulation of
> SPEC 2006 benchmarks.
>
> Suspecting a memory leak, I wanted to use valgrind to understand better.
>
>
>
> Without valgrind option, it takes less than 10 minutes for kernel to boot
> and also run the 400.perlbench/attrs benchmark.
>
> But with valgrind, it has crossed 2 hrs and the kernel hasn’t yet booted.
>
>
>
> Usage:
>
> valgrind --log-file=attrs.val.txt --error-limit=no   $GEM5_CMD
>
>
>
> I would like to know if this slowdown is reasonable with valgrind?
>
> And do you have any suggestions for a memory leak detection tool that is
> faster than valgrind and works well with gem5?
>
>
>
> Appreciate your time and effort. Thanks much.
>
>
>
> Best Regards
>
> Sindhuja
>
>
>
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: syscall newfstatat (#262) unimplemented

[Gabe Black via gem5-users]

The standard library you're linking against is newer, and is using a system
call that gem5 doesn't implement. You'll either need to use an older
standard library, or implement that system call. If you're trying to run
gem5's tests, then I know at least one of the x86 ones uses dynamic linking
and links against libraries on your host system (!) which can include calls
to the more recent system call. It really shouldn't do that in my opinion,
but that's the way it's set up today unfortunately.

Gabe

On Thu, Sep 2, 2021 at 2:16 PM Manas via gem5-users 
wrote:

> Hi, I think while building gem5, I may have missed something. And I
> didn't realize it during testing the `hello` binary.
>
> Now, whenever any binary uses file operations (like `fopen`) then I
> get the following error:
>
> ```
> build/X86/sim/syscall_emul.cc:66: fatal: syscall newfstatat (#262)
> unimplemented.
> ```
>
> Can someone point me to where could the issue be?
>
> Thank you
> --
> Manas
> CSAM Undergraduate | 2022
> IIIT-Delhi, India
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: util/tlm issue, need help

[Gabe Black via gem5-users]

Hi, sorry for taking a while to get back to you. The cxx-config code is not
quite correct, although it basically works in most cases. It fails to build
with the systemc integration, but you don't want to use gem5's built in
systemc kernel anyway, if you're going to run it inside another external
systemc simulation. The util/systemc/gem5_within_systemc/README was updated
to tell you to set USE_SYSTEMC=0 on the command line, but it looks like we
forgot to update the tlm one. Ideally we'll fix the underlying issue one of
these days, but there are a lot of things to fix and only so much time. So,
to get the build to work, add USE_SYSTEMC=0 to the scons command line.

Gabe

On Fri, Aug 13, 2021 at 9:13 AM wu xuyong via gem5-users <
gem5-users@gem5.org> wrote:

> Dear Gem5 Users,
>
>  I‘ve got stucked when try to follow the tlm tutorial in
> gem5/util/tlm/README.
>
> (similar issues for versioin of GEM5 21.1.0.0 & 21.0.1.0)
>
> Following the section III of the README file, there is no issue on the
> first two line and end with normal gem5.opt output:
>
> > cd ../..
>
> > scons build/ARM/gem5.opt
>
>
>
> While the problem comes during the next command
>
> > scons --with-cxx-config --without-python --without-tcmalloc
>
> >   build/ARM/libgem5_opt.so
>
>
>
> There comes several error report as below, the log file is also available
> as attachment.
>
> build/ARM/cxx_config/Gem5ToTlmBridge256.cc:144
> :24: error: cannot convert
> 'sc_gem5::Gem5ToTlmBridge<256>*' to 'gem5::SimObject*' in return
>
>   144 | return this->create();
>
>   |^~
>
>   ||
>
>   |sc_gem5::Gem5ToTlmBridge<256>*
>
>
>
> I tried hard walking arround and have no ideal on how to get throught. I
> guess it may be a common issue for those who’s trying to get through this
> tutorial. Any advise on using the tlm utility of Gem5 will be great helpful.
>
> By the way, it will make my life better if anyone could offer me any idea
> on getting rid of the huge amount of namespace warning in building the new
> version 21.1.0.0.
>
>
>
> Thank in advance
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: static_inst.cc panic or assertion error when debugging execution of an x86 O3CPU

[Gabe Black via gem5-users]

86_64-linux-gnu/libpython3.8.so.1.0(+0x74d6d)[0x7f3f7d2b7d6d]
>>
>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x7d86)[0x7f3f7d2bfef6]
>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x8006b)[0x7f3f7d2c306b]
>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x74d6d)[0x7f3f7d2b7d6d]
>>
>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x12fd)[0x7f3f7d2b946d]
>>
>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalCodeWithName+0x8fb)[0x7f3f7d40de3b]
>>
>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyFunction_Vectorcall+0x94)[0x7f3f7d4eb114]
>> --- END LIBC BACKTRACE ---
>> Aborted
>>
>> On Wed, Aug 11, 2021 at 12:41 AM Gabe Black via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> Please give this a try:
>>>
>>> https://gem5-review.googlesource.com/c/public/gem5/+/49183
>>>
>>> On Tue, Aug 10, 2021 at 9:37 PM Deric Cheung via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
>>>> Host OS: Ubuntu 12.04 LTS
>>>> Host CPU: Intel i7-2600 3.40 GHz
>>>>
>>>> I'm trying to debug an x86 application on an O3CPU using syscall
>>>> emulation, but static_inst.cc panics or runs into an assertion error. Ideas
>>>> for how I can debug or solve this issue?
>>>>
>>>> Example command 1 (causing panic): build/X86/gem5.opt
>>>> --debug-flags=Exec --debug-file=debug.txt configs/example/se.py
>>>> --cpu-type=O3CPU --caches -c tests/test-progs/hello/bin/x86/linux/hello
>>>>
>>>> Terminal output:
>>>>
>>>>> $build/X86/gem5.opt --debug-flags=Exec --debug-file=debug.txt
>>>>>> configs/example/se.py --cpu-type=O3CPU --caches -c
>>>>>> tests/test-progs/hello/bin/x86/linux/hello
>>>>>
>>>>> gem5 Simulator System.  http://gem5.org
>>>>>
>>>>> gem5 is copyrighted software; use the --copyright option for details.
>>>>>
>>>>>
>>>>>> gem5 version 21.1.0.0
>>>>>
>>>>> gem5 compiled Aug 10 2021 19:50:47
>>>>>
>>>>> gem5 started Aug 10 2021 22:07:52
>>>>>
>>>>> gem5 executing on uc12, pid 1240379
>>>>>
>>>>> command line: build/X86/gem5.opt --debug-flags=Exec
>>>>>> --debug-file=debug.txt configs/example/se.py --cpu-type=O3CPU --caches -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
>>>>>
>>>>> warn: No dot file generated. Please install pydot to generate the dot
>>>>>> file and pdf.
>>>>>
>>>>> build/X86/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/X86/sim/simulate.cc:107: info: Entering event queue @ 0.
>>>>>> Starting simulation...
>>>>>
>>>>> build/X86/arch/x86/insts/static_inst.cc:252: panic: Unrecognized
>>>>>> register class.
>>>>>
>>>>> Memory Usage: 630156 KBytes
>>>>>
>>>>> Program aborted at tick 1281000
>&g

[gem5-users] Re: static_inst.cc panic or assertion error when debugging execution of an x86 O3CPU

[Gabe Black via gem5-users]

On Wed, Aug 11, 2021 at 7:20 AM Deric Cheung via gem5-users <
gem5-users@gem5.org> wrote:

> I implemented that patch (
> https://gem5-review.googlesource.com/c/public/gem5/+/49183) and now the
> panic in static_inst.cc no longer occurs. Thank you!
>
> However I still encounter a failed assertion (gem5.opt:
> build/X86/arch/x86/insts/static_inst.cc:144: static void
> gem5::X86ISA::X86StaticInst::printReg(std::ostream&, gem5::RegId, int):
> Assertion `size == 1 || size == 2 || size == 4 || size == 8' failed.) when
> running this command:
>
> build/X86/gem5.opt --debug-flags=Exec --debug-file=debug.txt
> --debug-start=1000 configs/example/se.py --cpu-type=O3CPU --caches -c
> tests/test-progs/threads/bin/x86/linux/threads
>
> Log:
> $ build/X86/gem5.opt --debug-flags=Exec --debug-file=debug.txt
> --debug-start=1000 configs/example/se.py --cpu-type=O3CPU --caches -c
> tests/test-progs/threads/bin/x86/linux/threads
> gem5 Simulator System.  http://gem5.org
> gem5 is copyrighted software; use the --copyright option for details.
>
> gem5 version 21.1.0.0
> gem5 compiled Aug 11 2021 08:12:16
> gem5 started Aug 11 2021 08:15:32
> gem5 executing on uc12, pid 1408288
> command line: build/X86/gem5.opt --debug-flags=Exec --debug-file=debug.txt
> --debug-start=1000 configs/example/se.py --cpu-type=O3CPU --caches -c
> tests/test-progs/threads/bin/x86/linux/threads
>
> 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
> warn: No dot file generated. Please install pydot to generate the dot file
> and pdf.
> build/X86/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/X86/sim/simulate.cc:107: info: Entering event queue @ 0.  Starting
> simulation...
> build/X86/arch/x86/cpuid.cc:180: warn: x86 cpuid family 0x:
> unimplemented function 13
> gem5.opt: build/X86/arch/x86/insts/static_inst.cc:144: static void
> gem5::X86ISA::X86StaticInst::printReg(std::ostream&, gem5::RegId, int):
> Assertion `size == 1 || size == 2 || size == 4 || size == 8' failed.
> Program aborted at tick 10277500
> --- BEGIN LIBC BACKTRACE ---
> build/X86/gem5.opt(+0x1074340)[0x55744c0c4340]
> build/X86/gem5.opt(+0x109393e)[0x55744c0e393e]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7f3f7d2353c0]
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7f3f7c7d818b]
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x12b)[0x7f3f7c7b7859]
> /lib/x86_64-linux-gnu/libc.so.6(+0x25729)[0x7f3f7c7b7729]
> /lib/x86_64-linux-gnu/libc.so.6(+0x36f36)[0x7f3f7c7c8f36]
> build/X86/gem5.opt(+0x7a680a)[0x55744b7f680a]
> build/X86/gem5.opt(+0xb1e459)[0x55744bb6e459]
> build/X86/gem5.opt(+0xe913fd)[0x55744bee13fd]
> build/X86/gem5.opt(+0xe83859)[0x55744bed3859]
> build/X86/gem5.opt(+0xfa9893)[0x55744bff9893]
> build/X86/gem5.opt(+0xfaad51)[0x55744bffad51]
> build/X86/gem5.opt(+0xfac650)[0x55744bffc650]
> build/X86/gem5.opt(+0xfaca08)[0x55744bffca08]
> build/X86/gem5.opt(+0xfbd469)[0x55744c00d469]
> build/X86/gem5.opt(+0x10815f6)[0x55744c0d15f6]
> build/X86/gem5.opt(+0x10af334)[0x55744c0ff334]
> build/X86/gem5.opt(+0x10afb82)[0x55744c0ffb82]
> build/X86/gem5.opt(+0xc7d2f2)[0x55744bccd2f2]
> build/X86/gem5.opt(+0x6804b3)[0x55744b6d04b3]
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x2a8738)[0x7f3f7d4eb738]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x8dd8)[0x7f3f7d2c0f48]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalCodeWithName+0x8fb)[0x7f3f7d40de3b]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyFunction_Vectorcall+0x94)[0x7f3f7d4eb114]
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x74d6d)[0x7f3f7d2b7d6d]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x7d86)[0x7f3f7d2bfef6]
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x8006b)[0x7f3f7d2c306b]
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x74d6d)[0x7f3f7d2b7d6d]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x12fd)[0x7f3f7d2b946d]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(

[gem5-users] Re: static_inst.cc panic or assertion error when debugging execution of an x86 O3CPU

[Gabe Black via gem5-users]

Please give this a try:

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

On Tue, Aug 10, 2021 at 9:37 PM Deric Cheung via gem5-users <
gem5-users@gem5.org> wrote:

> Host OS: Ubuntu 12.04 LTS
> Host CPU: Intel i7-2600 3.40 GHz
>
> I'm trying to debug an x86 application on an O3CPU using syscall
> emulation, but static_inst.cc panics or runs into an assertion error. Ideas
> for how I can debug or solve this issue?
>
> Example command 1 (causing panic): build/X86/gem5.opt --debug-flags=Exec
> --debug-file=debug.txt configs/example/se.py --cpu-type=O3CPU --caches -c
> tests/test-progs/hello/bin/x86/linux/hello
>
> Terminal output:
>
>> $build/X86/gem5.opt --debug-flags=Exec --debug-file=debug.txt
>>> configs/example/se.py --cpu-type=O3CPU --caches -c
>>> tests/test-progs/hello/bin/x86/linux/hello
>>
>> gem5 Simulator System.  http://gem5.org
>>
>> gem5 is copyrighted software; use the --copyright option for details.
>>
>>
>>> gem5 version 21.1.0.0
>>
>> gem5 compiled Aug 10 2021 19:50:47
>>
>> gem5 started Aug 10 2021 22:07:52
>>
>> gem5 executing on uc12, pid 1240379
>>
>> command line: build/X86/gem5.opt --debug-flags=Exec
>>> --debug-file=debug.txt configs/example/se.py --cpu-type=O3CPU --caches -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
>>
>> warn: No dot file generated. Please install pydot to generate the dot
>>> file and pdf.
>>
>> build/X86/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/X86/sim/simulate.cc:107: info: Entering event queue @ 0.  Starting
>>> simulation...
>>
>> build/X86/arch/x86/insts/static_inst.cc:252: panic: Unrecognized register
>>> class.
>>
>> Memory Usage: 630156 KBytes
>>
>> Program aborted at tick 1281000
>>
>> --- BEGIN LIBC BACKTRACE ---
>>
>> build/X86/gem5.opt(+0x10743b0)[0x5647381dc3b0]
>>
>> build/X86/gem5.opt(+0x10939ae)[0x5647381fb9ae]
>>
>> /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7fa5889d33c0]
>>
>> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7fa587f7618b]
>>
>> /lib/x86_64-linux-gnu/libc.so.6(abort+0x12b)[0x7fa587f55859]
>>
>> build/X86/gem5.opt(+0x30e015)[0x564737476015]
>>
>> build/X86/gem5.opt(+0x7a6964)[0x56473790e964]
>>
>> build/X86/gem5.opt(+0x85464b)[0x5647379bc64b]
>>
>> build/X86/gem5.opt(+0xe9146d)[0x564737ff946d]
>>
>> build/X86/gem5.opt(+0xe838c9)[0x564737feb8c9]
>>
>> build/X86/gem5.opt(+0xfa9fcd)[0x564738111fcd]
>>
>> build/X86/gem5.opt(+0xfaadc1)[0x564738112dc1]
>>
>> build/X86/gem5.opt(+0xfac6c0)[0x5647381146c0]
>>
>> build/X86/gem5.opt(+0xfaca78)[0x564738114a78]
>>
>> build/X86/gem5.opt(+0xfbd4d9)[0x5647381254d9]
>>
>> build/X86/gem5.opt(+0x1081666)[0x5647381e9666]
>>
>> build/X86/gem5.opt(+0x10af3a4)[0x5647382173a4]
>>
>> build/X86/gem5.opt(+0x10afbf2)[0x564738217bf2]
>>
>> build/X86/gem5.opt(+0xc7d362)[0x564737de5362]
>>
>> build/X86/gem5.opt(+0x680583)[0x5647377e8583]
>>
>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x2a8738)[0x7fa588c89738]
>>
>>
>>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x8dd8)[0x7fa588a5ef48]
>>
>>
>>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalCodeWithName+0x8fb)[0x7fa588babe3b]
>>
>>
>>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyFunction_Vectorcall+0x94)[0x7fa588c89114]
>>
>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x74d6d)[0x7fa588a55d6d]
>>
>>
>>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x7d86)[0x7fa588a5def6]
>>
>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x8006b)[0x7fa588a6106b]
>>
>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x74d6d)[0x7fa588a55d6d]
>>
>>
>>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x12fd)[0x7fa588a5746d]
>>
>>
>>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalCodeWithName+0x8fb)[0x7fa588babe3b]
>>
>>
>>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyFunction_Vectorcall+0x94)[0x7fa588c89114]
>>
>> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x74d6d)[0x7fa588a55d6d]
>>
>> --- END LIBC BACKTRACE ---
>>
>> Aborted
>>
>>
> Example command 2 (causing assertion error): build/X86/gem5.opt
> --debug-flags=Exec --debug-file=debug.txt --debug-start=1000
> configs/example/se.py --cpu-type=O3CPU 

[gem5-users] Re: Implicit Register Dependencies in x86

[Gabe Black via gem5-users]

Great, I'm glad that fixed it for you. Could you please upload your fix so
other people can benefit from it too?

https://www.gem5.org/contributing

Gabe

On Mon, Jul 26, 2021 at 11:39 AM Mohit Gambhir via gem5-users <
gem5-users@gem5.org> wrote:

> Thanks for that workaround. Introducing additional variables  hiResult and
> loResult for ProdHi and ProdLo and using the new variables always on RHS
> resolves the issue for now.
>
> Regards,
> Mohit
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Implicit Register Dependencies in x86

[Gabe Black via gem5-users]

Yes, I haven't looked at the code itself, but that explanation seems very
plausible. The way the ISA parser works is basically if something is on the
left hand side of an =, then it's assumed to be a destination, and
otherwise it's a source. It bases its decision *purely* on text, with no
understand of liveness, where values came from, or even more subtle things
like being set by a function when passed by reference.

One trick you can use, and which you'll find in other places in the ISA
descriptions (particularly ARM I think), is to assign the result of a
computation to a temporary like "result" which doesn't mean anything to the
parser. Then you can use that variable to compute flags, etc, without the
parser thinking you're reading the original version of that register.
Separately, you can assign result to the destination register, which the
also successfully tell the parser how to treat that operand.

uint64_t result = Src1 * Src2;
computeFlags(result);
Dest = result;

I have some grand plans for how to make the parser and ISA generation in
general more sophisticated in several different ways, at which point these
sorts of tricks will hopefully be unnecessary. In the meantime though, this
may help solve your problem. If it works, please send out a review so we
can fix this for other folks too.

Gabe

On Fri, Jul 23, 2021 at 12:20 PM Mohit Gambhir via gem5-users <
gem5-users@gem5.org> wrote:

> Hi Gabe,
>
> I think your code has not yet made into stable/master branch. I see that
> in develop branch INTREG_IMPLICIT is no longer there and is replaced by
> INTREG_PRODHI and INTREG_PRODLO
>
> However, I see that even in develop branch there are two classes that are
> generated - Mul1s and Mul1sFlags. In Mul1s INTREG_PRODLO and INTREG_PRODHI
> are not added as source and are only added as destination. But in
> Mul1sFlags class they are added both as source and destination.
>
> class Mul1s : public X86ISA::RegOpT X86ISA::FoldedSrc2Op>
> {
>   ...
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, src1));
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, src2));
> setDestRegIdx(_numDestRegs++, RegId(IntRegClass,
> X86ISA::INTREG_PRODLOW));
> _numIntDestRegs++;
> setDestRegIdx(_numDestRegs++, RegId(IntRegClass,
> X86ISA::INTREG_PRODHI));
> _numIntDestRegs++;
> ...
> }
>
> class Mul1sFlags : public X86ISA::RegOpT X86ISA::FoldedSrc2Op>
> {
> .
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, src1));
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, src2));
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass,
> X86ISA::INTREG_PRODLOW));
> setDestRegIdx(_numDestRegs++, RegId(IntRegClass,
> X86ISA::INTREG_PRODLOW));
> _numIntDestRegs++;
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass,
> X86ISA::INTREG_PRODHI));
> setDestRegIdx(_numDestRegs++, RegId(IntRegClass,
> X86ISA::INTREG_PRODHI));
>
> }
>
> Any idea why that would be? Does it have anything to do with how Mul1s is
> defined in src/arch/x86/isa/microops/regop.isa. I see that flags_code in
> that definition does read ProdHi and ProdLow but it is being produced by
> the same instruction. Does isa_parser naively treat it as source because it
> is RHS in flags code? My understanding of isa_parser is very primitive so
> any help there will be appreciated.
>
> Thanks!
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Implicit Register Dependencies in x86

[Gabe Black via gem5-users]

That sounds plausible. In general, when you write to a register in x86, you
may be doing a partial write where the old data in the register needs to be
preserved. For instance, if %rax has 0x0123456789abcdef in it, and you want
to write 0x1 to %al, then you need both the old value and the value you're
writing to create 0x0123456789abcd01. I think there are some mechanisms in
place which avoid bringing in a register as a source if, for instance,
you're writing 32 or 64 bits which either zero fill the upper 32 bits, or
just plain overwrite all the bits, although I don't remember the specifics.
It could be that this is not being applied to ProdHi or ProdLow for some
reason.

In any case, since ProdHi and ProdLow are just temporary holding spots for
the output of the multiplier, it doesn't make sense to use partial writes
to them ever, even if the output size was 8 or 16 bits. You'll never need
to know what was in the other bits of ProdHi or ProdLow, even if you need
to know what was in the upper bits of whatever architectural register
you're ultimately writing their values into.

It's a little confusing due to the overloaded terminology, but I think if
you look for "predicated" or something like that in the x86 ISA
description's operands definitions, you should find what I'm talking about.
I have some changes which I think are still pending (mabye?) which
significantly rework how operands for x86 microops are handled and make
them much more precise in how they're applied, how the instructions are
disassembled, etc. Part of that also had to do with when/if registers are
"picked", aka only a part of their value is used, or "merged", aka
partially written, I think. Sorry I can't be more specific than that, I
wrote those changes months ago. I think they went in, although I'm not
completely certain of that. I think I also got rid of the INTREG_IMPLICIT
method, so it looks like you're using a slightly older version of gem5 as
well.

Gabe

On Wed, Jul 21, 2021 at 10:58 AM mohit.gambhir84--- via gem5-users <
gem5-users@gem5.org> wrote:

> Hi Ayaz,
>
> Thanks for your reply. You are right that they do get renamed and are
> assigned a different destination physical register for each instruction.
> But, as you see below, IMPLICIT(0) and IMPLICIT(1) are both source and
> destination for IMUL_R_R instruction. So each instruction is still waiting
> for the previous instruction to complete and write to previous physical
> registers that are then used as sources, creating a chain of dependencies.
>
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, INTREG_IMPLICIT(0)));
> setDestRegIdx(_numDestRegs++, RegId(IntRegClass, INTREG_IMPLICIT(0)));
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, INTREG_IMPLICIT(1)))
> setDestRegIdx(_numDestRegs++, RegId(IntRegClass, INTREG_IMPLICIT(1)));
>
> Including a trace from rename stage for just implicit(0) register
>
> 16665750: system.cpu.rename: [tid:0] Processing instruction [sn:34990]
> with PC (0x400c0f=>0x400c13).(1=>2).
> 16665750: system.cpu.rename: [tid:0] Looking up IntRegClass arch reg 32,
> got phys reg 54 (IntRegClass)
> 16665750: system.cpu.rename: [tid:0] Register 54 (flat: 54) (IntRegClass)
> is not ready.
> 16665750: system.cpu.rename: [tid:0] Renaming arch reg 32 (IntRegClass) to
> physical reg 10 (10).
> ...
> 16665750: system.cpu.rename: [tid:0] Processing instruction [sn:34992]
> with PC (0x400c13=>0x400c17).(0=>1).
> 16665750: system.cpu.rename: [tid:0] Looking up IntRegClass arch reg 32,
> got phys reg 10 (IntRegClass)
> 16665750: system.cpu.rename: [tid:0] Register 10 (flat: 10) (IntRegClass)
> is not ready.
>
> Does that make sense?
>
> Regards,
> Mohit
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Building Gem5 on Ubuntu 20.04 - Failure details

[Gabe Black via gem5-users]

Yeah, this looks like your system ran out of memory:

g++: fatal error: Killed signal terminated program lto1

That's probably the kernel going around killing processes using lots of
memory since it's running out.

Gabe

On Mon, May 24, 2021 at 7:27 PM Eliot Moss  wrote:

> On 5/24/2021 10:12 PM, Gabe Black wrote:
> > The last lines in your original email are:
> >
> >   [SOPARMHH] VirtIO9PBase -> X86/params/VirtIO9PBase.hh
> >   [SOPARMHH] VirtIO9PDiod -> X86/params/VirtIO9PDiod.hh
> >   [SOPARMHH] VirtIO9PProxy -> X86/params/VirtIO9PProxy.hh
> >   [SOPARMHH] VirtIO9PSocket -> X86/params/VirtIO9PSocket.hh
> >   [ CXX] X86/dev/virtio/fs9p.cc -> .o
> >   [SOPARMCC] AMPMPrefetcher -> X86/params/AMPMPrefetcher.cc
> >   [ CXX] X86/params/AMPMPrefetcher.cc -> .o
> >   [SOPARMCC] AccessMapPatternMatching ->
> X86/params/AccessMapPatternMatching.cc
> >   [ CXX] X86/params/AccessMapPatternMatching.cc -> .o
> >   [SOPARMCC] AtomicSimpleCPU -> X86/params/AtomicSimpleCPU.cc
> >   [ CXX] X86/params/AtomicSimpleCPU.cc -> .o
> >   [SOPARMCC] BIPRP -> X86/params/BIPRP.cc
> >   [ CXX] X86/params/BIPRP.cc -> .o
> >
> > Did it get cut off?
>
> Yes; maybe the mailing list has a max length?  Here's what was at the end:
>
>   [   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
>   [  AR]  -> drampower/libdrampower.a
>   [  RANLIB]  -> drampower/libdrampower.a
>   [LINK]  -> X86/gem5.opt
> g++: fatal error: Killed signal terminated program lto1
> compilation terminated.
> make: *** [/tmp/ccEY6Dte.mk:41: /tmp/gem5.opt.Gp3kKc.ltrans13.ltrans.o]
> Error 1
> make: *** Waiting for unfinished jobs
> lto-wrapper: fatal error: make returned 2 exit status
> compilation terminated.
> /usr/bin/ld: error: lto-wrapper failed
> collect2: error: ld returned 1 exit status
> scons: *** [build/X86/gem5.opt] Error 1
> scons: building terminated because of errors.
>
> Hope this comes through for you.  I thought the whole thing went
> to the list ... EM
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Building Gem5 on Ubuntu 20.04 - Failure details

[Gabe Black via gem5-users]

The last lines in your original email are:

 [SOPARMHH] VirtIO9PBase -> X86/params/VirtIO9PBase.hh
 [SOPARMHH] VirtIO9PDiod -> X86/params/VirtIO9PDiod.hh
 [SOPARMHH] VirtIO9PProxy -> X86/params/VirtIO9PProxy.hh
 [SOPARMHH] VirtIO9PSocket -> X86/params/VirtIO9PSocket.hh
 [ CXX] X86/dev/virtio/fs9p.cc -> .o
 [SOPARMCC] AMPMPrefetcher -> X86/params/AMPMPrefetcher.cc
 [ CXX] X86/params/AMPMPrefetcher.cc -> .o
 [SOPARMCC] AccessMapPatternMatching -> X86/params/AccessMapPatternMat
ching.cc
 [ CXX] X86/params/AccessMapPatternMatching.cc -> .o
 [SOPARMCC] AtomicSimpleCPU -> X86/params/AtomicSimpleCPU.cc
 [ CXX] X86/params/AtomicSimpleCPU.cc -> .o
 [SOPARMCC] BIPRP -> X86/params/BIPRP.cc
 [ CXX] X86/params/BIPRP.cc -> .o

Did it get cut off?

On Mon, May 24, 2021 at 7:06 PM Eliot Moss  wrote:

> On 5/24/2021 10:04 PM, Gabe Black wrote:
> > Well, whatever the reason, there are no error messages in your original
> email :-)
>
> What you see is everything produced to the terminal by running the command.
> What would you expect to see?  :-)
>
> Best - Eliot
>
> > On Mon, May 24, 2021 at 7:01 PM Eliot Moss  m...@cs.umass.edu>> wrote:
> >
> > On 5/24/2021 9:47 PM, Gabe Black wrote:
> >   > Hi Eliot, unfortunately this output doesn't seem to include
> stderr, and so doesn't have any
> > of the
> >   > error messages.
> >
> > The |& below puts stdout and stderr together.  So it has all the
> error
> > messages that were produced by this combination of flags.  If I
> additionally
> > set -flto-record, in the past I have gotten a number of megabytes of
> messages
> > complaining about things missing in debug-related sections of
> decoder.o (I
> > forget which decoder.o - sorry).  I can try to generate that as
> well, if you
> > think it will help ...
> >
> > EM
> >
> > (large output trimmed)
> >
> >   > On Mon, May 24, 2021 at 6:44 PM Eliot Moss via gem5-users <
> gem5-users@gem5.org
> > 
> >   > >>
> wrote:
> >   >
> >   > This is more for the record.  I set up a docker according to
> the Gem5 web
> >   > pages, using the Ubuntu 20.04.  I made sure my git clone of
> current gem5 was
> >   > not modified and I removed the build/ hierarchy.  In /gem5 I
> ran this command:
> >   >
> >   > scons build/X86/gem5.opt -j2 |& tee gem5.opt.out.txt
> >
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Building Gem5 on Ubuntu 20.04 - Failure details

[Gabe Black via gem5-users]

Well, whatever the reason, there are no error messages in your original
email :-)

Gabe

On Mon, May 24, 2021 at 7:01 PM Eliot Moss  wrote:

> On 5/24/2021 9:47 PM, Gabe Black wrote:
>  > Hi Eliot, unfortunately this output doesn't seem to include stderr, and
> so doesn't have any of the
>  > error messages.
>
> The |& below puts stdout and stderr together.  So it has all the error
> messages that were produced by this combination of flags.  If I
> additionally
> set -flto-record, in the past I have gotten a number of megabytes of
> messages
> complaining about things missing in debug-related sections of decoder.o (I
> forget which decoder.o - sorry).  I can try to generate that as well, if
> you
> think it will help ...
>
> EM
>
> (large output trimmed)
>
>  > On Mon, May 24, 2021 at 6:44 PM Eliot Moss via gem5-users <
> gem5-users@gem5.org
>  > > wrote:
>  >
>  > This is more for the record.  I set up a docker according to the
> Gem5 web
>  > pages, using the Ubuntu 20.04.  I made sure my git clone of current
> gem5 was
>  > not modified and I removed the build/ hierarchy.  In /gem5 I ran
> this command:
>  >
>  > scons build/X86/gem5.opt -j2 |& tee gem5.opt.out.txt
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Building Gem5 on Ubuntu 20.04

[Gabe Black via gem5-users]

Yeah, I wouldn't have expected that either, but if that's what you're
seeing it's hard to argue otherwise. I don't think that's an inherent
behavior of LTO, but it might be an unintended side effect somehow, maybe
pulled in indirectly? It's probably worth a Jira ticket.

Gabe

On Mon, May 24, 2021 at 1:48 PM Bobby Bruce  wrote:

> In regards to debug symbols on the stable branch: All i can say for sure
> is the debug symbols are being stripped right now with LTO enabled by
> default, and they aren't stripped if you pass `--no-lto`. I wouldn't have
> expected LTO to work this way, but this is our observation and one of the
> reason's we're going to disable it by default.
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Mon, May 24, 2021 at 1:43 PM Gabe Black  wrote:
>
>> I don't think LTO strips debug symbols... But yes, LTO does significantly
>> increase link time if your machine doesn't have lots of cores to
>> parallelize the link. It slows it down in general, but with gcc you can
>> parallelize the link with LTO where you can't without LTO for some reason,
>> and that outweighs the other overhead if you have enough cores to throw at
>> it.
>>
>> Especially when running in a virtual machine, you might just be running
>> out of memory. LTO will use more ram, and if you run out things will fail
>> in potentially strange ways.
>>
>> It sounds like you have a workaround for now so this may be a moot point,
>> but in general, when you report compiler errors (or errors in general) it's
>> very helpful to provide the error output instead of just describing the
>> errors. That provides a lot of helpful detail which can make diagnosing the
>> problem much easier.
>>
>> Gabe
>>
>> On Mon, May 24, 2021 at 1:07 PM Bobby Bruce via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> Thanks for the report Eliot. In this case there's no need to file a bug
>>> report as we're about to produce a minor release of gem5 that will off LTO
>>> by default. I'm not familiar with this particular problem you are facing,
>>> but we've found we need to turn it off for other reasons (1. It increases
>>> links times for some users to unacceptable levels and 2. LTO strips debug
>>> symbols which you'll need if you want to run tools such as GDB).
>>>
>>> I'm hoping we can ship the minor release sometime this week!
>>>
>>> --
>>> Dr. Bobby R. Bruce
>>> Room 3050,
>>> Kemper Hall, UC Davis
>>> Davis,
>>> CA, 95616
>>>
>>> web: https://www.bobbybruce.net
>>>
>>>
>>> On Mon, May 24, 2021 at 12:43 PM Eliot Moss via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
 Dear Gem5-ers:

 I have been trying to build Gem5 out of the box, for x86, on a
 VirtualBox
 virtual machine set up for 64-bit Ubuntu 20.04 ("focal").  I can do

 scons build/X86/gem5.opt

 but it will succeed only if I disable link time optimization LTO using
 --no-lto.  I've tried various versions GCC - 7, 8, 9, and 10 - and all
 produce the same result.  (I think the key thing is probably something
 in
 binutils, but I don't know what version to try to obtain, and this
 version of
 Ubuntu does not readily offer anything other than 2.34.)

 Searching the web about this general problem mostly produces the
 "solution" of
 disabling LTO.  So, where should we / I file a bug report?  By turning
 on LTO
 reporting, I have found that the proximal cause is that decoder.o does
 not
 have a .debug_str section and yet there are a huge number of references
 to
 things that should be there (labels, I guess - the decode *would* have
 a lot
 of those!).

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

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

[gem5-users] Re: Guidance on adding an x86 instruction

[Gabe Black via gem5-users]

Hi Eliot. The decoder, particularly the x86 decoder, is one of the most
complex areas of gem5, and unfortunately there isn't any comprehensive
documentation explaining how it works. I did put together this document a
while ago (
https://docs.google.com/document/d/1quwxZOPb181jVWAh_7nX7E6uJM-7d9VDU9KxKkGmIrY/edit#heading=h.ogwesp50kyg)
which describes how the decoders in gem5 work in general, although I
haven't looked at it in a while and I don't remember exactly what's in
there.

As far as the tags which describe where an instructions operands come from,
the most important part of the implementation is specialize.py, I think. It
may have a slightly different name. That file implements the code which
parses the tags and prepares operands for the instruction, whether they're
registers, address components, etc. The tags themselves are based on the
operand description shorthand used in the AMD manuals in their instruction
reference, where generally one letter describes where the operand comes
from, and another letter describes the operand size. The actual size will
usually depend on other factors like the default operand size, the mode
you're in, etc, so the letter for the size really describes a pattern of
sizing than a particular size.

The microops themselves are more like what you would see in other ISAs
since they're the actual instructions which get executed by the CPUs. The
one additional difference is that they plug into the microcode assembler so
that they can be used in macroops. That's done with a python class which is
instantiated using the operands from the microcode, so, roughtly speaking:

add r1, r2, r3, operand_size=2

could map to:

Add(r1, r2, r3, operand_size=2)

where Add is the python class which represents the microop. The variables
r1, r2,  and r3 would be defined elsewhere as strings which will eventually
get pasted into the C++ and would be the index for r1, r2, r3, etc.

Gabe

On Mon, May 24, 2021 at 11:52 AM Eliot Moss via gem5-users <
gem5-users@gem5.org> wrote:

> Hi, all --
>
> I've been using an older version of Gem5 for some time (inherited from an
> existing project) for some ARM simulations, but now am moving to do
> something
> new on x86.
>
> The particular task where I'd like some guidance is this:
>
> I want to add an instruction that will send a command to the cache(s).  It
> does not need to mention a specific address, but may send some data.  I was
> thinking of encoding it the same way as clwb, but using the currently
> disallowed 11 (i.e., 3) combination of the mod/rm bits.  This generally
> indicates a register as opposed to a memory operand.  I think I have found
> more or less where to do this in the decoder, but if someone would respond
> about that, it would be helpful.
>
> Then there is the question of the other steps of adding an instruction,
> which
> starts getting more mysterious (e.g., what does Iz, for example mean, and
> is
> it what I want if I want this new instruction to have a register operand?).
>
> It will seem I'll need to add a micro-op as well.  I can follow the clwb
> model
> for that, except that this special thing will probably use some new flag in
> its request/packet that will head toward the cache (and of course I will be
> extending the cache to notice and handle that for the new thing I'm
> devising).
>
> An overall sketch of how to accomplish this successfully and going with the
> flow of the design would be great.  If there are specific pieces of
> documentation I should be looking at it, pointers to them would also be
> gratefully accepted.
>
> Regards, and thanks in advance - Eliot Moss
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Building Gem5 on Ubuntu 20.04

[Gabe Black via gem5-users]

I don't think LTO strips debug symbols... But yes, LTO does significantly
increase link time if your machine doesn't have lots of cores to
parallelize the link. It slows it down in general, but with gcc you can
parallelize the link with LTO where you can't without LTO for some reason,
and that outweighs the other overhead if you have enough cores to throw at
it.

Especially when running in a virtual machine, you might just be running out
of memory. LTO will use more ram, and if you run out things will fail in
potentially strange ways.

It sounds like you have a workaround for now so this may be a moot point,
but in general, when you report compiler errors (or errors in general) it's
very helpful to provide the error output instead of just describing the
errors. That provides a lot of helpful detail which can make diagnosing the
problem much easier.

Gabe

On Mon, May 24, 2021 at 1:07 PM Bobby Bruce via gem5-users <
gem5-users@gem5.org> wrote:

> Thanks for the report Eliot. In this case there's no need to file a bug
> report as we're about to produce a minor release of gem5 that will off LTO
> by default. I'm not familiar with this particular problem you are facing,
> but we've found we need to turn it off for other reasons (1. It increases
> links times for some users to unacceptable levels and 2. LTO strips debug
> symbols which you'll need if you want to run tools such as GDB).
>
> I'm hoping we can ship the minor release sometime this week!
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Mon, May 24, 2021 at 12:43 PM Eliot Moss via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Dear Gem5-ers:
>>
>> I have been trying to build Gem5 out of the box, for x86, on a VirtualBox
>> virtual machine set up for 64-bit Ubuntu 20.04 ("focal").  I can do
>>
>> scons build/X86/gem5.opt
>>
>> but it will succeed only if I disable link time optimization LTO using
>> --no-lto.  I've tried various versions GCC - 7, 8, 9, and 10 - and all
>> produce the same result.  (I think the key thing is probably something in
>> binutils, but I don't know what version to try to obtain, and this
>> version of
>> Ubuntu does not readily offer anything other than 2.34.)
>>
>> Searching the web about this general problem mostly produces the
>> "solution" of
>> disabling LTO.  So, where should we / I file a bug report?  By turning on
>> LTO
>> reporting, I have found that the proximal cause is that decoder.o does not
>> have a .debug_str section and yet there are a huge number of references to
>> things that should be there (labels, I guess - the decode *would* have a
>> lot
>> of those!).
>>
>> Regards - Eliot
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Alternative of void * in syscall_emul.cc file

[Gabe Black via gem5-users]

Hi. VPtr<> is supposed to be equivalent to void *. Even with a c void *
though, you can't (in standard c) use it as an array of bytes. If you need
it to be an array of bytes, you need to use VPtr. There are some
facilities to cast VPtrs of different types, but I don't remember how
extensive that support is, or if VPtr<> is part of it. Also VPtrs in
general can't be used as arrays, just as pointers. You can approximate
using them as arrays by using pointer (like) arithmetic on them and
increment them with ++, or I think add an integer offset to them, etc. I
intend to give them that capability eventually, and then replace BufferArg
with VPtr so there's only one system. In the mean time, if you really need
array like behavior, you might want to use BufferArg, and manage its
contents manually with copyIn and copyOut. I would suggest using a
VPtr though, if what you're manipulating is an array of bytes and
you're accessing those bytes individually.

In the arguments for a system call, you should still use VPtr<> for a bare
pointer/address even if you access the data with BufferArg, since then the
system call mechanism will know that those arguments should be pointer
sized for whatever the simulated system is. VPtr<> can be cast to Addr
which will turn it into the underlying address which was passed in as an
argument. Something like this (not tested):

void
sayHello(SyscallDesc *desc, ThreadContext *tc, VPtr<> hello_ptr, size_t
size)
{
BufferArg hello_buf(hello_ptr, size);
hello_buf.copyIn(tc->getVirtProxy());
const char *hello_str = (const char *)hello_buf.bufferPtr();
std::cout << "Hello " << hello_str << "!\n";
hello_str[0] = '\0';
hello_buf.copyOut(tc->getVirtProxy());
}

Alternatively you could do mostly the same thing with VPtr (also
untested):

void
sayHello(SyscallDesc *desc, ThreadContext *tc, VPtr hello_ptr, size_t
size)
{
std::cout << "Hello ";
while (size--)
std::cout << *hello_ptr++;
std::cout << "!\n";
}

Gabe

On Mon, May 3, 2021 at 2:24 PM Harsh via gem5-users 
wrote:

> I'm trying to implement a few of the system calls. The system call 318
> includes copying random bytes to a void* few. However, in the
> src/sim/syscall_emul.cc file, I could not find any use of void* there are
> uses of VPtr<>. I'm not sure whether they are the same thing.
>
> Also, I looked into the implementation of VPtr<>
> http://pages.cs.wisc.edu/~swilson/gem5-docs/vptr_8hh_source.html#l00083
> and there is no functionality of inserting elements into the underlying
> buffer attribute. I tried creating the BufferArg object and then calling
> its bufferPtr() method, however, I'm not sure if this is the best method.
> Some of the examples make use of std::memcpy on the bufferPtr, but I do not
> have any other buffer object to copy from.
>
> Can someone please confirm whether VPtr<> is the alternative of void* and
> whether there is any other way to implement
> for (int i = 0; i < size ; i++) {buf[i] = some random byte;} using VPtr<>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Error while building gem5

[Gabe Black via gem5-users]

This question has been asked (and answered) on this list already. Please
don't ask the same question multiple times.

Gabe

On Wed, Apr 21, 2021 at 9:14 PM VAIDYA ROHINI VILAS via gem5-users <
gem5-users@gem5.org> wrote:

> Hello,
> I am trying to build gem5 for X86 architecture but it does not
> successfully build due to errors.
> Here I am attaching a screenshot of the error.
> Please help me to solve this issue ASAP.
> THank you.
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Error while building gem5

[Gabe Black via gem5-users]

It looks like you might be running out of memory, which building too many
things at once could contribute to. The final link is going to use a lot of
memory no matter what, most likely.

Gabe

On Wed, Apr 21, 2021 at 3:34 AM Hoa Nguyen  wrote:

> Hi,
>
> Can you be more specific about the command line and the gem5 version
> that you used?
>
> From the screenshot, it seems to be a problem with LTO. You can
> compile gem5 with --no-lto flag to not to use LTO for compiling.
>
> Regards,
> Hoa Nguyen
>
> On 4/20/21, VAIDYA ROHINI VILAS  wrote:
> > Hello,
> > I am trying to build gem5 for X86 architecture but it does not
> successfully
> > build due to errors.
> > Here I am attaching a screenshot of the error.
> > Please help me to solve this issue ASAP.
> > THank you.
> >
> >
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: How to debug a program in GEM5 FS mode.

[Gabe Black via gem5-users]

Yeah, I don't think gdb in SE mode handles page faults well, but there was
actually a change proposed very recently which should help improve that.
You can probably cherry-pick that change locally if you want to try it out.

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

Gabe

On Tue, Apr 20, 2021 at 11:16 PM Liyichao  wrote:

> Thanks Gabe.
>
> I think run gdb inside gem5 is of course a better method but slow speed.
>
> In se mode，I also have tried it，
> but my program in se mode has a page fault  panic before segment fault.I 
> think se mode cannot process page fault.
>
>
>
>
> --
>
> 李翼超 charlie
> Mobile：+86-15858232899
> Email：liyic...@huawei.com
>
>
> *发件人： *Gabe Black
> *收件人： *gem5 users mailing list
> *抄送： *Liyichao
> *主题： *Re: [gem5-users] How to debug a program in GEM5 FS mode.
> *时间： *2021-04-21 14:06:58
>
> Hello, Liyichao. While gdb debugging in gem5 is a great tool, it's a bit
> limited as far as the sort of debugging you're talking about. It can see
> the CPU state when you're in user space programs, but it doesn't understand
> that different user space programs are different things, or know how to
> look up their symbols, etc. It's intended primarily for debugging the
> kernel, since that's frankly a more tractable problem. It would be possible
> to extend that support to give it more insight into what's going on inside
> the kernel so it can do more in that regard, and while I'd like to do that
> at some point, that's not anything that will happen soon.
>
> If you want to debug a user space program inside gem5, I think your best
> bet is to debug it in SE mode where the only thing running is your program.
> SE mode is more approximate than FS mode and can't run every program, but
> if it can run yours that's probably what you'll want to do.
>
> Another option would be to run gdb *inside* gem5, as part of the
> simulation. I don't know if anybody has tried that, but then gdb should
> work like it would on a real ARM host, more or less.
>
> Gabe
>
> On Tue, Apr 20, 2021 at 7:27 PM Liyichao via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi All:
>>
>>  I am currently debugging a program with an SVE instruction in
>> the FS mode of GEM5. However, a segment error occurs in the program.
>> Therefore, I want to locate which instruction is causing the error and
>> check the contents of the register of the error instruction. What are the
>> debugging methods of GEM5 for applications in FS mode? Because programs
>> with SVE instructions cannot be debugged directly on the ARM server, I want
>> to debug in FS mode of GEM5.
>>
>>
>>
>> Does the Remote GDB support the preceding operations? Are there detailed
>> instructions for REMOTE GDB? The Remote GDB guidance on the GEM5 website is
>> a little brief.
>>
>>
>>
>> TKS.
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: How to debug a program in GEM5 FS mode.

[Gabe Black via gem5-users]

Hello, Liyichao. While gdb debugging in gem5 is a great tool, it's a bit
limited as far as the sort of debugging you're talking about. It can see
the CPU state when you're in user space programs, but it doesn't understand
that different user space programs are different things, or know how to
look up their symbols, etc. It's intended primarily for debugging the
kernel, since that's frankly a more tractable problem. It would be possible
to extend that support to give it more insight into what's going on inside
the kernel so it can do more in that regard, and while I'd like to do that
at some point, that's not anything that will happen soon.

If you want to debug a user space program inside gem5, I think your best
bet is to debug it in SE mode where the only thing running is your program.
SE mode is more approximate than FS mode and can't run every program, but
if it can run yours that's probably what you'll want to do.

Another option would be to run gdb *inside* gem5, as part of the
simulation. I don't know if anybody has tried that, but then gdb should
work like it would on a real ARM host, more or less.

Gabe

On Tue, Apr 20, 2021 at 7:27 PM Liyichao via gem5-users 
wrote:

> Hi All:
>
>  I am currently debugging a program with an SVE instruction in the
> FS mode of GEM5. However, a segment error occurs in the program. Therefore,
> I want to locate which instruction is causing the error and check the
> contents of the register of the error instruction. What are the debugging
> methods of GEM5 for applications in FS mode? Because programs with SVE
> instructions cannot be debugged directly on the ARM server, I want to debug
> in FS mode of GEM5.
>
>
>
> Does the Remote GDB support the preceding operations? Are there detailed
> instructions for REMOTE GDB? The Remote GDB guidance on the GEM5 website is
> a little brief.
>
>
>
> TKS.
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: ARM and opening a file

[Gabe Black via gem5-users]

If this works on x86, the chances are good that the system call
implementations are fine since they're likely the same between the two, but
there could be some glue (flag translation, which system calls that are
hooked up) which is different. You should try enabling the system call
DPRINTF flags (--debug-flags on the command line) to see what system calls
are being called, and what they're returning. If a system call which isn't
implemented is being called, there should be a message about it from gem5.

Gabe

On Tue, Apr 20, 2021 at 1:45 PM Bobby Bruce via gem5-users <
gem5-users@gem5.org> wrote:

> Hey Majid,
>
> Are you running in FS or SE mode? If you're running in SE mode, I don't
> find this too surprising as not all System calls are currently supported.
>
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 2235,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Wed, Apr 14, 2021 at 8:16 PM Majid Jalili via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi,
>> When I was running SPEC CPU 2017, in particular 505.mcf_r, I noticed that
>> if gem5 should open a file, it will not make any progress. I dig into mcf
>> code and found when the read_min function is called the simulation freezes.
>> Then I started running a simple benchmark as follows, that just prints
>> the content of a file:
>>
>> https://www.geeksforgeeks.org/c-program-print-contents-file/
>>
>> For this example, I also run into the same problem. I tried X86 and
>> everything works just fine
>>
>> Repo:  I tried both dev and stable
>> gcc: aarch64-linux-gnu-gcc-7 aarch64-linux-gnu-gcc-5
>>
>> Any help is great!
>>
>>
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Simulating modern Smartphone System on Chip with Android 11 image

[Gabe Black via gem5-users]

1. Yes. You can also use the ethernet bridge to bridge the network within
gem5 out to the host network so you can access the "real" network/internet.
2. Yes, caches are separate components, so you can add in caches as you
want, and configure their properties.

Gabe

On Fri, Apr 16, 2021 at 10:05 AM Pavel Golikov via gem5-users <
gem5-users@gem5.org> wrote:

> I see. Thank you. Another few questions if I may:
>
> 1. Docs say that gem5 has NIC devices and two simulated instances can
> simulate Ethernet connection. Would it be possible to set up a simulation
> of web browser? I read that there is no internet connection inside gem5,
> that's why I am asking. What I had in mind was something like this:
> Device A runs full system simulation and is connected to device B, which
> acts as a web server. In terminal of device A a command something like:
> "adb shell am start -n
> com.android.chrome/com.google.android.apps.chrome.Main" (this starts google
> chrome through adb shell on my android phone) is run, to start google
> chrome. Then device B sends the website data to device A and device A opens
> chrome and loads the website. If that's not possible, is there any other
> way to simulate internet connection in gem5?
>
> 2. Coming back to full system simulation. Would I be able to introduce
> extra caches and experiment with rerouting data flow etc... if I simulate a
> SoC like Snapdragon?
>
> Pavel.
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Running parallel version of a CPU benchmark on multiple cores

[Gabe Black via gem5-users]

That's essentially right, although gem5 does have some plumbing to run
multiple event queues within the same simulation which can coordinate with
each other within a small window (quantum) of time. gem5 has support for
fibers/threads/coroutines, but these are not typically used to model
events. Events are processed inline when they happen using a simple
function call.

Gabe

On Thu, Apr 15, 2021 at 2:46 AM gabriel.busnot--- via gem5-users <
gem5-users@gem5.org> wrote:

> Hi John,
>
> Short answer : no, you can only run several simulations in parallel, but
> not a single simulation using one thread per CPU.
>
> Gem5 relies on Discrete Event Simulation (DES) to simulate the concurrent
> behavior of HW.
> DES is intrinsically sequential in its execution as it relies on
> coroutines (also called user user threads, greed threads, fibers, etc.).
> Parallelizing such application is a very hard task that often requires a
> lot of subtle code transformations to efficiently protect shared resources.
> If done correctly, then parallel DES does not have all the good properties
> of classic DES, especially determinism... Unless you add extra care to
> preserve it, which is hard, too. Trust me ;).
>
> This question has been discussed back in the days but seems stalled now:
> http://www.m5sim.org/Parallel_M5
>
> Cheers,
> Gabriel
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Simulating modern Smartphone System on Chip with Android 11 image

[Gabe Black via gem5-users]

Hi Pavel.

1. Yes, this is possible, I've done that as part of my work. The (a?) hard
part is getting the software set up correctly, but gem5 as it is should be
able to run it. Be warned that android is a big, complex system and can
take a long time to boot and run on gem5, which can be particularly
problematic when you're trying to get things working for the first time.
2. If by heterogeneous you mean with differently spec-ed ARM cores, yes.
gem5 does not simulate particular ARM or x86 cores perse, it simulates the
ARM and x86 ISAs within CPU models, some of which can be configured to be
like particular CPUs but which will not model them exactly. gem5 cannot
(currently) simulate more than one ISA at a time, and so you couldn't have,
for instance, an ARM core with a RISCV coprocessor in an accelerator
device, or an x86 server talking to an ARM mobile device, all in the same
simulation. Once we support having multiple ISAs in the same simulation,
you would be able to simulate those things.

Gabe

On Thu, Apr 15, 2021 at 1:53 PM Pavel Golikov via gem5-users <
gem5-users@gem5.org> wrote:

> My apologies, I forgot to mention that I am looking to perform full system
> simulation while collecting the hardware counters.
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Speeding up the Edit, Compile, Debug cycle

[Gabe Black via gem5-users]

Hi Gabriel. One big reason not to use shared libraries is performance,
although that doesn't mean the idea is without merit. In the long term, I
would like to give gem5 a kconfig like configuration mechanism, where you
could specify things to be built into gem5 itself, things to be excluded,
and things that would be loadable at run time. Things get a bit complicated
with gem5's python integration and SimObjects, but I'm hoping it will be
doable. There are a lot of steps between here and there and some things
need to be prioritized over others, but this is something I'm hoping to
improve in the long run.

Gabe

On Thu, Apr 15, 2021 at 4:05 AM gabriel.busnot--- via gem5-users <
gem5-users@gem5.org> wrote:

> Hi all,
>
> I would like to know what is your favorite way to run the ECD cycle with
> this gem5.debug beast of a binary.
>
> I am currently developing a pretty large Ruby protocol and use 2 build
> configurations: debug and fasta for "fast with asserts". I've defined the
> fasta build target myself and detail it bellow.
> I've carefully seasoned my code with asserts in order to catch as many
> bugs as possible without relying on gdb. I catch about 2/3 of the bugs that
> way I would say.
> The rest of the time, which is often more than 20 times a day, I must fall
> back to the debug target to have gem5 debug flags enabled and usable gdb
> information.
>
> So, what is the fasta target? It is the regular fast target...
> - with asserts (because segfault-based debugging sucks)
> - without LTO and stripping (for much faster link time)
> - without -Werror (because I don't want "unused variable errors" while
> developing).
> How does it perform? 20s compile time and close-ish to "fast" binary
> speeds.
>
> Now, why not use only the debug target? 1'40" compile time, 10"
> uncompressible platform elaboration time, 20" to load symbols in gdb: 2'+
> uncompressible time to compile and run gem5 under GDB.
> Why not use the opt target instead? ~3min compile time due to LTO and
> unusable gdb due to optimization, anyway.
>
> This brings me to the question: why doesn't gem5 make use of shared
> libraries, at least to speedup build time in debug mode?
> Ideally, one could even specify which modules need debug info and which
> don't. In my case, I would only include ruby-related debug info for
> instance.
> "Compile+Run in GDB" time could shrink down to less than 5s total that way.
>
> What do you think of it?
> I don't know much about SCons but with a few pointers to start, I could
> take a look at it and eventually submit a patch if I am happy with the
> results.
>
> Cheers,
> Gabriel Busnot
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Maybe pipeview script has some version compatibility issues？

[Gabe Black via gem5-users]

Maybe a python 2 vs 3 issue? I haven't used this script myself.

Gabe

On Mon, Apr 12, 2021 at 2:02 AM weiwei Zhao via gem5-users <
gem5-users@gem5.org> wrote:

> cmd：./util/o3-pipeview.py -c 1000 -o DP1d_corr/pipeview.out --color
> DP1d_corr/trace.out
>
> Processing trace...  Traceback (most recent call last):
>   File "./util/o3-pipeview.py", line 379, in 
> main()
>   File "./util/o3-pipeview.py", line 371, in main
> *(tick_range + inst_range))
>   File "./util/o3-pipeview.py", line 142, in process_trace
> queue_inst(outfile, curr_inst, cycle_time, width, color, timestamps,
> store_completions)
>   File "./util/o3-pipeview.py", line 162, in queue_inst
> print_insts(outfile, cycle_time, width, color, timestamps,
> store_completions, insts['min_threshold'])
>   File "./util/o3-pipeview.py", line 167, in print_insts
> insts['queue'].sort(compare_by_sn)
> TypeError: must use keyword argument for key function
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Long linkage

[Gabe Black via gem5-users]

The opt build now uses link time optimization (LTO) and does not use
partial linking. On slower machines and/or machines with fewer cores (and
maybe less memory?) this seems to really slow things down, where on
machines with more cores, LTO linking happens to be parallel where normal
linking doesn't seem to be, and this and not having partial linking is
actually a good bit faster and significantly reduces the footprint of the
build directory.

If you see long link times and you didn't before, you can try disabling LTO
(--no-lto). That should bring the link times back down to be more in line
with older versions.

Gabe

On Sun, Apr 11, 2021 at 9:46 PM Majid Jalili via gem5-users <
gem5-users@gem5.org> wrote:

> Hi,
> Why does the recent version of gem5 takes very long on the last step when
> creating the gem5.opt? My 2-month old repo is just fine, but the new
> version takes a very long to finish link.
> I tried on three different machines with the different OS but no
> improvement.
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Kernel panic when using ubuntu-18.04-arm64-docker.img

[Gabe Black via gem5-users]

Hi, it looks like your script (/tmp/my_script) is exiting. I think the init
process isn't supposed to exit.

Gabe

On Sun, Apr 11, 2021 at 4:13 AM kong han via gem5-users 
wrote:

> Hi all,
>
> Now I using the Latest linux kernel and disk images to run fs mode with
> KVM CPU   (
> https://www.gem5.org/documentation/general_docs/fullsystem/guest_binaries),
> and I mount the image and modify the mnt-dir/init.gem5 to readfile from the
> –script, then I run this script, but after that, I have the Kernal panic,
> and can’t run next step, how could I solve this problem?
>
> The error is :
>
> + mount -t proc - /proc
>
> + mount -t sysfs - /sys
>
> + mount -t debugfs - /sys/kernel/debug/
>
> + [ -e /dev/sdb1 ]
>
> + [ -e /dev/sdb ]
>
> + [ -e /dev/vdb1 ]
>
> + [ -e /dev/vdb ]
>
> + [ -e /dev/vda1 ]
>
> + [ -e /dev/vda ]
>
> + f=/tmp/script
>
> + /sbin/m5 --addr 0x1001 readfile
>
> + chmod 777 /tmp/my_script
>
> + exec /tmp/my_script
>
> 
>
> [4.428566] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x
>
> [4.428566]
>
> [4.430528] CPU: 0 PID: 1 Comm: sh Not tainted 4.18.0+ #1
>
> [4.431673] Hardware name: V2P-CA15 (DT)
>
> [4.432596] Call trace:
>
> [4.433314]  dump_backtrace+0x0/0x1c0
>
> [4.434125]  show_stack+0x14/0x20
>
> [4.435046]  dump_stack+0x8c/0xac
>
> [4.435837]  panic+0x130/0x288
>
> [4.436563]  complete_and_exit+0x0/0x20
>
> [4.437473]  do_group_exit+0x38/0xa0
>
> [4.438310]  __wake_up_parent+0x0/0x28
>
> [4.439181]  el0_svc_naked+0x30/0x34
>
> [4.440043] Kernel Offset: disabled
>
> [4.440911] CPU features: 0x22800210
>
> [4.441720] Memory Limit: 512 MB
>
> [4.442503] ---[ end Kernel panic - not syncing: Attempted to kill
> init! exitcode=0x
>
> [4.442503]  ]---
>
>
>
> The init.gem5 I modify is :
>
> #!/bin/sh
>
> set -ex
>
> mount -t proc - /proc
>
> mount -t sysfs - /sys
>
> mount -t debugfs - /sys/kernel/debug/
>
> for DEV in /dev/sdb1 /dev/sdb /dev/vdb1 /dev/vdb /dev/vda1 /dev/vda; do
>
>   if [ -e "${DEV}" ]; then
>
> mount "${DEV}" /data
>
> break
>
>   fi
>
> done
>
> f=/tmp/script
>
> /sbin/m5 --addr 0x1001 readfile > /tmp/my_script
>
> chmod 777 /tmp/my_script
>
> exec /tmp/my_script
>
> exec /sbin/getty -a root -L ttyAMA0 vt102
>
>
>
> And my cmd is :
>
> ./build/ARM/gem5.opt \
>
> -d ./m5out/   \
>
> ./configs/example/fs.py  \
>
> --disk=../image/ubuntu-18.04-arm64-docker.img  \
>
> --kernel=../aarch-system-201901106/binaries/vmlinux.arm64  \
>
> --cpu-type=ArmV8KvmCPU  \
>
> --bootloader=../kernel/aarch-system-201901106/binaries/boot.arm64  \
>
> --script=../gem5/temp-rcs/t1.rcS  \
>
>
>
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Can't define my own create() function

[Gabe Black via gem5-users]

Hi. The automatically generated create() method will only exist if your
SimObject can be constructed with a constant reference to the parameter
type. Or in other words, if it has a constructor of the form
TraceManager(const TraceManagerParams ). You can disable that by
just adding a dummy parameter like an int which you don't have to use for
anything. This is somewhat like how c++ operator overloading disambiguates
the i++ and the ++i cases.

Gabe

On Fri, Apr 9, 2021 at 7:11 PM weiwei Zhao via gem5-users <
gem5-users@gem5.org> wrote:

> The compile error like this:
>
> build/ARM/params/TraceManager.do: In function
> `TraceManagerParams::create() const':
> /data1/zhaoweiwei/gem5/base_v21.0.0.0/build/ARM/params/TraceManager.cc:53:
> multiple definition of `TraceManagerParams::create() const'
> build/ARM/sim/tracemanager.do:/data1/zhaoweiwei/gem5/base_v21.0.0.0/build/ARM/sim/tracemanager.cc:156:
> first defined here
> collect2: error: ld returned 1 exit status
> scons: *** [build/ARM/gem5.debug] Error 1
> scons: building terminated because of errors.
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: IGbE_e1000 card not connected

[Gabe Black via gem5-users]

Hi Nikos, how old is your gem5 checkout? The change below fixed some
aspects of how PCI devices are managed, including one which could cause
failures like you're seeing.

commit 9be18aa66ddb8db4da043279819d45bc72b7b086
Author: Gabe Black 
Date:   Fri Oct 2 03:00:04 2020 -0700

On Wed, Mar 31, 2021 at 1:04 PM Νικόλαος Ταμπουρατζής via gem5-users <
gem5-users@gem5.org> wrote:

> Dear gem5 community,
>
> I would like to use the IGbE_e1000 card in the latest gem5 version in
> ARM FS mode. As I can see the card is connected only in VExpress_EMM
> and VExpress_EMM64. However, I cannot boot correctly the latest gem5
> version either in VExpress_EMM or VExpress_EMM64 using the
> 20180409.tar.xz kernels and images from the following link:
> https://www.gem5.org/documentation/general_docs/fullsystem/guest_binaries.
>
> So I achieve to boot the gem5 using the VExpress_GEM5_V1 machine type
> (specifically through this configuration: $GEM5/build/ARM/gem5.opt -d
> $GEM5/node0 $GEM5/configs/example/fs.py
> --kernel=vmlinux.vexpress_gem5_v1_64
> --disk-image=linaro-minimal-aarch64.img
> --machine-type=VExpress_GEM5_V1 --dtb=armv7_gem5_v1_1cpu.dtb).
>
> However, the IGbE_e1000 card is not included in the
> VExpress_GEM5_V1... So I tried to connect it in VExpress_GEM5_Base
> (which is used from VExpress_GEM5_V1). Specifically,
>
> 1) I add the following (below pci_host = GenericArmPciHost)
>
> # Attach any PCI devices that are supported
> def attachPciDevices(self):
> self.ethernet = IGbE_e1000(pci_bus=0, pci_dev=0, pci_func=0,
> InterruptLine=1, InterruptPin=1)
>
> 2) I add the self.ethernet in def _off_chip_devices(self).
>
> Unfortunatelly, I get the following error after 2 minutes of
> simulation (during this message: [0.135098] e1000 :00:00.0:
> enabling device ( -> 0002)):
>
> fatal: system.iobus has two ports responding within range
> [0x8000:0x8002]:
>  system.realview.ethernet.pio
>  system.iobridge.cpu_side_port
>
> Looking in previous gem5 versions, in the GenericArmPciHost there is
> not the "pci_mem_base=0x4000". So, I remove this and I am able to
> boot Linux and see the eth0 but I do not know if is correct to remove
> the pci_mem_base.
>
> I would appreciate it if anyone would like to explain me please! :)
>
> Best regards,
> Nikos
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: m5 utility for ARM64

[Gabe Black via gem5-users]

Hi Jeageun, you should take a look at util/m5/README.md for an explanation
of how the m5 utility works and how it should be used in different
environments. It looks like it's trying to use the instruction based
mechanism to call into gem5, and that won't work in KVM. In KVM, you have
to use the magic address based mechanism. That's all spelled out in that
README. There are also instructions there for building the utility if your
version is too old and doesn't have the updates reflected in that document.
The older m5 utility would have to be recompiled to use a different
mechanism, where with the new version you can select what mechanism to use
from the command line.

Gabe

On Wed, Mar 31, 2021 at 7:11 PM JeaGeun Jung via gem5-users <
gem5-users@gem5.org> wrote:

> Hi all,
>
> I'm trying to use m5 exit on the ARM image using
> http://dist.gem5.org/dist/current/arm/aarch-system-201901106.tar.bz2.
>
> I boot this image using the following instruction
>
> ./build/ARM/gem5.opt configs/example/fs.py --kernel
> /data/gem5_image/vmlinux --disk-image
> /data/gem5_image/ubuntu-18.04-arm64-docker.img --mem-size=16GB
> --cpu-type=ArmV8KvmCPU -n4 --cpu-clock=3.2GHz
>
> In short, kvm cpu boot for ARM full system.
>
> In the gem5 image, I tried m5 exit, and it prints an error message.
> I use most updated gem5 develop branch.
>
> root@aarch64-gem5:~# m5 exit
>
> [  125.384290] m5[737]: undefined instruction: pc=00409290
>
> [  125.386245] Code: ff070110 d65f03c0 ff090110 d65f03c0 (ff210110)
>
> Illegal instruction
>
> I tried to compile m5 binary in gem5 image, but it doesn't work. How could
> I fix this bug?
>
> Thanks,
> Jeageun
>
> ᐧ
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Gem5 hang with multi core

[Gabe Black via gem5-users]

Hi Xijing. I don't think anyone has gotten x86 and caches and
locking/atomic instructions to fully work, so it's just a known bug in gem5
at the moment. If you want to simulate that sort of system, I would suggest
using ARM if possible. We'd love to fix this at some point, but there are a
lot of things to work on and only so many people to work on them :-/.

Gabe

On Fri, Mar 26, 2021 at 11:13 AM Xijing Han via gem5-users <
gem5-users@gem5.org> wrote:

> Thanks for the respond.
>
> This is my command line:
>
> ../gem5_security/gem5_noBWPQ/build/X86/gem5.opt
> --outdir=/home/xhan24/gem5_out_16G_new/gem5_out_redis_orig/latency_after_WPQ_noBWPQ
> ../try_config/configs/example/fs.py
> --checkpoint-dir=/home/xhan24/gem5_chk/multi_core/redis
> --disk-image=/home/xhan24/gem5_disk2/e_ext.img
> --kernel=/home/xhan24/gem5_kernel/KERNEL414 --mem-size=16GB
> --cpu-type=DerivO3CPU -n 4 --cpu-clock=1GHz --mem-type=DDR4_2400_16x4
> --caches --l2cache --l3cache --cacheline_size=64 -r 1 --script redis_run.scr
>
>
> So when I start the multi core mode, it works fine for a while, then it
> got stuck in some kernel funcion: native_queued_spin_lock_slowpath, gem5
> is still working, but it always execute the instructions in this function.
>
> On Fri, Mar 26, 2021 at 1:52 PM Giacomo Travaglini <
> giacomo.travagl...@arm.com> wrote:
>
>> Hi Xijing,
>>
>> Could you please provide us with more information (e.g. the command line)
>>
>> Kind Regards,
>> Giacomo
>> --
>> *From:* Xijing Han via gem5-users 
>> *Sent:* 26 March 2021 17:10
>> *To:* gem5-users@gem5.org 
>> *Cc:* Xijing Han 
>> *Subject:* [gem5-users] Gem5 hang with multi core
>>
>> Hi,
>>
>> I have a hang issue using gem5 with multi core mode.
>> I am using FS mode and a classic memory system.  It works fine with
>> single core mode. But when I try to set n = 4, it starts running for a
>> while and then get into a deadlock in kernel. Can someone help me out?
>> Thanks.
>>
>> Best,
>> Xijing
>> 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-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: gem5 crash when mount by vio-9p protocol in KVM mode with more than 1 core

[Gabe Black via gem5-users]

Please take the version that works for you and create a review:

http://www.gem5.org/contributing

It's much easier to look at changes in the code review interface, and we
can add reviewers who are most familiar with this code.

Gabe

On Tue, Mar 16, 2021 at 2:59 AM Liyichao  wrote:

> Adding “EventQueue::ScopedMigration migrate(eventQueue());”  in kick()
> function in class VirtIODeviceBase does work now, thanks.
>
>
>
> class VirtIODeviceBase : public SimObject
>
> {
>
>   public:
>
> typedef uint16_t QueueID;
>
> typedef uint32_t FeatureBits;
>
> /** This is a VirtQueue address as exposed through the low-level
>
>  * interface.\ The address needs to be multiplied by the page size
>
>  * (seems to be hardcoded to 4096 in the spec) to get the real
>
>  * physical address.
>
>  */
>
> typedef uint16_t VirtAddress;
>
> /** Device Type (sometimes known as subsystem ID) */
>
> typedef uint16_t DeviceId;
>
>
>
> BitUnion8(DeviceStatus)
>
> Bitfield<7> failed;
>
> Bitfield<2> driver_ok;
>
> Bitfield<1> driver;
>
> Bitfield<0> acknowledge;
>
> EndBitUnion(DeviceStatus)
>
>
>
> typedef VirtIODeviceBaseParams Params;
>
> VirtIODeviceBase(Params *params, DeviceId id, size_t config_size,
>
>  FeatureBits features);
>
> virtual ~VirtIODeviceBase();
>
>
>
>   public:
>
> /** @{
>
>  * @name SimObject Interfaces
>
>  */
>
> void serialize(CheckpointOut ) const override;
>
> void unserialize(CheckpointIn ) override;
>
> /** @} */
>
>
>
>   protected:
>
> /** @{
>
>  * @name Device Model Interfaces
>
>  */
>
>
>
> /**
>
>  * Inform the guest of available buffers.
>
>  *
>
>  * When a device model has finished processing incoming buffers
>
>  * (after onNotify has been called), it typically needs to inform
>
>  * the guest that there are new pending outgoing buffers. The
>
>  * method used to inform the guest is transport dependent, but is
>
>  * typically through an interrupt. Device models call this method
>
>  * to tell the transport interface to notify the guest.
>
>  */
>
> void kick() {
>
> assert(transKick);
>
>EventQueue::ScopedMigration migrate(eventQueue());
>
> transKick->process();
>
> };
>
>
>
>
>
>
>
> *发件人:* Liyichao
> *发送时间:* 2021年3月16日 14:06
> *收件人:* 'Gabe Black' 
> *抄送:* gem5 users mailing list 
> *主题:* 答复: [gem5-users] gem5 crash when mount by vio-9p protocol in KVM
> mode with more than 1 core
>
>
>
> I look into the code, and find that the kick() function in
> VirtIO9PBase::sendRMsg function in fs9p.cc is defined in class
> VirtIODeviceBase:
>
>
>
> class VirtIODeviceBase : public SimObject
>
> {
>
>   public:
>
> typedef uint16_t QueueID;
>
> typedef uint32_t FeatureBits;
>
> /** This is a VirtQueue address as exposed through the low-level
>
>  * interface.\ The address needs to be multiplied by the page size
>
>  * (seems to be hardcoded to 4096 in the spec) to get the real
>
>  * physical address.
>
>  */
>
> typedef uint16_t VirtAddress;
>
> /** Device Type (sometimes known as subsystem ID) */
>
> typedef uint16_t DeviceId;
>
>
>
> BitUnion8(DeviceStatus)
>
> Bitfield<7> failed;
>
> Bitfield<2> driver_ok;
>
> Bitfield<1> driver;
>
> Bitfield<0> acknowledge;
>
> EndBitUnion(DeviceStatus)
>
>
>
> typedef VirtIODeviceBaseParams Params;
>
> VirtIODeviceBase(Params *params, DeviceId id, size_t config_size,
>
>  FeatureBits features);
>
> virtual ~VirtIODeviceBase();
>
>
>
>   public:
>
> /** @{
>
>  * @name SimObject Interfaces
>
>  */
>
> void serialize(CheckpointOut ) const override;
>
> void unserialize(CheckpointIn ) override;
>
> /** @} */
>
>
>
>   protected:
>
> /** @{
>
>  * @name Device Model Interfaces
>
>  */
>
>
>
> /**
>
>  * Inform the guest of available buffers.
>
>  *
>
>  * When a device model has finished processing incoming buffers
>
>  * (after onNotify has been called), it typically needs to inform
>
>  * the guest that there are new pending outgoing buffers. The
>
>  * method used to inform the guest is transport dependent, but is
>
>  * typically through an interrupt. Device models call this method
>
>  * to tell the transport interface to notify the guest.
>
>  */
>
> void kick() {
>
> assert(transKick);
>
>EventQueue::ScopedMigration migrate(eventQueue());
>
> transKick->process();
>
> };
>
>
>
> But not define in MmioVirtIO and PciVirtIO as you mentioned.
>
>
>
> So should I declared in the kick() definition?
>
>
>
> void kick() {
>
>EventQueue::ScopedMigration migrate(eventQueue());
>
> assert(transKick);
>
> transKick->process();
>
> };
>
>
>
>
>
> *发件人:* Gabe Black 

[gem5-users] Re: Custom M5Ops

[Gabe Black via gem5-users]

Hi Sam, there are a few ways you can do that.

1. You could set up a PC based event if you know what PC your behavior will
always be triggered from (see examples like skipping udelay for some
versions of the linux kernel).
2. You could create a new gem5 op by picking an unused number and a wrapper
stub in the header files I think you've found. Then in gem5 itself, you'd
add an implementation in src/sim/pseudo_inst.(hh|cc). The fairly trivial
"sum" gem5 op is probably a good example.
3. You could use the existing m5_workload gem5 op which basically just
pokes the workload object and tells it something interesting is happening.
The workload can then inspect state and look at registers, the PC, etc to
figure out what you want to happen. You can think of this sort of like a
system call but into the simulator. You'd need to create your own workload
class (which could be/would likely be based on an existing one) to
implement this back end logic. This is how I intend the system calls in SE
mode to be implemented one of these days.

Gabe

On Tue, Mar 16, 2021 at 4:55 AM Samuel Thomas via gem5-users <
gem5-users@gem5.org> wrote:

> Hello,
>
> I’m working on a project where I want to trigger a hardware procedure from
> software. I can see in the gem5/include/gem5/asm/generic/m5ops.h file,
> there is a certain amount of address space allocated for user customizable
> operations like this. Is there documentation as to how to use this address
> space and make a custom operation?
>
> Thank you for your help!
>
> Best,
> Sam
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: gem5 crash when mount by vio-9p protocol in KVM mode with more than 1 core

[Gabe Black via gem5-users]

Basically you want to make sure you've moved to the right event queue by
the time any code you call tries to schedule an event. The VirtIO devices
themselves don't seem to, but the code they're calling (interacting with
other devices, sending transactions to the memory system) could be. If it
doesn't work in kick(), then there may be a call earlier which is causing
problems. This is only necessary on code paths that are called
asynchronously, like when you get poked from the other process running the
diod daemon for instance. Basically you want to always and only create a
ScopedMigration when called asynchronously and when something that happens
during that asynchronous call might directly or indirectly cause an event
to be scheduled on the event queue.

I think Andreas has a lot of familiarity with this area, so hopefully he
can chime in and let us know if we're on the right track.

Gabe

On Mon, Mar 15, 2021 at 10:39 PM Liyichao  wrote:

> Or you mean the ScopedMigration needs to be declared in
> VitIO9PBase::sendMsg in fs9p.cc before kick() be called?
>
>
>
>
>
> void
>
> VirtIO9PBase::sendRMsg(const P9MsgHeader , const uint8_t *data,
> size_t size)
>
> {
>
> DPRINTF(VIO9P, "Sending RMsg\n");
>
> EventQueue::ScopedMigration migrate(eventQueue());
>
> dumpMsg(header, data, size);
>
> DPRINTF(VIO9P, "\tPending transactions: %i\n", pendingTransactions.
> size());
>
> assert(header.len >= sizeof(header));
>
>
>
> VirtDescriptor *main_desc(pendingTransactions[header.tag]);
>
> pendingTransactions.erase(header.tag);
>
>
>
> // Find the first output descriptor
>
> VirtDescriptor *out_desc(main_desc);
>
> while (out_desc && !out_desc->isOutgoing())
>
> out_desc = out_desc->next();
>
> if (!out_desc)
>
> panic("sendRMsg: Framing error, no output descriptor.\n");
>
>
>
> P9MsgHeader header_out(htop9(header));
>
> header_out.len = htop9(sizeof(P9MsgHeader) + size);
>
>
>
> out_desc->chainWrite(0, (uint8_t *)_out, sizeof(header_out));
>
> out_desc->chainWrite(sizeof(header_out), data, size);
>
>
>
> queue.produceDescriptor(main_desc, sizeof(P9MsgHeader) + size);
>
> kick();
>
> }
>
>
>
>
> --
>
> 李翼超（Charlie）
>
>
>
> 华为技术有限公司 Huawei Technologies Co., Ltd.
>
> [image: Company_logo]
>
> 部门：计算系统与组件开发部 [云与计算BG]
>
> 手 机：15858232899
> 电子邮件：liyic...@huawei.com
>
> 地址：中国(China)-杭州(Hangzhou)-滨江区江淑路360号华为杭州研发中心Z4# [3-A06]
> --
>
>  本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
>
>
>
> *发件人:* Liyichao
> *发送时间:* 2021年3月16日 13:30
> *收件人:* 'Gabe Black' 
> *抄送:* gem5 users mailing list 
> *主题:* 答复: [gem5-users] gem5 crash when mount by vio-9p protocol in KVM
> mode with more than 1 core
>
>
>
> Hi Gabe:
>
>  You mean that the code to be modified just like this?
>
>
>
>  void
>
> PciVirtIO::kick()
>
> {
>
> DPRINTF(VIOIface, "kick(): Sending interrupt...\n");
>
> EventQueue::ScopedMigration migrate(eventQueue());
>
> interruptDeliveryPending = true;
>
> intrPost();
>
> }
>
>
>
>
>
> void
>
> MmioVirtIO::kick()
>
> {
>
> DPRINTF(VIOIface, "kick(): Sending interrupt...\n");
>
> EventQueue::ScopedMigration migrate(eventQueue());
>
> setInterrupts(interruptStatus | INT_USED_RING);
>
> }
>
>
>
> *发件人:* Gabe Black [mailto:gabe.bl...@gmail.com ]
> *发送时间:* 2021年3月16日 8:44
> *收件人:* Liyichao 
> *抄送:* gem5 users mailing list 
> *主题:* Re: [gem5-users] gem5 crash when mount by vio-9p protocol in KVM
> mode with more than 1 core
>
>
>
> I think what you want to do is in the kick() functions in MmioVirtIO and
> PciVirtIO, you want to declare a ScopedMigration at the start of the
> function, and pass its constructor the result of the eventQueue() method.
> The SimObject class inherits from EventManager and knows what event queue
> it's supposed to use, and that's what eventQueue returns. When you declare
> a ScopedMigration, it will handle the locking correctly and move over to
> that queue, and when it goes out of scope (at the end of the function) it
> will put everything back.
>
>
>
> Please give that a try, and if it works for you (I don't have a way to
> test it myself) put up a review so we can get a fix checked in.
>
>
>
> Gabe
>
>
>
> On Mon, Mar 15, 2021 at 5:28 PM Liyichao  wrote:
>
> Thanks for your explaination.In O3 type with multi-core 9P is ok.
>
>
> *发件人： *Gabe Black
>
> *收件人： *gem5 

[gem5-users] Re: gem5 crash when mount by vio-9p protocol in KVM mode with more than 1 core

[Gabe Black via gem5-users]

Yes exactly, did that help?

Gabe

On Mon, Mar 15, 2021 at 10:29 PM Liyichao  wrote:

> Hi Gabe:
>
>  You mean that the code to be modified just like this?
>
>
>
>  void
>
> PciVirtIO::kick()
>
> {
>
> DPRINTF(VIOIface, "kick(): Sending interrupt...\n");
>
> EventQueue::ScopedMigration migrate(eventQueue());
>
> interruptDeliveryPending = true;
>
> intrPost();
>
> }
>
>
>
>
>
> void
>
> MmioVirtIO::kick()
>
> {
>
> DPRINTF(VIOIface, "kick(): Sending interrupt...\n");
>
> EventQueue::ScopedMigration migrate(eventQueue());
>
> setInterrupts(interruptStatus | INT_USED_RING);
>
> }
>
>
>
> *发件人:* Gabe Black [mailto:gabe.bl...@gmail.com]
> *发送时间:* 2021年3月16日 8:44
> *收件人:* Liyichao 
> *抄送:* gem5 users mailing list 
> *主题:* Re: [gem5-users] gem5 crash when mount by vio-9p protocol in KVM
> mode with more than 1 core
>
>
>
> I think what you want to do is in the kick() functions in MmioVirtIO and
> PciVirtIO, you want to declare a ScopedMigration at the start of the
> function, and pass its constructor the result of the eventQueue() method.
> The SimObject class inherits from EventManager and knows what event queue
> it's supposed to use, and that's what eventQueue returns. When you declare
> a ScopedMigration, it will handle the locking correctly and move over to
> that queue, and when it goes out of scope (at the end of the function) it
> will put everything back.
>
>
>
> Please give that a try, and if it works for you (I don't have a way to
> test it myself) put up a review so we can get a fix checked in.
>
>
>
> Gabe
>
>
>
> On Mon, Mar 15, 2021 at 5:28 PM Liyichao  wrote:
>
> Thanks for your explaination.In O3 type with multi-core 9P is ok.
>
>
>
> *发件人： *Gabe Black
>
> *收件人： *gem5 users mailing list
>
> *抄送： *Liyichao
>
> *主题： *Re: [gem5-users] gem5 crash when mount by vio-9p protocol in KVM
> mode with more than 1 core
>
> *时间： *2021-03-16 07:24:15
>
>
>
> I haven't looked at the code yet, but this is probably because the v9
> implementation is getting asynchronous input which might be received by one
> thread, which then tries to schedule an event on an event queue associated
> with another queue. Most of the time this is not an issue since gem5 is
> usually single threaded, but when using multiple cores with KVM, each core
> runs in its own thread. There's a way to add events to the event queue in
> another thread safely (ScopedMigration) which I'm assuming the v9 code is
> not using.
>
>
>
> Gabe
>
>
>
> On Sun, Mar 7, 2021 at 8:38 PM Liyichao via gem5-users <
> gem5-users@gem5.org> wrote:
>
> Hi All:
>
>
>
>  When I use –vio-9p with fs_bigLITTLE.py, 1 core the mount cmd was
> ok, but more than 1 core, mount cmd will cause GEM5 crash
>
>
>
>  1core:
>
>  Gem5 cmd: ./build/ARM/gem5.opt --debug-flags=Exec  -d
> /home/l00515693/m5out configs/example/arm/fs_bigLITTLE.py --cpu-type=kvm
> --kernel=vmlinux --machine-type=VExpress_GEM5_V1
> --disk=expanded-aarch64-ubuntu-trusty-headless.img --caches
> --big-cpu-clock=2.6GHz --little-cpu-clock=2.6GHz --big-cpus=1
> --little-cpus=0 --mem-size=4GB --param 'system.realview.gic.gem5_extensions
> = True' --bootscript=./test.rcS --vio-9p
>
>  Mount cmd in guest OS: mount -t 9p -o
> trans=virtio,version=9p2000.L,aname=/home/l00515693/m5out/9p/share gem5
> /mnt/9p
>
> root@charlie:~# df -h
>
> Filesystem  Size  Used Avail Use% Mounted on
>
> /dev/root   9.9G  3.3G  6.2G  35% /
>
> devtmpfs2.0G  4.0K  2.0G   1% /dev
>
> none4.0K 0  4.0K   0% /sys/fs/cgroup
>
> none396M   52K  396M   1% /run
>
> none5.0M 0  5.0M   0% /run/lock
>
> none2.0G 0  2.0G   0% /run/shm
>
> none100M 0  100M   0% /run/user
>
> gem52.9T  1.8T  989G  65% /mnt/9p
>
>
>
>
>
>
>
>  2core:
>
>  Gem5 cmd: ./build/ARM/gem5.opt --debug-flags=Exec  -d
> /home/l00515693/m5out configs/example/arm/fs_bigLITTLE.py --cpu-type=kvm
> --kernel=vmlinux --machine-type=VExpress_GEM5_V1
> --disk=expanded-aarch64-ubuntu-trusty-headless.img --caches
> --big-cpu-clock=2.6GHz --little-cpu-clock=2.6GHz --big-cpus=2
> --little-cpus=0 --mem-size=4GB --param 'system.realview.gic.gem5_extensions
> = True' --bootscript=./test.rcS --vio-9p
>
>
>
>  Mount cmd in guest OS: mount -t 9p -o
> trans=virtio,version=9p2000.L,aname=/home/l00515693/m5out/9p/share gem5
> /mnt/9p
>
>
>
> GEM5 crash info:
>
> gem5.opt: build/ARM/sim/eventq_impl.hh:40: void
> EventQueue::schedule(Event*, Tick, bool): Assertion `when >= getCurTick()'
> failed.
>
> Program aborted at tick 476281849910020
>
> --- BEGIN LIBC BACKTRACE ---
>
> ./build/ARM/gem5.opt(_Z15print_backtracev+0x40)[0xdd24e418]
>
> ./build/ARM/gem5.opt(_Z12abortHandleri+0x5c)[0xdd25efa4]
>
> linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0x9fea5688]
>
> /lib/aarch64-linux-gnu/libc.so.6(raise+0xb0)[0x9f6634f8]
>
> --- END LIBC BACKTRACE ---
>
> Aborted (core dumped)
>

[gem5-users] Re: gem5 crash when mount by vio-9p protocol in KVM mode with more than 1 core

[Gabe Black via gem5-users]

I think what you want to do is in the kick() functions in MmioVirtIO and
PciVirtIO, you want to declare a ScopedMigration at the start of the
function, and pass its constructor the result of the eventQueue() method.
The SimObject class inherits from EventManager and knows what event queue
it's supposed to use, and that's what eventQueue returns. When you declare
a ScopedMigration, it will handle the locking correctly and move over to
that queue, and when it goes out of scope (at the end of the function) it
will put everything back.

Please give that a try, and if it works for you (I don't have a way to test
it myself) put up a review so we can get a fix checked in.

Gabe

On Mon, Mar 15, 2021 at 5:28 PM Liyichao  wrote:

> Thanks for your explaination.In O3 type with multi-core 9P is ok.
>
>
>
>
> --
>
> 李翼超 charlie
> Mobile：+86-15858232899
> Email：liyic...@huawei.com
>
>
> *发件人： *Gabe Black
> *收件人： *gem5 users mailing list
> *抄送： *Liyichao
> *主题： *Re: [gem5-users] gem5 crash when mount by vio-9p protocol in KVM
> mode with more than 1 core
> *时间： *2021-03-16 07:24:15
>
> I haven't looked at the code yet, but this is probably because the v9
> implementation is getting asynchronous input which might be received by one
> thread, which then tries to schedule an event on an event queue associated
> with another queue. Most of the time this is not an issue since gem5 is
> usually single threaded, but when using multiple cores with KVM, each core
> runs in its own thread. There's a way to add events to the event queue in
> another thread safely (ScopedMigration) which I'm assuming the v9 code is
> not using.
>
> Gabe
>
> On Sun, Mar 7, 2021 at 8:38 PM Liyichao via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi All:
>>
>>
>>
>>  When I use –vio-9p with fs_bigLITTLE.py, 1 core the mount cmd
>> was ok, but more than 1 core, mount cmd will cause GEM5 crash
>>
>>
>>
>>  1core:
>>
>>  Gem5 cmd: ./build/ARM/gem5.opt --debug-flags=Exec  -d
>> /home/l00515693/m5out configs/example/arm/fs_bigLITTLE.py --cpu-type=kvm
>> --kernel=vmlinux --machine-type=VExpress_GEM5_V1
>> --disk=expanded-aarch64-ubuntu-trusty-headless.img --caches
>> --big-cpu-clock=2.6GHz --little-cpu-clock=2.6GHz --big-cpus=1
>> --little-cpus=0 --mem-size=4GB --param 'system.realview.gic.gem5_extensions
>> = True' --bootscript=./test.rcS --vio-9p
>>
>>  Mount cmd in guest OS: mount -t 9p -o
>> trans=virtio,version=9p2000.L,aname=/home/l00515693/m5out/9p/share gem5
>> /mnt/9p
>>
>> root@charlie:~# df -h
>>
>> Filesystem  Size  Used Avail Use% Mounted on
>>
>> /dev/root   9.9G  3.3G  6.2G  35% /
>>
>> devtmpfs2.0G  4.0K  2.0G   1% /dev
>>
>> none4.0K 0  4.0K   0% /sys/fs/cgroup
>>
>> none396M   52K  396M   1% /run
>>
>> none5.0M 0  5.0M   0% /run/lock
>>
>> none2.0G 0  2.0G   0% /run/shm
>>
>> none100M 0  100M   0% /run/user
>>
>> gem52.9T  1.8T  989G  65% /mnt/9p
>>
>>
>>
>>
>>
>>
>>
>>  2core:
>>
>>  Gem5 cmd: ./build/ARM/gem5.opt --debug-flags=Exec  -d
>> /home/l00515693/m5out configs/example/arm/fs_bigLITTLE.py --cpu-type=kvm
>> --kernel=vmlinux --machine-type=VExpress_GEM5_V1
>> --disk=expanded-aarch64-ubuntu-trusty-headless.img --caches
>> --big-cpu-clock=2.6GHz --little-cpu-clock=2.6GHz --big-cpus=2
>> --little-cpus=0 --mem-size=4GB --param 'system.realview.gic.gem5_extensions
>> = True' --bootscript=./test.rcS --vio-9p
>>
>>
>>
>>  Mount cmd in guest OS: mount -t 9p -o
>> trans=virtio,version=9p2000.L,aname=/home/l00515693/m5out/9p/share gem5
>> /mnt/9p
>>
>>
>>
>> GEM5 crash info:
>>
>> gem5.opt: build/ARM/sim/eventq_impl.hh:40: void
>> EventQueue::schedule(Event*, Tick, bool): Assertion `when >= getCurTick()'
>> failed.
>>
>> Program aborted at tick 476281849910020
>>
>> --- BEGIN LIBC BACKTRACE ---
>>
>> ./build/ARM/gem5.opt(_Z15print_backtracev+0x40)[0xdd24e418]
>>
>> ./build/ARM/gem5.opt(_Z12abortHandleri+0x5c)[0xdd25efa4]
>>
>> linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0x9fea5688]
>>
>> /lib/aarch64-linux-gnu/libc.so.6(raise+0xb0)[0x9f6634f8]
>>
>> --- END LIBC BACKTRACE ---
>>
>> Aborted (core dumped)
>>
>>
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: request to allocate mask for invalid number: Invalid argument

[Gabe Black via gem5-users]

This code seems to be calling system calls like mprotect which are not
implemented, and which are probably doing something important as far as how
the program works. Implementing these accurately would be complicated, and
so you best bet is probably to use full system mode.

Gabe

On Fri, Mar 12, 2021 at 7:47 AM Pedro Becker via gem5-users <
gem5-users@gem5.org> wrote:

> Hi all,
>
> I'm using gem5 to run a multithreaded & multicore application compiled for
> ARM (aarch64).
> My application under test is also dynamically compiled. I provide the
> --interpr-dir and --redirects flags to se.py so it can find the interpreter
> and libraries.
> I'm able to successfully run a simple/toy multithreaded application with
> this setup.
>
> However, when I move on to a more complex application (dependent on more
> libraries, etc) I'm facing the following error:
>
> warn: ignoring syscall mprotect(...)
> warn: ignoring syscall set_robust_list(...)
> warn: ignoring syscall rt_sigaction(...)
> warn: ignoring syscall rt_sigaction(...)
> warn: ignoring syscall rt_sigprocmask(...)
>   (further warnings will be suppressed)
> warn: ignoring syscall get_mempolicy(...)
> warn: ignoring syscall sched_getaffinity(...)
> warn: fcntl64(3, 3) passed through to host
> sysconf(NPROCESSORS_CONF) failed: No such file or directory
> warn: fcntl64(3, 3) passed through to host
> request to allocate mask for invalid number: Invalid argument
> Exiting @ tick 395657918000 because exiting with last active thread context
> Simulated exit code not 0! Exit code is 1
>
> Observations:
>   * I modified src/arch/arm/linux/process.cc to set "get_mempolicy"
> syscall as ignoreFunc. I was having an 'unimplemented' error prior to that,
> and I thought it was safe to do it because that's what is done in  the
> counterpart x86 file src/arch/x86/linux/process.cc
>   * I also modified the said code to be as simple as a
>  std::cout << "hello" << std::endl;
>   in the main function, and removed all remaining source code (but kept
> the linked libraries when compiling). The error persists.
>  I hence believe it has something to do with loading the libraries or
> environment preparation on gem5.
>
> There are previous threads about it but they are 3 years and were not very
> helpful for my case.
>
> Any suggestions?
> Thank you very much!
>
> Cheers,
> Pedro.
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: gem5 crash when mount by vio-9p protocol in KVM mode with more than 1 core

[Gabe Black via gem5-users]

I haven't looked at the code yet, but this is probably because the v9
implementation is getting asynchronous input which might be received by one
thread, which then tries to schedule an event on an event queue associated
with another queue. Most of the time this is not an issue since gem5 is
usually single threaded, but when using multiple cores with KVM, each core
runs in its own thread. There's a way to add events to the event queue in
another thread safely (ScopedMigration) which I'm assuming the v9 code is
not using.

Gabe

On Sun, Mar 7, 2021 at 8:38 PM Liyichao via gem5-users 
wrote:

> Hi All:
>
>
>
>  When I use –vio-9p with fs_bigLITTLE.py, 1 core the mount cmd was
> ok, but more than 1 core, mount cmd will cause GEM5 crash
>
>
>
>  1core:
>
>  Gem5 cmd: ./build/ARM/gem5.opt --debug-flags=Exec  -d
> /home/l00515693/m5out configs/example/arm/fs_bigLITTLE.py --cpu-type=kvm
> --kernel=vmlinux --machine-type=VExpress_GEM5_V1
> --disk=expanded-aarch64-ubuntu-trusty-headless.img --caches
> --big-cpu-clock=2.6GHz --little-cpu-clock=2.6GHz --big-cpus=1
> --little-cpus=0 --mem-size=4GB --param 'system.realview.gic.gem5_extensions
> = True' --bootscript=./test.rcS --vio-9p
>
>  Mount cmd in guest OS: mount -t 9p -o
> trans=virtio,version=9p2000.L,aname=/home/l00515693/m5out/9p/share gem5
> /mnt/9p
>
> root@charlie:~# df -h
>
> Filesystem  Size  Used Avail Use% Mounted on
>
> /dev/root   9.9G  3.3G  6.2G  35% /
>
> devtmpfs2.0G  4.0K  2.0G   1% /dev
>
> none4.0K 0  4.0K   0% /sys/fs/cgroup
>
> none396M   52K  396M   1% /run
>
> none5.0M 0  5.0M   0% /run/lock
>
> none2.0G 0  2.0G   0% /run/shm
>
> none100M 0  100M   0% /run/user
>
> gem52.9T  1.8T  989G  65% /mnt/9p
>
>
>
>
>
>
>
>  2core:
>
>  Gem5 cmd: ./build/ARM/gem5.opt --debug-flags=Exec  -d
> /home/l00515693/m5out configs/example/arm/fs_bigLITTLE.py --cpu-type=kvm
> --kernel=vmlinux --machine-type=VExpress_GEM5_V1
> --disk=expanded-aarch64-ubuntu-trusty-headless.img --caches
> --big-cpu-clock=2.6GHz --little-cpu-clock=2.6GHz --big-cpus=2
> --little-cpus=0 --mem-size=4GB --param 'system.realview.gic.gem5_extensions
> = True' --bootscript=./test.rcS --vio-9p
>
>
>
>  Mount cmd in guest OS: mount -t 9p -o
> trans=virtio,version=9p2000.L,aname=/home/l00515693/m5out/9p/share gem5
> /mnt/9p
>
>
>
> GEM5 crash info:
>
> gem5.opt: build/ARM/sim/eventq_impl.hh:40: void
> EventQueue::schedule(Event*, Tick, bool): Assertion `when >= getCurTick()'
> failed.
>
> Program aborted at tick 476281849910020
>
> --- BEGIN LIBC BACKTRACE ---
>
> ./build/ARM/gem5.opt(_Z15print_backtracev+0x40)[0xdd24e418]
>
> ./build/ARM/gem5.opt(_Z12abortHandleri+0x5c)[0xdd25efa4]
>
> linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0x9fea5688]
>
> /lib/aarch64-linux-gnu/libc.so.6(raise+0xb0)[0x9f6634f8]
>
> --- END LIBC BACKTRACE ---
>
> Aborted (core dumped)
>
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Shutdown x86 Full System simulation

[Gabe Black via gem5-users]

Hi Deepak. On a real system, you would probably use ACPI to tell the
chipset to power down the machine, but on gem5 you can probably just run
the "exit" pseudo instruction which will tell gem5 to exit back to the
python config file.

Gabe

On Wed, Mar 10, 2021 at 2:07 AM Deepak Mohan via gem5-users <
gem5-users@gem5.org> wrote:

> Hi,
> I was implementing an x86 operating system that runs on gem5
> simulator. I have to implement the shutdown functionality for the OS.
> From my initial research I found out that I have to use the ACPI for
> implementing shutdown (using outw(PM1a_CNT, SLP_TYPa | SLP_EN ); ).
> But the values of PM1a_CNT, SLP_TYPa and SLP_EN has to be gathered
> from the DSDT table of ACPI. When I searched the gem5 source for the
> DSDT table, I was unable to find it (there was classes defined for
> RSDT and XSDT tables).
> Can anyone please give any pointers towards where to search ? Or are
> there any other methods to shutdown the x86 Full system simulation ?
>
> Thanks,
> Deepak Mohan
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: scons error:invalid use of incomplete type 'class System'

[Gabe Black via gem5-users]

You have a circular dependency in your include files system.hh gets past
the compiler guard, then includes base.hh which includes cache.hh which
tries to include system.hh. Since system.hh has already started to be
included it gets skipped, but since it was only started none of the things
it defines are available yet. You can break these sorts of loops by being
careful to only include things you actually need, by declaring classes
without actually including their definitions, and by moving the use of
classes (and including their header files) into .cc files which won't be
part of a loop.

Gabe

On Thu, Feb 25, 2021 at 12:40 AM yangyuqing--- via gem5-users <
gem5-users@gem5.org> wrote:

> I use gem5 20 on ubuntu 20.04.
> I try to add some new features to gem5, but I do not damage class system.
> When I run scons, errors occurs like following:
> In file included from /usr/include/c++/9/cassert:44,
>  from build/X86/mem/cache/write_queue_entry.hh:49,
>  from build/X86/mem/cache/write_queue.hh:50,
>  from build/X86/mem/cache/base.hh:64,
>  from build/X86/mem/cache/cache.hh:53,
>  from build/X86/cpu/base.hh:65,
>  from build/X86/sim/system.hh:55,
>  from build/X86/arch/x86/fs_workload.cc:48:
> build/X86/mem/cache/base.hh: In member function 'void
> BaseCache::incMissCount(PacketPtr)':
> build/X86/mem/cache/base.hh:1224:48: error: invalid use of incomplete type
> 'class System'
>  1224 | assert(pkt->req->requestorId() < system->maxRequestors());
>   |^~
> In file included from build/X86/cpu/thread_context.hh:54,
>  from build/X86/arch/x86/fs_workload.hh:47,
>  from build/X86/arch/x86/fs_workload.cc:39:
> build/X86/cpu/pc_event.hh:39:7: note: forward declaration of 'class System'
>39 | class System;
>   |   ^~
> In file included from /usr/include/c++/9/cassert:44,
>  from build/X86/mem/cache/write_queue_entry.hh:49,
>  from build/X86/mem/cache/write_queue.hh:50,
>  from build/X86/mem/cache/base.hh:64,
>  from build/X86/mem/cache/cache.hh:53,
>  from build/X86/cpu/base.hh:65,
>  from build/X86/sim/system.hh:55,
>  from build/X86/arch/x86/fs_workload.cc:48:
> build/X86/mem/cache/base.hh: In member function 'void
> BaseCache::incHitCount(PacketPtr)':
> build/X86/mem/cache/base.hh:1235:48: error: invalid use of incomplete type
> 'class System'
>  1235 | assert(pkt->req->requestorId() < system->maxRequestors());
>   |^~
> In file included from build/X86/cpu/thread_context.hh:54,
>  from build/X86/arch/x86/fs_workload.hh:47,
>  from build/X86/arch/x86/fs_workload.cc:39:
> build/X86/cpu/pc_event.hh:39:7: note: forward declaration of 'class System'
>39 | class System;
>   |   ^~
>  [ CXX] X86/arch/x86/insts/static_inst.cc -> .o
> scons: *** [build/X86/arch/x86/fs_workload.o] Error 1
> scons: building terminated because of errors.
>
> I do not know what is wrong?
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Error coming while running gem5 in se mode

[Gabe Black via gem5-users]

The ARM in --cmd should be lower case.

On Mon, Feb 22, 2021 at 1:17 AM VAIDYA ROHINI VILAS via gem5-users <
gem5-users@gem5.org> wrote:

> I am trying to run gem5 in se mode by command *" build/ARM/gem5.opt
> configs/example/se.py --cmd=tests/test-progs/hello/bin/ARM/linux/hello"*
> error coming as
> *"warn: DRAM device capacity (8192 Mbytes) does not match the address
> range assigned (512 Mbytes)*
> *fatal: Can't load object file tests/test-progs/hello/bin/ARM/linux/hello"*
>
> please help me to solve the error.
> Thank you.
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Adding an ethernet device to x86 simulation

[Gabe Black via gem5-users]

Hi Lukas. It's not really clear from your description what the problem is,
but I would expect the "size()" method to be very simple, and so the "root"
pointer is probably null or corrupt. You should probably look into where
that value is coming from and what might have happened to it.

Gabe

On Thu, Feb 18, 2021 at 5:43 AM lsteiner--- via gem5-users <
gem5-users@gem5.org> wrote:

> Hi Gabe,
> there is already a post in Jira about the non-working dual option:
> https://gem5.atlassian.net/browse/GEM5-823
> However, they are using ARM and not X86 and encounter a different problem.
> I will also create a new post for the X86 problem.
> I've now performed a combination of the steps you told me and the steps
> described in
> https://gem5-users.gem5.narkive.com/rv4ZbtzB/simulating-two-x86-machines
> . A system is now set up properly but gem5 encounters a segmentation fault.
> When debugging with GDB I get the following output:
> Program received signal SIGSEGV, Segmentation fault.
> 0x5676aaab in Stats::Formula::size (this=0x59116718) at
> build/X86/base/statistics.cc:486
> 486 return root->size();
> Any ideas what the problem could be? Maybe some missing config parameters?
> Regards,
> Lukas
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Adding an ethernet device to x86 simulation

[Gabe Black via gem5-users]

Hi Lukas. Would you mind filing a bug in Jira describing what's wrong with
the --dual option? The provided configs have gotten really big and complex
over the years, and it can be hard to work with them to, for instance, add
a new device like you're trying to. You might consider making your own
config which does exactly what you want, perhaps starting with a copy of
the provided configs and stripping away unnecessary code and pulling things
together until you have a much smaller, simpler config to work with to make
just how you want it.

To answer your question more specifically, the IGBE_e1000 device inherits
from PciDevice ultimately which has all the stuff in it to work with PCI
from a software perspective. There needs to be a PciHost object somewhere
in the SimObject hierarchy above the device which sets policy like where
config space is, etc. That should just work I think, but if not you can
even set that parameter explicitly (called "host"). Other than that, I
think all you'll need to do is hook up the connection to memory/a bus, and
the network interface to whatever simulated network you set up.

Gabe

On Wed, Feb 17, 2021 at 6:47 AM lsteiner--- via gem5-users <
gem5-users@gem5.org> wrote:

> Hi all,
> I want to simulate an x86 server-client configuration in one gem5
> instance. Since the --dual option in fs.py does not work any more, I'm now
> trying to add an ethernet device (e.g., "IGbE_e1000") manually. Is there an
> example or a related thread that shows how to add such a device in the
> latest gem5 version? Do I have to attach the ethernet device to the
> "pci_bus" in "configs/common/FSConfig.py"?
> Thanks for your help!
> Regards,
> Lukas
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: X86KvmCPU fails -- reason code 0x80000021

[Gabe Black via gem5-users]

Hi Kevin. It looks like that change has already been checked in on the
develop branch in October. Judging by the dates on the releases, I'd guess
that would be included on version 20.1 (September), although I haven't
verified that specifically. It should definitely be in the develop branch,
and should also be in the next release which should be branched off of
develop fairly soon.

Gabe

On Wed, Feb 17, 2021 at 6:30 AM Kevin Loughlin via gem5-users <
gem5-users@gem5.org> wrote:

> Hi all,
>
> Returning to this thread, I had to apply Ryan's version of the patch Gabe
> mentioned to successfully boot the X86KvmCPU in FS mode. Thus, I do think
> we should merge it, unless there's something I'm missing.
>
> Has someone submitted this patch for review or is anyone planning to? If
> not, I'm happy to submit it. I have some other small patches to make the
> configuration work with multiple CPUs and the rdtscp instruction that I'm
> already going to be submitting here. Just let me know please.
>
> Thanks,
>
> Kevin
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Problem in using m5_checkpoint within C++ Application

[Gabe Black via gem5-users]

Hi Veronia. scons build/x86/out/m5 asks scons to build the m5 utility, not
the m5 library which is called build/x86/out/libm5.a. You may have some
other library on your system called m5 which -lm5 is picking up which
doesn't have that symbol.

Gabe

On Thu, Feb 4, 2021 at 3:52 AM Veronia Bahaa via gem5-users <
gem5-users@gem5.org> wrote:

> Hello,
>
> I have been trying to use the m5_checkpoint inside a C++ test program. But
> when I run the application makefile I always get
> undefined reference to `m5_checkpoint' collect2: error: ld returned 1 exit
> status
> I did the following steps:
> 1- Build m5 and lib m5 using scons build/x86/out/m5
> 2- Add #include  to the test application C++ file
> 3- Add these commands to the Makefile
> GEM5_PATH = /home/veronia/gem5
> TARGET_ISA = x86
> CFLAGS = -I$(GEM5_PATH)/include
> LDFLAGS = -L$(GEM5_PATH)/util/m5/build/$(TARGET_ISA)/out -lm5
>
> Am I  missing some steps?
> Thanks in advance!
>
> Cheers,
> Veronia
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: VExpress_GEM5_V1, Ethernet, and BARs

[Gabe Black via gem5-users]

iacomo Travaglini
> Cc: Gabe Black; Bohren, Jonathan
> Subject: [gem5-users] Re: VExpress_GEM5_V1, Ethernet, and BARs
>
>
> Giacomo,
>
>
> That's good to know.
>
>
> We're running `fs.py` with `system/arm/dt/armv7_gem5_v1_1cpu.dtb` which
> we've copied into our working directory.
>
>
> Full invocation:
>
>
> ```
>
> ./gem5/build/ARM/gem5.opt \
>
> gem5/configs/example/fs.py \
>
> --bootloader ./boot.arm \
>
> --kernel=./vmlinux \
>
> --machine-type=VExpress_GEM5_V1 \
>
> --dtb-file=./armv7_gem5_v1_1cpu.dtb \
>
> --disk-image=../image/ubuntu-base-18.04.5-base-armhf.img \
>
> --root-device=/dev/sda
>
> ```
>
>
> -jrb
>
> From: Giacomo Travaglini 
> Sent: Friday, January 22, 2021 8:16:48 AM
> To: gem5 users mailing list 
> Cc: Gabe Black ; Bohren, Jonathan <
> jrboh...@honeybeerobotics.com>
> Subject: RE: [gem5-users] Re: VExpress_GEM5_V1, Ethernet, and BARs
>
>
> Out of curiosity, which DTB are you using?
> IMO the kernel shouldn't write 800 to the PCI Bar, knowing there is
> DRAM there and this is notified via the DTB
>
> Kind Regards
>
> Giacomo
>
> > -Original Message-
> > From: Bohren, Jonathan via gem5-users 
> > Sent: 22 January 2021 12:51
> > To: gem5 users mailing list 
> > Cc: Gabe Black ; Bohren, Jonathan
> > 
> > Subject: [gem5-users] Re: VExpress_GEM5_V1, Ethernet, and BARs
> >
> > Gabe,
> >
> >
> >
> > Yeah, this is a very recent version of `develop`. This is after rebasing
> a recent
> > proposed change `38796` [1] (which disables the HDLcd) onto `develop`
> HEAD
> > from 2020-01-20:
> >
> >
> >
> > ```
> >
> > c6e3fd79f (develop-rebase-38796) dev-arm, system-arm: Remove HDLcd from
> > VExpress_GEM5_VX platforms
> >
> > b9ce8848e system-arm: Move display node into a shared DTS file
> >
> > 71932a360 (upstream/develop, develop) dev: Fixing EtherDevice stats
> > initialization order
> >
> > ```
> >
> >
> >
> > The two changesets in CL `38796` [1] were based on `3059c6d` which was
> the
> > HEAD of `develop` on 2020-01-05, and it didn’t appear that CL `38796`
> reverted
> > any changes made in the interim.
> >
> >
> >
> > I came across a similar discussion in the archives [2], which did seem
> similar,
> > but didn’t address the problem described below. Is the bug you’re
> referring to
> > the one addressed by CL `35516` [3]?
> >
> >
> >
> > Thanks for taking a look at this!
> >
> >
> >
> > [1] https://gem5-review.googlesource.com/c/public/gem5/+/38796
> > <https://gem5-review.googlesource.com/c/public/gem5/+/38796>
> >
> > [2] https://www.mail-archive.com/gem5-users@gem5.org/msg18647.html
> > <https://www.mail-archive.com/gem5-users@gem5.org/msg18647.html>
> >
> > [3] https://gem5-review.googlesource.com/c/public/gem5/+/35516
> > <https://gem5-review.googlesource.com/c/public/gem5/+/35516>
> >
> >
> >
> > -jrb
> >
> >
> >
> > From: Gabe Black via gem5-users 
> > Sent: Thursday, January 21, 2021 11:59 PM
> > To: gem5 users mailing list 
> > Cc: Gabe Black 
> > Subject: [gem5-users] Re: VExpress_GEM5_V1, Ethernet, and BARs
> >
> >
> >
> > Are you using up to date develop? There was a bug like this a while ago,
> but it's
> > been fixed on develop for a while as well.
> >
> >
> >
> > Gabe
> >
> >
> >
> > On Thu, Jan 21, 2021 at 6:35 PM Bohren, Jonathan via gem5-users  > us...@gem5.org <mailto:gem5-users@gem5.org> > wrote:
> >
> > We've been using the `VExpress_GEM5_V1` platform but it was failing
> > on both `stable` and `develop` when adding an `IGbE_e1000` PCI device to
> the
> > `makeArmSystem()` function in `FSConfig.py`. We've worked around it, but
> > looking for the "right way" to add such a device.
> >
> > For reference, the change is shown here:
> > ```
> > diff --git a/configs/common/FSConfig.py
> > b/configs/common/FSConfig.py
> > index 6fd39a5aa..837d95982 100644
> > --- a/configs/common/FSConfig.py
> > +++ b/configs/common/FSConfig.py
> > @@ -226,6 +226,8 @@ def makeArmSystem(mem_mode,
> > machine_type, num_cpus=1, mdesc=None,
> >  else:
> >  self.pci_ide = IdeController(disks=disks)
> >  pci_devices.append(self.pci_ide)
> > +self.realview.ethernet = IGbE_e1000()
> > +pci_devices.append(self.realview.ethernet)
>

[gem5-users] Re: VExpress_GEM5_V1, Ethernet, and BARs

[Gabe Black via gem5-users]

Are you using up to date develop? There was a bug like this a while ago,
but it's been fixed on develop for a while as well.

Gabe

On Thu, Jan 21, 2021 at 6:35 PM Bohren, Jonathan via gem5-users <
gem5-users@gem5.org> wrote:

> We've been using the `VExpress_GEM5_V1` platform but it was failing on
> both `stable` and `develop` when adding an `IGbE_e1000` PCI device to the
> `makeArmSystem()` function in `FSConfig.py`. We've worked around it, but
> looking for the "right way" to add such a device.
>
> For reference, the change is shown here:
> ```
> diff --git a/configs/common/FSConfig.py b/configs/common/FSConfig.py
> index 6fd39a5aa..837d95982 100644
> --- a/configs/common/FSConfig.py
> +++ b/configs/common/FSConfig.py
> @@ -226,6 +226,8 @@ def makeArmSystem(mem_mode, machine_type, num_cpus=1,
> mdesc=None,
>  else:
>  self.pci_ide = IdeController(disks=disks)
>  pci_devices.append(self.pci_ide)
> +self.realview.ethernet = IGbE_e1000()
> +pci_devices.append(self.realview.ethernet)
>
>  self.mem_ranges = []
>  size_remain = long(Addr(mdesc.mem()))
> ```
>
> Specifically, the error that results during boot is regarding an address
> range collision once the device loads:
> ```
> fatal: system.iobus has two ports responding within range
> [0x8000:0x8002]:
> system.realview.ethernet.pio
> system.iobridge.cpu_side_port
> ```
>
> That `0x8000:0x8002` range corresponds exactly to the 128kB BAR0
> of the `IGbE` device.
>
> The recent change [1] makes it clear that this is an issue because the
> `IGbE_e1000` device uses a `PciMemBar`, which overlaps with the Realview's
> DRAM address range, while the pre-existing `IdeController` device only uses
> `PciIoBar` BARs, which don't. It's  possible to avoid the range collision
> by changing the Ethernet device's `PciMemBar` to a `PciIoBar` to keep it
> out of the DRAM range, but it's not yet clear if that workaround will cause
> other issues.
>
> What's the proper way to avoid this collision?
>
> [1] https://gem5-review.googlesource.com/c/public/gem5/+/35516
>
>  -jrb
>
> 
>
> DISCLAIMER:
> This e-mail may contain ITAR controlled technical data as defined by 22
> CFR 120.10 and may not be forwarded or disclosed to any Foreign Person, as
> defined at 22 CFR 120.16, without the prior written consent of Honeybee
> Robotics and the United States Department of State.
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Installation issue in MAC OS

[Gabe Black via gem5-users]

This is from newer versions of scons changing how initialization works, and
where and when gem5's scons files update the python search path. It's fixed
on the develop branch, if you want to try that.

Gabe

On Tue, Jan 19, 2021 at 2:39 AM 刘宗惠 via gem5-users 
wrote:

> Hello,
>
> I am new to gem5 and trying to install and build it in MacOS. I also get
> the following error when I try to build the binaries for x86 processor:
>
> *** Error loading site_init file ./site_scons/site_init.py:
> *** cannot import site init file ./site_scons/site_init.py:
> ModuleNotFoundError: No module named 'm5.util’:
>
> Did you solve this problem? Could you tell me what to do next or where to
> find the answer to this problem?
>
> Thanks,
> Liu Zonghui
> Wuhan University of Technology
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Implementation of write() Syscall in SE Mode

[Gabe Black via gem5-users]

SE mode does not work at the standard library level, it works at the system
call level. As long as your custom standard library uses the normal linux
system calls and the normal linux system call ABI, you shouldn't have to do
anything special. There could be a very minor technical exception on x86
where on a real system the kernel has to provide tiny helpers since there
are 3 different ways to call system calls (int, sysenter, syscall) and the
program doesn't have a good/efficient way to know which to use. Those are
built into gem5 in assembly and loaded into memory as the program is set
up, but I don't think RISCV does anything like that since it doesn't have
all the baggage x86 does.

Gabe

On Thu, Jan 14, 2021 at 12:47 AM jan.thoma--- via gem5-users <
gem5-users@gem5.org> wrote:

> Hi all,
>
> I am a little stuck and would appreciate if someone could help. I am
> simulating in Gem5 syscall emulation mode and I've made some modifications
> to the CPU model to support some additional instructions (RISC-V). To
> compile programs using the new instructions, I also have a clang compiler
> that places the instructions. It is important that *every* piece of code
> that is executed on the core goes through my own compiler. I compiled
> Newlib
> for libc support. Unfortunately, the _write() function (that is, the
> function that executes the syscall) has to be implemented manually. Is
> there
> a way to print to stdout in syscall emulation mode where I compile the libc
> myself? What would the _write() function have to implement? Is there any
> other way to print during simulation?
>
> From other platforms I am used to solutions like "write at a specific
> address" but I couldn't find anything like that for Gem5. I realize that
> the
> problem is very unusual, I would appreciate any help. Thanks!
>
> Best,
> Jan
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Extra timing for specific instruction not registered for RISC-V

[Gabe Black via gem5-users]

I just did a quick check, and it looks like the RISCV ISA definition
includes support for the instruction based pseudo ops. If you add support
to the m5 utility, then it might just work.

Gabe

On Wed, Dec 2, 2020 at 9:04 PM Volkan Mutlu via gem5-users <
gem5-users@gem5.org> wrote:

> Hello everyone, I believe I found a small problem with the way custom
> timings are handled through the MinorFUTiming class. I wanted to submit it
> to the tracker but the Jira webpage constantly keeps refreshing and I can't
> access any issue pages. If anybody knows an alternate way to make this
> issue known please let me know.
>
> I was trying to add a new functional unit to the MinorCPU through the
> python interface and I specified some custom timings for a set of custom
> instructions that I have. One snippet looked like this:
>
> timings =
> [MinorFUTiming(match=0x200300b,mask=0xfe00707f,description='shatransform',extraCommitLat=65,srcRegsRelativeLats=[0]),
>
> MinorFUTiming(match=0x8000100b,mask=0xfe00707f,description='sipcompress',extraCommitLat=3,srcRegsRelativeLats=[0]),
>
> MinorFUTiming(match=0x8000200b,mask=0xfe00707f,description='sipfinalize',extraCommitLat=4,srcRegsRelativeLats=[0])]
>
> But I noticed the extraCommitLat values were not affecting anything in my
> simulations. I tracked the issue down to a function called findTiming in
> /gem5/src/cpu/minor/func_unit.cc . It seems this is the function
> responsible for finding this extra timing information. However, there is a
> conditional directive at the beginning of the function that is as follows:
>
> #if THE_ISA == ARM_ISA
> /* This should work for any ISA with a POD mach_inst */
> TheISA::ExtMachInst mach_inst = inst->machInst;
> #else
> /* Just allow extra decode based on op classes */
> uint64_t mach_inst = 0;
> #endif
>
> So if gem5 is not built for ARM, it seems you can only specify extra
> timing information for op classes in general. Different instructions from
> the same op class will not get assigned timing information even if you
> specify it as I did above. I changed the conditional to be (THE_ISA ==
> ARM_ISA) || (THE_ISA == RISCV_ISA) , and that seems to have fixed the issue.
>
> If anybody working with RISC-V builds experienced similar issues maybe
> this can help. Also let me know if this fix is somehow not appropriate or
> might have other consequences to be mindful of.
>
> Thanks.
>
> PS: As an off-topic question, does anyone know of a reliable way to
> instrument code running in SE mode for RISC-V? I asked a similar question
> here before, m5ops was suggested but there are no m5ops pseudo-instructions
> implemented for RISC-V as of now to the best of my knowledge. I've been
> trying to make use of hardware performance counters (for instance using
> rdcycle), but I find that its unreliable and doesn't add up when compared
> to the stat dump that I see from gem5. Thanks in advance.
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: 答复: 答复: Re: Looking for Linux disk image for 64-bit ARM with Ubuntu 18.04 or GLIBC 2.27

[Gabe Black via gem5-users]

Don't use -o,loop with mount. That creates another loopback device and then
tries to use that, and apparently reuses /dev/loop4. If you look in /dev,
there will also be a /dev/loop4p1 (for instance) for each partition. Mount
that device instead.

Gabe

On Wed, Dec 2, 2020 at 12:07 AM Boya Chen via gem5-users <
gem5-users@gem5.org> wrote:

> This image can work.
> The offset of the image is 65536, not 32256
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: 答复: Re: Looking for Linux disk image for 64-bit ARM with Ubuntu 18.04 or GLIBC 2.27

[Gabe Black via gem5-users]

That's probably a disk image and not a file system image. You need to tell
losetup to scan for the partition table with I think the -p option.

Gabe

On Tue, Dec 1, 2020 at 10:02 AM Choe, Jiwon via gem5-users <
gem5-users@gem5.org> wrote:

> I'm running into the same issue as well.
>
> -Jiwon
>
> On Mon, Nov 30, 2020 at 10:32 PM Liyichao via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi:
>> I download the img you mentioned, when I mount it on /media,it's
>> wrong:
>>
>>
>> root@ubuntu:/home/l00515693/fs-image_fx/disks# mount -o
>> loop,offset=32256
>> /home/l00515693/fs-image_fx/disks/ubuntu-18.04-arm64-docker.img /media/
>> mount: /media: wrong fs type, bad option, bad superblock on /dev/loop4,
>> missing codepage or helper program, or other error.
>>
>>
>>
>> -邮件原件-
>> 发件人: Giacomo Travaglini via gem5-users [mailto:gem5-users@gem5.org]
>> 发送时间: 2020年11月30日 16:47
>> 收件人: gem5 users mailing list 
>> 抄送: Giacomo Travaglini 
>> 主题: [gem5-users] Re: Looking for Linux disk image for 64-bit ARM with
>> Ubuntu 18.04 or GLIBC 2.27
>>
>> Hi Jiwon
>>
>> We recently uploaded a prebuilt Ubuntu18.04 on gem5.org:
>>
>>
>> http://dist.gem5.org/dist/current/arm/disks/ubuntu-18.04-arm64-docker.img.bz2
>>
>> Kind Regards
>>
>> Giacomo
>>
>> > -Original Message-
>> > From: Choe, Jiwon via gem5-users 
>> > Sent: 29 November 2020 04:42
>> > To: gem5 users mailing list 
>> > Cc: Choe, Jiwon 
>> > Subject: [gem5-users] Looking for Linux disk image for 64-bit ARM with
>> > Ubuntu
>> > 18.04 or GLIBC 2.27
>> >
>> > Hi all,
>> >
>> > I'm looking for a Linux disk image for 64-bit ARM that has GLIBC
>> > version 2.27 (Ubuntu 18.04+ I think).
>> >
>> > I am trying to run Java JDK that has been compiled on Ubuntu 18.04
>> > (with GLIBC 2.27) on a gem5 ARM FS simulation. I am currently using
>> > the disk image that I got from here:
>> > http://dist.gem5.org/dist/current/arm/disks/aarch64-
>> > ubuntu-trusty-headless.img.bz2
>> >
>> > But when I try to run java, I get the following error within the
>> simulated system:
>> > java -version java -version
>> >
>> > Error: dl failure on line 604
>> > Error: failed /usr/lib/jvm/jdk/lib/server/libjvm.so, because
>> > /lib/aarch64-linux-
>> > gnu/libm.so.6: version `GLIBC_2.27' not found (required by
>> > /usr/lib/jvm/jdk/lib/server/libjvm.so)
>> >
>> >
>> > I think this happens because the disk image that I am using runs
>> > Ubuntu 14.04, which has GLIBC 2.19, but I compiled the java executable
>> > on Ubuntu 18.04 with GLIBC 2.27.
>> >
>> > So, if anyone has a Linux disk image (for 64-bit ARM) that has GLIBC
>> > 2.27, or if anyone knows how to upgrade GLIBC on the existing disk
>> > image, I would greatly appreciate your help.
>> >
>> > Thanks!
>> > Jiwon
>> 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-users mailing list -- gem5-users@gem5.org To unsubscribe send an
>> email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: 'DPRINTF' was not declared in this scope

[Gabe Black via gem5-users]

You need to include base/trace.hh which defines DPRINTF itself.

Gabe

On Sat, Nov 21, 2020 at 8:33 PM yujiecui--- via gem5-users <
gem5-users@gem5.org> wrote:

> I want to know the cache information when the replacement algorithm is
> executed. So I made the following changes in the latest version of gem5. I
> added a line of DebugFlag('ReplacementInfo') command to the
> /home/cuiyujie/workspace/workGem5/gem5/src/mem/cache/replacement_policies/SConscript
> file. Then I added the header file #include "debug/ReplacementInfo.hh" in
> the /home/cuiyujie/workspace/workGem5/gem5/build/X86/params/RandomRP.cc
> file. Then I used DPRINTF(ReplacementInfo, "candidates"); command in this
> file. But an error occurred during compilation.
>
> build/X86/mem/cache/replacement_policies/random_rp.cc: In member
> function'virtual ReplaceableEntry* RandomRP::getVictim(const
> ReplacementCandidates&) const':
> build/X86/mem/cache/replacement_policies/random_rp.cc:82:13:
> error:'ReplacementInfo' was not declared in this scope
>  DPRINTF(ReplacementInfo, "candidates");
>  ^
> build/X86/mem/cache/replacement_policies/random_rp.cc:82:13: note:
> suggested alternative:
> In file included from
> build/X86/mem/cache/replacement_policies/random_rp.cc:44:0:
> build/X86/debug/ReplacementInfo.hh:18:19: note:'Debug::ReplacementInfo'
>  extern SimpleFlag ReplacementInfo;
>^
> build/X86/mem/cache/replacement_policies/random_rp.cc:82:42:
> error:'DPRINTF' was not declared in this scope
>  DPRINTF(ReplacementInfo, "candidates");
>   ^
> scons: *** [build/X86/mem/cache/replacement_policies/random_rp.o] Error 1
> scons: building terminated because of errors.
>
> What do you need to define first to use DPRINTF?
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Need Help For Applying a Patch

[Gabe Black via gem5-users]

gem5 does not use mercurial any more and hasn't for a while, and so using
hg commands probably won't work. You should be able to apply the patches
using the normal "patch" command, or even with git using the "git am"
command, but if your patches are really old (likely if they're geared
towards mercurial) then they likely won't apply cleanly.

Gabe

On Wed, Nov 18, 2020 at 6:59 PM Srikrishna Vasudev via gem5-users <
gem5-users@gem5.org> wrote:

> Hello everyone!
> I am trying to implement a patch, but for some reason I am unable to do
> it. I feel like I might be missing a step in between somewhere.
> I am using the instructions given in this site to import the patch:
> https://synergy.ece.gatech.edu/tools/garnet/mercurial-patches-for-gem5garnet/
> I want to implement this patch:
> https://github.com/farzadfch/gem5-cache-partitioning
> In the* patches* folder I have made a txt file name *series* and and I
> have also copied the patch there. I use the *echo* command to write the
> name of the patch in the series txt file as it is written in the
> instructions. But when I use the* hg qpush *command it shows the message
> "no patch in series".
> I have tried using a different patch as well, but it also shows the same
> message.
> I am new to gem5 and all the stuff related to it, so I might be making
> some mistake.
> Kindly help me out guys!
> Thank you.
>
> With regards
> Srikrishna Vasudev
>
>
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: m5ops for riscv

[Gabe Black via gem5-users]

In what way was it not possible? Did you get an error message?

Gabe

On Wed, Nov 18, 2020 at 1:51 PM Cristobal Ramirez Lazo via gem5-users <
gem5-users@gem5.org> wrote:

> Dear all,
> I would like to use the m5ops functions such as "m5_reset_stats" in my own
> c++ program.
> I have done it for x86, however, I would like to do it for RISC-V.
>
> For X86 I performed the following:
>
> scons -C util/m5 build/x86/out/m5
> gcc -static -I include -o main.out main.c util/m5/build/x86/out/libm5.a
>
> My C program:
>
> #include 
> #include 
>
> int main() {
> printf("Hello, World!");
> m5_reset_stats(0,0);
> return 0;
> }
>
> However, when I have tried for RISC-V, it was not possible. Do you know if 
> there is support for RISC-V ?
>
> Thanks !!
>
> Cristóbal
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Compiling m5 utils

[Gabe Black via gem5-users]

It's an option for the m5 utility, not the gem5 simulator. It tells the
utility to use a different mechanism to trigger the operations, one based
on a special address rather than special, otherwise undefined instructions.

Gabe

On Sat, Nov 14, 2020 at 1:10 AM krishnan gosakan 
wrote:

> I am using KVM cpu. What is that --addr flag? I can't find it in
> options.py and get an error when invoking gem5 with it.
> fs.py: error: no such option: --addr
> I compiled m5 from the latest master branch and tried using it in my old
> branch
> I get "Illegal Instruction" error. Is that due to KVM and not using --addr
> flag?
>
> On Sat, Nov 14, 2020 at 2:32 PM Gabe Black  wrote:
>
>> I think that should work, although I haven't tried it. If you're using
>> the new m5 utility with x86 and the KVM cpu, be sure you use the --addr
>> flag. If not, then I think it should work the same.
>>
>> Gabe
>>
>> On Sat, Nov 14, 2020 at 12:24 AM krishnan gosakan via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> Can I use m5 util from the current stable branch with the old gem5 repo
>>> I am currently using? Will that won't create compatibility issues?
>>>
>>> On Sat, Nov 14, 2020 at 1:38 PM Gabe Black via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
>>>> Probably not. There were some other fixes which made things partially
>>>> work with PIE code, but the version of the utility you're using may be too
>>>> old to include those, or you might be trying to use it in a way that the
>>>> partial support didn't cover (different ISA for instance). You'll probably
>>>> save yourself a lot of headaches by moving to a more recent version of
>>>> gem5, at least for the m5 utility if you can't or don't want to move
>>>> completely.
>>>>
>>>> Gabe
>>>>
>>>> On Fri, Nov 13, 2020 at 11:28 PM krishnan gosakan <
>>>> krishnan.gosa...@gmail.com> wrote:
>>>>
>>>>> I tried make.
>>>>> I used the command make -f Makefile.x86
>>>>> for which I got the following error
>>>>>
>>>>> gcc -O2 -DM5OP_ADDR=0x -I../../include -o m5.o -c m5.c
>>>>>> gcc -O2 -DM5OP_ADDR=0x -I../../include -o m5op_x86.o -c
>>>>>> m5op_x86.S
>>>>>> gcc -O2 -DM5OP_ADDR=0x -I../../include -o m5_mmap.o -c
>>>>>> m5_mmap.c
>>>>>> gcc -o m5 m5.o m5op_x86.o m5_mmap.o
>>>>>> /usr/bin/ld: m5op_x86.o: relocation R_X86_64_32S against symbol
>>>>>> `m5_mem' can not be used when making a PIE object; recompile with -fPIC
>>>>>> /usr/bin/ld: final link failed: Nonrepresentable section on output
>>>>>> collect2: error: ld returned 1 exit status
>>>>>> Makefile.x86:54: recipe for target 'm5' failed
>>>>>> make: *** [m5] Error 1
>>>>>>
>>>>>
>>>>> Even i added -fPIC in makefile and still getting the same error
>>>>>
>>>>> gcc -O2 -DM5OP_ADDR=0x -I../../include -fPIC -o m5.o -c m5.c
>>>>>> gcc -O2 -DM5OP_ADDR=0x -I../../include -fPIC -o m5op_x86.o -c
>>>>>> m5op_x86.S
>>>>>> gcc -O2 -DM5OP_ADDR=0x -I../../include -fPIC -o m5_mmap.o -c
>>>>>> m5_mmap.c
>>>>>> gcc -o m5 m5.o m5op_x86.o m5_mmap.o
>>>>>> /usr/bin/ld: m5op_x86.o: relocation R_X86_64_32S against symbol
>>>>>> `m5_mem' can not be used when making a PIE object; recompile with -fPIC
>>>>>> /usr/bin/ld: final link failed: Nonrepresentable section on output
>>>>>> collect2: error: ld returned 1 exit status
>>>>>> Makefile.x86:54: recipe for target 'm5' failed
>>>>>> make: *** [m5] Error 1
>>>>>>
>>>>>
>>>>> Am I missing anything here?
>>>>>
>>>>> On Sat, Nov 14, 2020 at 9:32 AM Gabe Black 
>>>>> wrote:
>>>>>
>>>>>> That version of gem5 is a few years old and doesn't have the updates
>>>>>> to the m5 utility that made it use scons. In that version, you need to 
>>>>>> use
>>>>>> make.
>>>>>>
>>>>>> Gabe
>>>>>>
>>>>>> On Fri, Nov 13, 2020 at 7:43 PM krishnan gosakan via gem5-users <
>>>>>> gem5-users@gem5.org> wrote:
>>>>>>
>>>>>>

[gem5-users] Re: Compiling m5 utils

[Gabe Black via gem5-users]

I think that should work, although I haven't tried it. If you're using the
new m5 utility with x86 and the KVM cpu, be sure you use the --addr flag.
If not, then I think it should work the same.

Gabe

On Sat, Nov 14, 2020 at 12:24 AM krishnan gosakan via gem5-users <
gem5-users@gem5.org> wrote:

> Can I use m5 util from the current stable branch with the old gem5 repo I
> am currently using? Will that won't create compatibility issues?
>
> On Sat, Nov 14, 2020 at 1:38 PM Gabe Black via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Probably not. There were some other fixes which made things partially
>> work with PIE code, but the version of the utility you're using may be too
>> old to include those, or you might be trying to use it in a way that the
>> partial support didn't cover (different ISA for instance). You'll probably
>> save yourself a lot of headaches by moving to a more recent version of
>> gem5, at least for the m5 utility if you can't or don't want to move
>> completely.
>>
>> Gabe
>>
>> On Fri, Nov 13, 2020 at 11:28 PM krishnan gosakan <
>> krishnan.gosa...@gmail.com> wrote:
>>
>>> I tried make.
>>> I used the command make -f Makefile.x86
>>> for which I got the following error
>>>
>>> gcc -O2 -DM5OP_ADDR=0x -I../../include -o m5.o -c m5.c
>>>> gcc -O2 -DM5OP_ADDR=0x -I../../include -o m5op_x86.o -c
>>>> m5op_x86.S
>>>> gcc -O2 -DM5OP_ADDR=0x -I../../include -o m5_mmap.o -c m5_mmap.c
>>>> gcc -o m5 m5.o m5op_x86.o m5_mmap.o
>>>> /usr/bin/ld: m5op_x86.o: relocation R_X86_64_32S against symbol
>>>> `m5_mem' can not be used when making a PIE object; recompile with -fPIC
>>>> /usr/bin/ld: final link failed: Nonrepresentable section on output
>>>> collect2: error: ld returned 1 exit status
>>>> Makefile.x86:54: recipe for target 'm5' failed
>>>> make: *** [m5] Error 1
>>>>
>>>
>>> Even i added -fPIC in makefile and still getting the same error
>>>
>>> gcc -O2 -DM5OP_ADDR=0x -I../../include -fPIC -o m5.o -c m5.c
>>>> gcc -O2 -DM5OP_ADDR=0x -I../../include -fPIC -o m5op_x86.o -c
>>>> m5op_x86.S
>>>> gcc -O2 -DM5OP_ADDR=0x -I../../include -fPIC -o m5_mmap.o -c
>>>> m5_mmap.c
>>>> gcc -o m5 m5.o m5op_x86.o m5_mmap.o
>>>> /usr/bin/ld: m5op_x86.o: relocation R_X86_64_32S against symbol
>>>> `m5_mem' can not be used when making a PIE object; recompile with -fPIC
>>>> /usr/bin/ld: final link failed: Nonrepresentable section on output
>>>> collect2: error: ld returned 1 exit status
>>>> Makefile.x86:54: recipe for target 'm5' failed
>>>> make: *** [m5] Error 1
>>>>
>>>
>>> Am I missing anything here?
>>>
>>> On Sat, Nov 14, 2020 at 9:32 AM Gabe Black  wrote:
>>>
>>>> That version of gem5 is a few years old and doesn't have the updates to
>>>> the m5 utility that made it use scons. In that version, you need to use
>>>> make.
>>>>
>>>> Gabe
>>>>
>>>> On Fri, Nov 13, 2020 at 7:43 PM krishnan gosakan via gem5-users <
>>>> gem5-users@gem5.org> wrote:
>>>>
>>>>> Hi all,
>>>>> I am trying to compile m5 utils. I followed the documentation
>>>>> available at https://www.gem5.org/documentation/general_docs/m5ops/
>>>>> I am using
>>>>> https://gem5.googlesource.com/public/gem5/+/f0364a2b08f8919347164e9aad82ca3a0167eb4b
>>>>>
>>>>> In the above repo, utils/m5 directory has no scons file and I am
>>>>> facing difficulty in compiling m5. Can anyone help me with this?
>>>>> Thanks in advance.
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Krishnan.
>>>>> ___
>>>>> gem5-users mailing list -- gem5-users@gem5.org
>>>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>>
>>>>
>>>
>>> --
>>> Regards,
>>> Krishnan.
>>>
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
>
> --
> Regards,
> Krishnan.
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Compiling m5 utils

[Gabe Black via gem5-users]

Probably not. There were some other fixes which made things partially work
with PIE code, but the version of the utility you're using may be too old
to include those, or you might be trying to use it in a way that the
partial support didn't cover (different ISA for instance). You'll probably
save yourself a lot of headaches by moving to a more recent version of
gem5, at least for the m5 utility if you can't or don't want to move
completely.

Gabe

On Fri, Nov 13, 2020 at 11:28 PM krishnan gosakan <
krishnan.gosa...@gmail.com> wrote:

> I tried make.
> I used the command make -f Makefile.x86
> for which I got the following error
>
> gcc -O2 -DM5OP_ADDR=0x -I../../include -o m5.o -c m5.c
>> gcc -O2 -DM5OP_ADDR=0x -I../../include -o m5op_x86.o -c m5op_x86.S
>> gcc -O2 -DM5OP_ADDR=0x -I../../include -o m5_mmap.o -c m5_mmap.c
>> gcc -o m5 m5.o m5op_x86.o m5_mmap.o
>> /usr/bin/ld: m5op_x86.o: relocation R_X86_64_32S against symbol `m5_mem'
>> can not be used when making a PIE object; recompile with -fPIC
>> /usr/bin/ld: final link failed: Nonrepresentable section on output
>> collect2: error: ld returned 1 exit status
>> Makefile.x86:54: recipe for target 'm5' failed
>> make: *** [m5] Error 1
>>
>
> Even i added -fPIC in makefile and still getting the same error
>
> gcc -O2 -DM5OP_ADDR=0x -I../../include -fPIC -o m5.o -c m5.c
>> gcc -O2 -DM5OP_ADDR=0x -I../../include -fPIC -o m5op_x86.o -c
>> m5op_x86.S
>> gcc -O2 -DM5OP_ADDR=0x -I../../include -fPIC -o m5_mmap.o -c
>> m5_mmap.c
>> gcc -o m5 m5.o m5op_x86.o m5_mmap.o
>> /usr/bin/ld: m5op_x86.o: relocation R_X86_64_32S against symbol `m5_mem'
>> can not be used when making a PIE object; recompile with -fPIC
>> /usr/bin/ld: final link failed: Nonrepresentable section on output
>> collect2: error: ld returned 1 exit status
>> Makefile.x86:54: recipe for target 'm5' failed
>> make: *** [m5] Error 1
>>
>
> Am I missing anything here?
>
> On Sat, Nov 14, 2020 at 9:32 AM Gabe Black  wrote:
>
>> That version of gem5 is a few years old and doesn't have the updates to
>> the m5 utility that made it use scons. In that version, you need to use
>> make.
>>
>> Gabe
>>
>> On Fri, Nov 13, 2020 at 7:43 PM krishnan gosakan via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> Hi all,
>>> I am trying to compile m5 utils. I followed the documentation available
>>> at https://www.gem5.org/documentation/general_docs/m5ops/
>>> I am using
>>> https://gem5.googlesource.com/public/gem5/+/f0364a2b08f8919347164e9aad82ca3a0167eb4b
>>>
>>> In the above repo, utils/m5 directory has no scons file and I am facing
>>> difficulty in compiling m5. Can anyone help me with this?
>>> Thanks in advance.
>>>
>>> --
>>> Regards,
>>> Krishnan.
>>> ___
>>> gem5-users mailing list -- gem5-users@gem5.org
>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>>
>
> --
> Regards,
> Krishnan.
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Compiling m5 utils

[Gabe Black via gem5-users]

That version of gem5 is a few years old and doesn't have the updates to the
m5 utility that made it use scons. In that version, you need to use make.

Gabe

On Fri, Nov 13, 2020 at 7:43 PM krishnan gosakan via gem5-users <
gem5-users@gem5.org> wrote:

> Hi all,
> I am trying to compile m5 utils. I followed the documentation available at
> https://www.gem5.org/documentation/general_docs/m5ops/
> I am using
> https://gem5.googlesource.com/public/gem5/+/f0364a2b08f8919347164e9aad82ca3a0167eb4b
>
> In the above repo, utils/m5 directory has no scons file and I am facing
> difficulty in compiling m5. Can anyone help me with this?
> Thanks in advance.
>
> --
> Regards,
> Krishnan.
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0

[Gabe Black via gem5-users]

n
>>>
>>>
>>>
>>>
>>> On Mon, Nov 9, 2020 at 6:48 PM Matt Sinclair via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
>>>> Hi Gabe,
>>>>
>>>> I don't have the broken build in front of me, and it's possible it is
>>>> because I'm running on an Ubuntu 16 machine, but I had to add c+11 per the
>>>> error message I got when debugging this.  If c++14 works though, great.
>>>>
>>>> Thanks for the updated info -- I built the tutorial out of the old one,
>>>> so next time I'll make sure to update it accordingly.
>>>>
>>>> Thanks,
>>>> Matt
>>>>
>>>> On Mon, Nov 9, 2020 at 5:44 PM Gabe Black via gem5-users <
>>>> gem5-users@gem5.org> wrote:
>>>>
>>>>> BTW, I do think I need to explicitly set the c++ version in the scons
>>>>> file, like in Matt's original email above. I'd probably set it to c++14
>>>>> though, to be consistent with gem5 proper. I think that will likely fix a
>>>>> build issue Bobby had with an older (7.x I think) version of gcc, where 
>>>>> the
>>>>> default version is probably different from the compiler I'm using (10.x I
>>>>> think).
>>>>>
>>>>> Gabe
>>>>>
>>>>> On Mon, Nov 9, 2020 at 1:50 PM Gabe Black 
>>>>> wrote:
>>>>>
>>>>>> Hi folks. If you're using the magic address based version of the gem5
>>>>>> ops, then you should call, for instance, m5_exit_addr and not just 
>>>>>> m5_exit.
>>>>>> The "normal" functions are now always the magic instructions which
>>>>>> essentially only gem5 CPU models know how to execute. All call mechanisms
>>>>>> are built into the library at once now so you can use the same binary on
>>>>>> the KVM CPU, native gem5 CPUs, etc.
>>>>>>
>>>>>> You also should not change the scons files when you build. The old
>>>>>> Makefile based setup required tinkering with things to get the build you
>>>>>> wanted, but that is no longer necessary. If you need to, that's a bug and
>>>>>> we should look into it. The lines you're commenting out just set the
>>>>>> default magic address, and that's only there for legacy reasons. You can
>>>>>> set the address to use from the command line if you're using the m5
>>>>>> utility, or by setting the m5op_addr variable if using the library. You
>>>>>> still have to run map_m5_mem to make the magic physical address visible 
>>>>>> to
>>>>>> userspace for the library to work, or otherwise set up a virtual to
>>>>>> physical mapping if you were, for instance, running in the kernel which
>>>>>> somebody was doing recently.
>>>>>>
>>>>>> If you try to use a call mechanism that isn't supported by your CPU
>>>>>> model, then the behavior will be unpredictable. For x86 on the KVM CPU 
>>>>>> for
>>>>>> example, the special gem5 instructions will do whatever they look like 
>>>>>> they
>>>>>> should do on real hardware. That may be a nop, it may be to generate an
>>>>>> undefined instruction exception, etc. If it's a nop, it will just leave
>>>>>> whatever is in RAX in RAX.
>>>>>>
>>>>>> Also, argument values and return values are now handled by a layer
>>>>>> which knows and applies the actual ABI rules for a given ISA and for the
>>>>>> specific types of the arguments and return value. There should be no 
>>>>>> reason
>>>>>> to change the code which is calling the pseudo instruction to explicitly
>>>>>> set RAX, especially if you're using the address based calling mechanism
>>>>>> which doesn't go through that path at all.
>>>>>>
>>>>>> Gabe
>>>>>>
>>>>>> On Mon, Nov 9, 2020 at 1:06 PM Matt Sinclair via gem5-users <
>>>>>> gem5-users@gem5.org> wrote:
>>>>>>
>>>>>>> Hi Dan,
>>>>>>>
>>>>>>> My comment was just a general comment on the m5ops -- I thought you
>>>>>>> were using the "old" format for building m5ops and that might have been 
&

[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0

[Gabe Black via gem5-users]

Using the m5 library in SE mode is somewhat uncharted waters. You'd need
the access to /dev/mem to be captured and to map memory in the simulation
and not on the host, or Very Bad Things might happen to your host computer.
If the functions are defined in the header but you can't use them, you
should make sure you're actually getting the right header and not some
other, older version. The code which implements the ABI for address based
m5 ops in x86 is in src/arch/x86/tlb.cc in finalizePhysical, where it sets
the "local accessor" for the request, aka a callback which handles an
access which conceptually does not go out into the memory system and is
instead handled inside the CPU. The default, instruction based mechanism
will *not* work on a KVM based CPU (if that's what you're using), and so no
pseudo inst code of any kind will be invoked. If you're actually triggering
the address based mechanism but you're not using a virtual address which
maps to the correct physical address (the physical address is what's
special), then no pseudo inst code will be triggered then either. Basically
if you don't do the right dance to get gem5's attention, then it won't know
you're trying to do a pseudo instruction and will do something else
instead. Unfortunately exactly what gets through from whatever the CPU
model is to get gem5's attention varies (necessarily) based on how the CPU
is implemented, which is why there are all these different calling
mechanisms, and some attempt to organize them more systematically in the
utility.

Gabe

On Mon, Nov 9, 2020 at 4:40 PM Daniel Gerzhoy 
wrote:

> Hi Gabe,
>
> I can see where the register should be stored (line 59 in
> pseudo_inst_abi.hh) but I put a print there and it never gets called for
> the calls that I am making at least.
>
> When i try to use m5_exit_addr and other functions with that suffix I get
> a "error: 'm5_exit_addr' was not declared in this scope"
> Which makes sense because m5ops.h doesn't declare the functions, I can see
> they are built by macro though.
>
> I've also tried to run map_m5_mem() but I get the "Can't open /dev/mem"
> error message.
>
> Could you point me to, or could you quickly throw together an example
> 'hello-world' type program and build process for SE mode?
>
> Thanks,
>
> Dan
>
>
>
>
> On Mon, Nov 9, 2020 at 6:48 PM Matt Sinclair via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi Gabe,
>>
>> I don't have the broken build in front of me, and it's possible it is
>> because I'm running on an Ubuntu 16 machine, but I had to add c+11 per the
>> error message I got when debugging this.  If c++14 works though, great.
>>
>> Thanks for the updated info -- I built the tutorial out of the old one,
>> so next time I'll make sure to update it accordingly.
>>
>> Thanks,
>> Matt
>>
>> On Mon, Nov 9, 2020 at 5:44 PM Gabe Black via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> BTW, I do think I need to explicitly set the c++ version in the scons
>>> file, like in Matt's original email above. I'd probably set it to c++14
>>> though, to be consistent with gem5 proper. I think that will likely fix a
>>> build issue Bobby had with an older (7.x I think) version of gcc, where the
>>> default version is probably different from the compiler I'm using (10.x I
>>> think).
>>>
>>> Gabe
>>>
>>> On Mon, Nov 9, 2020 at 1:50 PM Gabe Black  wrote:
>>>
>>>> Hi folks. If you're using the magic address based version of the gem5
>>>> ops, then you should call, for instance, m5_exit_addr and not just m5_exit.
>>>> The "normal" functions are now always the magic instructions which
>>>> essentially only gem5 CPU models know how to execute. All call mechanisms
>>>> are built into the library at once now so you can use the same binary on
>>>> the KVM CPU, native gem5 CPUs, etc.
>>>>
>>>> You also should not change the scons files when you build. The old
>>>> Makefile based setup required tinkering with things to get the build you
>>>> wanted, but that is no longer necessary. If you need to, that's a bug and
>>>> we should look into it. The lines you're commenting out just set the
>>>> default magic address, and that's only there for legacy reasons. You can
>>>> set the address to use from the command line if you're using the m5
>>>> utility, or by setting the m5op_addr variable if using the library. You
>>>> still have to run map_m5_mem to make the magic physical address visible to
>>>> userspace for the library to work, or otherwise set up a virtual to
>>>&

[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0

[Gabe Black via gem5-users]

BTW, I do think I need to explicitly set the c++ version in the scons file,
like in Matt's original email above. I'd probably set it to c++14 though,
to be consistent with gem5 proper. I think that will likely fix a build
issue Bobby had with an older (7.x I think) version of gcc, where the
default version is probably different from the compiler I'm using (10.x I
think).

Gabe

On Mon, Nov 9, 2020 at 1:50 PM Gabe Black  wrote:

> Hi folks. If you're using the magic address based version of the gem5 ops,
> then you should call, for instance, m5_exit_addr and not just m5_exit. The
> "normal" functions are now always the magic instructions which essentially
> only gem5 CPU models know how to execute. All call mechanisms are built
> into the library at once now so you can use the same binary on the KVM CPU,
> native gem5 CPUs, etc.
>
> You also should not change the scons files when you build. The old
> Makefile based setup required tinkering with things to get the build you
> wanted, but that is no longer necessary. If you need to, that's a bug and
> we should look into it. The lines you're commenting out just set the
> default magic address, and that's only there for legacy reasons. You can
> set the address to use from the command line if you're using the m5
> utility, or by setting the m5op_addr variable if using the library. You
> still have to run map_m5_mem to make the magic physical address visible to
> userspace for the library to work, or otherwise set up a virtual to
> physical mapping if you were, for instance, running in the kernel which
> somebody was doing recently.
>
> If you try to use a call mechanism that isn't supported by your CPU model,
> then the behavior will be unpredictable. For x86 on the KVM CPU for
> example, the special gem5 instructions will do whatever they look like they
> should do on real hardware. That may be a nop, it may be to generate an
> undefined instruction exception, etc. If it's a nop, it will just leave
> whatever is in RAX in RAX.
>
> Also, argument values and return values are now handled by a layer which
> knows and applies the actual ABI rules for a given ISA and for the specific
> types of the arguments and return value. There should be no reason to
> change the code which is calling the pseudo instruction to explicitly set
> RAX, especially if you're using the address based calling mechanism which
> doesn't go through that path at all.
>
> Gabe
>
> On Mon, Nov 9, 2020 at 1:06 PM Matt Sinclair via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi Dan,
>>
>> My comment was just a general comment on the m5ops -- I thought you were
>> using the "old" format for building m5ops and that might have been the
>> problem.  Sounds like it wasn't.
>>
>> I think pushing a fix to develop and tagging Gabe and Jason as reviewers
>> is probably the right strategy.
>>
>> Thanks,
>> Matt
>>
>> On Mon, Nov 9, 2020 at 2:33 PM Daniel Gerzhoy 
>> wrote:
>>
>>> I found the issue and fixed it.
>>>
>>> The return value wasn't being put into the Rax register in
>>> src/arch/x86/isa/decoder/two_byte_opcodes.isa
>>>
>>> 0x4: BasicOperate::gem5Op({{
>>> uint64_t ret;
>>> bool recognized =
>>> PseudoInst::pseudoInst(
>>> xc->tcBase(), IMMEDIATE, ret);
>>> if (!recognized)
>>> fault = std::make_shared();
>>> Rax = ret;
>>>
>>> //<<>> }}, IsNonSpeculative);
>>>
>>>   This code was simplified with the new abi stuff and the Rax = ret;
>>> must have been lost in the shuffle.
>>>
>>> I could push the fix to develop, or should I just make an issue on Jira?
>>>
>>> Best,
>>>
>>> Dan
>>>
>>> On Mon, Nov 9, 2020 at 2:50 PM Daniel Gerzhoy 
>>> wrote:
>>>
 Let me further say that I know that the magic instructions are being
 called. I am just getting bogus return values.

 On Mon, Nov 9, 2020 at 2:18 PM Daniel Gerzhoy 
 wrote:

> Hi Matt,
>
> Thanks for this, it's very helpful. However after following the
> instructions (I had to extrapolate a little because of the directory
> structure changes you mentioned) I get the same result: Nill returns from
> the magic instructions.
> Actually It isn't nill, but a constant no matter what. If I compile my
> program with -O0 its nill, if with -O2 its: 4198192, which is suspicious.
>
> To clarify, are these updated instructions specifically meant to fix
> this issue I am running into? Or just general instructions to build m5op.o
>
> Here are the specific changes I made according to the link you
> provided, the supplemental instructions, and extrapolating based on the
> directory structure change.
>
> 1. In SConsopts I commented both:
>
> --- a/util/m5/src/abi/x86/SConsopts
> +++ b/util/m5/src/abi/x86/SConsopts
> @@ -27,8 +27,8 @@ Import('*')
>
>  env['ABI'] = 'x86'
>  

[gem5-users] Re: How to create a multicore system with different frequency for each core?

[Gabe Black via gem5-users]

If you want the frequency of the CPUs to change independently from each
other, I think you need to set up a ClockDomain object for each, instead of
letting them implicitly inherit the one from the System object.

On Mon, Nov 9, 2020 at 2:26 AM Đức Anh via gem5-users 
wrote:

> Hello all,
>
> I am looking for a way to create a system with multi CPU and they have
> different frequencies. As far as I see there is a system.clk_domain that
> acts as a global frequency, and it seems like all CPUs will follow this
> clock frequency. The clock domain does receive a list of frequencies
> though, but it is for DVFS (Dynamic voltage and frequency scaling). Is
> there a way to create or mimic a system where CPUs have different
> frequencies?
>
> Best regards,
> Duc Anh
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: --Script parameter cannot be used

[Gabe Black via gem5-users]

The --script option works by setting up a file for the m5 utility to read
in from the actual on disk init script found in the disk image. If the m5
utility isn't called, or is called incorrectly, or the script it extracts
isn't then run, the --script option won't work.

It's been a while, but I think the m5 utility command you want is "m5
readfile".

Gabe

On Sun, Nov 8, 2020 at 10:55 PM -17 via gem5-users 
wrote:

> Hi all:
> I try to use the “-- script ”parameter when running gem5 FS mode. I start
> gem5 as follows:
> /build/ARM/gem5.opt -d fs_results/rcstest configs/example/fs.py
> --cpu-type=AtomicSimpleCPU -n 1
> --disk-image=/home/fusiqing/gem5-20.1/2017sys/full_system_images/disks/gem5_ubuntu16.img
>
> --kernel=/home/fusiqing/gem5-20.1/2017sys/full_system_images/binaries/vmlinux
>
> --script=/home/gem5-20.1/configs/boot/halt.sh
> I started the simulation, but the script didn't run.The same goes for
> other files under /example/boot/.
> But in /config.ini I can see:
> readfile=/home/gem5-20.1/configs/boot/halt.sh
> May I ask what error occurred when I used the script?
> Thanks in advance.
>
>
> --
> /**/
> NUDTSiqing Fu
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0

[Gabe Black via gem5-users]

Hi folks. If you're using the magic address based version of the gem5 ops,
then you should call, for instance, m5_exit_addr and not just m5_exit. The
"normal" functions are now always the magic instructions which essentially
only gem5 CPU models know how to execute. All call mechanisms are built
into the library at once now so you can use the same binary on the KVM CPU,
native gem5 CPUs, etc.

You also should not change the scons files when you build. The old Makefile
based setup required tinkering with things to get the build you wanted, but
that is no longer necessary. If you need to, that's a bug and we should
look into it. The lines you're commenting out just set the default magic
address, and that's only there for legacy reasons. You can set the address
to use from the command line if you're using the m5 utility, or by setting
the m5op_addr variable if using the library. You still have to run
map_m5_mem to make the magic physical address visible to userspace for the
library to work, or otherwise set up a virtual to physical mapping if you
were, for instance, running in the kernel which somebody was doing recently.

If you try to use a call mechanism that isn't supported by your CPU model,
then the behavior will be unpredictable. For x86 on the KVM CPU for
example, the special gem5 instructions will do whatever they look like they
should do on real hardware. That may be a nop, it may be to generate an
undefined instruction exception, etc. If it's a nop, it will just leave
whatever is in RAX in RAX.

Also, argument values and return values are now handled by a layer which
knows and applies the actual ABI rules for a given ISA and for the specific
types of the arguments and return value. There should be no reason to
change the code which is calling the pseudo instruction to explicitly set
RAX, especially if you're using the address based calling mechanism which
doesn't go through that path at all.

Gabe

On Mon, Nov 9, 2020 at 1:06 PM Matt Sinclair via gem5-users <
gem5-users@gem5.org> wrote:

> Hi Dan,
>
> My comment was just a general comment on the m5ops -- I thought you were
> using the "old" format for building m5ops and that might have been the
> problem.  Sounds like it wasn't.
>
> I think pushing a fix to develop and tagging Gabe and Jason as reviewers
> is probably the right strategy.
>
> Thanks,
> Matt
>
> On Mon, Nov 9, 2020 at 2:33 PM Daniel Gerzhoy 
> wrote:
>
>> I found the issue and fixed it.
>>
>> The return value wasn't being put into the Rax register in
>> src/arch/x86/isa/decoder/two_byte_opcodes.isa
>>
>> 0x4: BasicOperate::gem5Op({{
>> uint64_t ret;
>> bool recognized =
>> PseudoInst::pseudoInst(
>> xc->tcBase(), IMMEDIATE, ret);
>> if (!recognized)
>> fault = std::make_shared();
>> Rax = ret;
>>
>> //<<> }}, IsNonSpeculative);
>>
>>   This code was simplified with the new abi stuff and the Rax = ret; must
>> have been lost in the shuffle.
>>
>> I could push the fix to develop, or should I just make an issue on Jira?
>>
>> Best,
>>
>> Dan
>>
>> On Mon, Nov 9, 2020 at 2:50 PM Daniel Gerzhoy 
>> wrote:
>>
>>> Let me further say that I know that the magic instructions are being
>>> called. I am just getting bogus return values.
>>>
>>> On Mon, Nov 9, 2020 at 2:18 PM Daniel Gerzhoy 
>>> wrote:
>>>
 Hi Matt,

 Thanks for this, it's very helpful. However after following the
 instructions (I had to extrapolate a little because of the directory
 structure changes you mentioned) I get the same result: Nill returns from
 the magic instructions.
 Actually It isn't nill, but a constant no matter what. If I compile my
 program with -O0 its nill, if with -O2 its: 4198192, which is suspicious.

 To clarify, are these updated instructions specifically meant to fix
 this issue I am running into? Or just general instructions to build m5op.o

 Here are the specific changes I made according to the link you
 provided, the supplemental instructions, and extrapolating based on the
 directory structure change.

 1. In SConsopts I commented both:

 --- a/util/m5/src/abi/x86/SConsopts
 +++ b/util/m5/src/abi/x86/SConsopts
 @@ -27,8 +27,8 @@ Import('*')

  env['ABI'] = 'x86'
  get_abi_opt('CROSS_COMPILE', '')
 -env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
 -env.Append(CCFLAGS='-DM5OP_ADDR=0x')
 +#env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
 +#env.Append(CCFLAGS='-DM5OP_ADDR=0x')

  env['CALL_TYPE']['inst'].impl('m5op.S', 'verify_inst.cc')
  env['CALL_TYPE']['addr'].impl('m5op_addr.S', default=True)

 2. In SConstruct I added:

 --- a/util/m5/SConstruct
 +++ b/util/m5/SConstruct
 @@ -44,7 +44,9 @@ def abspath(d):

  # Universal settings.
  main.Append(CXXFLAGS=[ 

[gem5-users] Re: Ethernet support for ARM FS simulation

[Gabe Black via gem5-users]

The way create methods and constructors were set up was standardized and
largely automated recently. If you're backporting a change across when that
happened, you're going to have to adjust those so they work with the old,
less consistent versions, but it should be very straightforward (turning
references into pointers mostly).

Gabe

On Fri, Nov 6, 2020 at 2:53 AM Liyichao  wrote:

> Hi Gabe:
>
> I use your patch to fix my GEM5 20.0.0.3, but somethins wrong in
> compilation:
>
>
>
>
>
> [SO PARAM] EtherDevBase -> ARM/params/EtherDevBase.hh
>
> [ CXX] ARM/dev/virtio/pci.cc -> .o
>
> [SO PARAM] EtherDevice -> ARM/params/EtherDevice.hh
>
> [SO PARAM] EtherTap -> ARM/params/EtherTap.hh
>
> [SO PARAM] EtherTapStub -> ARM/params/EtherTapStub.hh
>
> [SO PARAM] DistEtherLink -> ARM/params/DistEtherLink.hh
>
> [SO PARAM] IGbE -> ARM/params/IGbE.hh
>
> [SO PARAM] NSGigE -> ARM/params/NSGigE.hh
>
> [SO PARAM] Sinic -> ARM/params/Sinic.hh
>
> [SO PARAM] IdeController -> ARM/params/IdeController.hh
>
> [SO PARAM] IdeDisk -> ARM/params/IdeDisk.hh
>
> [ENUM STR] ArmPciIntRouting, True -> ARM/enums/ArmPciIntRouting.cc
>
> [ENUM STR] IdeID, True -> ARM/enums/IdeID.cc
>
> [SO PyBind] A9GlobalTimer -> ARM/python/_m5/param_A9GlobalTimer.cc
>
> [SO PyBind] A9SCU -> ARM/python/_m5/param_A9SCU.cc
>
> [SO PyBind] AmbaDmaDevice -> ARM/python/_m5/param_AmbaDmaDevice.cc
>
> [SO PyBind] AmbaFake -> ARM/python/_m5/param_AmbaFake.cc
>
> [SO PyBind] AmbaIntDevice -> ARM/python/_m5/param_AmbaIntDevice.cc
>
> [SO PyBind] AmbaPioDevice -> ARM/python/_m5/param_AmbaPioDevice.cc
>
> [SO PyBind] CopyEngine -> ARM/python/_m5/param_CopyEngine.cc
>
> [SO PyBind] CpuLocalTimer -> ARM/python/_m5/param_CpuLocalTimer.cc
>
> *In file included from build/ARM/dev/virtio/pci.hh:43:0,*
>
> * from build/ARM/dev/virtio/pci.cc:38:*
>
> *build/ARM/dev/pci/device.hh: In constructor 'PciBar::PciBar(const
> PciBarParams&)':*
>
> *build/ARM/dev/pci/device.hh:74:48: error: no matching function for call
> to 'SimObject::SimObject(const PciBarParams&)'*
>
> * PciBar(const PciBarParams ) : SimObject(p) {}*
>
> *^*
>
> *In file included from build/ARM/dev/virtio/base.hh:46:0,*
>
> * from build/ARM/dev/virtio/pci.hh:42,*
>
> * from build/ARM/dev/virtio/pci.cc:38:*
>
> *build/ARM/sim/sim_object.hh:120:5: note: candidate:
> SimObject::SimObject(const Params*)*
>
> * SimObject(const Params *_params);*
>
> * ^*
>
> *build/ARM/sim/sim_object.hh:120:5: note:   no known conversion for
> argument 1 from 'const PciBarParams' to 'const Params* {aka const
> SimObjectParams*}'*
>
> [SO PyBind] DistEtherLink -> ARM/python/_m5/param_DistEtherLink.cc
>
> [SO PyBind] EtherBus -> ARM/python/_m5/param_EtherBus.cc
>
> [SO PyBind] EtherDevBase -> ARM/python/_m5/param_EtherDevBase.cc
>
> [SO PyBind] EtherDevice -> ARM/python/_m5/param_EtherDevice.cc
>
> [SO PyBind] EtherDump -> ARM/python/_m5/param_EtherDump.cc
>
> [SO PyBind] EtherLink -> ARM/python/_m5/param_EtherLink.cc
>
> [SO PyBind] EtherSwitch -> ARM/python/_m5/param_EtherSwitch.cc
>
> [SO PyBind] EtherTap -> ARM/python/_m5/param_EtherTap.cc
>
> [SO PyBind] EtherTapBase -> ARM/python/_m5/param_EtherTapBase.cc
>
> [SO PyBind] EtherTapStub -> ARM/python/_m5/param_EtherTapStub.cc
>
> [SO PyBind] FVPBasePwrCtrl -> ARM/python/_m5/param_FVPBasePwrCtrl.cc
>
> [SO PyBind] GenericArmPciHost -> ARM/python/_m5/param_GenericArmPciHost.cc
>
> [SO PyBind] HDLcd -> ARM/python/_m5/param_HDLcd.cc
>
> [SO PyBind] IGbE -> ARM/python/_m5/param_IGbE.cc
>
> [SO PyBind] IdeController -> ARM/python/_m5/param_IdeController.cc
>
> [SO PyBind] IdeDisk -> ARM/python/_m5/param_IdeDisk.cc
>
> [SO PyBind] NSGigE -> ARM/python/_m5/param_NSGigE.cc
>
> scons: *** [build/ARM/dev/virtio/pci.o] Error 1
>
> scons: building terminated because of errors.
>
> *** Summary of Warnings ***
>
> Warning: Your compiler doesn't support incremental linking and lto at the
> same time, so lto is being disabled. To force lto on anyway, use the
> --force-lto option. That will
>
>  disable partial linking.
>
> Warning: While checking protoc version: [Errno 2] No such file or directory
>
> root@ubuntu-kunpeng920-1:/home/l00515693/gem5_repo/gem5# vim
> build/ARM/dev/pci/device.hh
>
> root@ubuntu-kunpeng920-1:/home/l00515693/gem5_repo/gem5# vim
> build/ARM/dev/pci/device.hh
>
>
>
>
>
>
> --
>
> 李翼超（Charlie）
>
>
>
> 华为技术有限公司 Huawei Technologies Co., Ltd.
>
> [image: Company_logo]
>
> 部门：计算系统与组件开发部 [云与计算BG]
>
> 手 机：15858232899
> 电子邮件：liyic...@huawei.com
>
> 地址：中国(China)-杭州(Hangzhou)-滨江区江淑路360号华为杭州研发中心Z4# [3-A06]
> --
>
>  本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any 

[gem5-users] Re: Ethernet support for ARM FS simulation

[Gabe Black via gem5-users]

That sounds like the problem I fixed with this CL:

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

Gabe

On Thu, Nov 5, 2020 at 4:42 AM Liyichao via gem5-users 
wrote:

> Hi Gabe:
>
>  I have looked at the email below, I also has the same question.
> As you mentioned, I just modified the FSConfig.py in function makeArmSystem
> with
>
> “self.ethernet = IGbE_e1000(pci_bus=0, pci_dev=0, pci_func=0,
>
>InterruptLine=1, InterruptPin=1)
>
> pci_devices.append(self.ethernet)” without any modifications in src/***
>
>
>
>  and use the latest img and kernel from GEM5 WEBSITE, but when I
> use fs.py to bootup , there is a fatal print “fatal: Unable to find
> destination for [0x4008:0x400c] on system.iobus”.
>
>
>
>
>
>
>
> My cmd is:
> ./build/ARM/gem5.opt
> --debug-flags=AddrRanges,NoncoherentXBar,DMA,EthernetEEPROM,Ethernet
> configs/example/fs.py  --cpu-type=ArmV8KvmCPU --kernel=vmlinux -n 1
> --machine-type=VExpress_GEM5_V1
> --disk-image=expanded-aarch64-ubuntu-trusty-headless.img
> --cpu-clock=2.6GHz  --mem-type=DDR4_2933_16x4_new --mem-size=8GB
>
>
>
>
>
> My GEM5 VERSION is 20.0.0.3
>
>
>
>
>
>
>
>
>
>
>
>
>
> You shouldn't modify your config by changing anything in src/, you should
>
> do that in the config scripts. If you want to add additional devices, they
>
> don't have to be part of the platform object, they just need to be
>
> connected to the right busses, etc.
>
>
>
> Gabe
>
>
>
> On Fri, Aug 28, 2020 at 12:06 PM HENG ZHUO via gem5-users <
>
> gem5-users@gem5.org> wrote:
>
>
>
> > Hi all,
>
> >
>
> > I noticed with the recent updates in ARM ISA support, now default machine
>
> > setup is using VExpress_GEM5_V1, which is great, with the 2019 build
> kernel
>
> > and boot loadert tested and everything. However, I also know that
>
> > VExpress_GEM5 does not support ethernet device. What would be best setup
> if
>
> > I want to use ethernet device, but with newer built kernel setup?
>
> >
>
> > 1) Shall I add ethernet device to VExpress_GEM5 machine config? This
>
> > should be most ideal case, in terms of simulated system. Assuming I can
> add
>
> > a new device in the src/dev/arm/RealView.py under VExpress_GEM5_V1. But,
>
> > the dtb is auto generated, seems like I also need to add entry in the
>
> > auto-generated device tree, anyone has any directions on how to add new
>
> > devices in this scenario?
>
> >
>
> > 2) Can I use the old VExpress_EMM64 machine, but with newer build 2019
>
> > kernel and boatload, my guess is not, I would assume the kernel is
>
> > customized based on the machine VExpress_GEM5.
>
> >
>
> > 3) Stick with using older build (2018 build kernel and bootloader), with
>
> > machine VExpress_EMM64. This should be working by default, but losing the
>
> > ability to use more updated kernel and machine config.
>
> >
>
> > Any suggestions, insights would be appreciated!
>
> >
>
> > Best,
>
> > Heng
>
> > ___
>
> > gem5-users mailing list -- gem5-users@gem5.org
>
> > To unsubscribe send an email to gem5-users-le...@gem5.org
>
> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> >
>
> ___
>
>
> --
>
> 李翼超（Charlie）
>
>
>
> 华为技术有限公司 Huawei Technologies Co., Ltd.
>
> [image: Company_logo]
>
> 部门：计算系统与组件开发部 [云与计算BG]
>
> 手 机：15858232899
> 电子邮件：liyic...@huawei.com
>
> 地址：中国(China)-杭州(Hangzhou)-滨江区江淑路360号华为杭州研发中心Z4# [3-A06]
> --
>
>  本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
>
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s