If you're using regular magic instruction based calls to the m5 ops, then
that should work fine since you don't have to set up any virtual/physical
mappings for that to work. That also means you can just call the non _addr
version, so no problems there either. The store method will be called by
the generic GuestABI code when the return type matches the partial
specialization, which in this case is any type T. I think I see the
problem, actually. There are two versions of the pseudoInst function, one
which returns the result to the caller, and one which doesn't. The one that
returns it assumes that you don't want to store it also, although you can
tell it to do both. The one that does not return it makes the opposite
assumption. The code in the decoder passes the return value back to the
caller, so that will not automatically store the result. What it should do
is either not call the version that passes back the result (preferred), or
keep calling the current one but tell it to store the result for it anyway.
I'm not sure why I didn't do that to start with, unless it was because one
change passed each other in time while they sat in review. It could have
also just been a mistake?
Gabe
On Mon, Nov 9, 2020 at 6:37 PM Daniel Gerzhoy <daniel.gerz...@gmail.com>
wrote:
> Hmm, I've been using magic instructions in SE mode for years now. Jason
> can you maybe shed some light on this? Have I been getting lucky or is
> there something we are missing?
>
> I'm using TimingSimpleCPU or DerivO3CPU (this is the GPU model, so we're
> more limited).
>
> To be clear, the pseudo-instructions are being called, no problems. I can
> see them executing with the PseudoInst debug flag.
> It's just that the return values don't show up unless I explicitly set Rax
> two_byte_opcodes.isa which is how it used to work.
> (And It is working properly and consistently with Rax set explicitly)
>
> Where is the "store" in pseudo_inst_abi.hh supposed to be called from? We
> could maybe add a check for SE mode and explicitly call it at the end of
> pseudoInstWork() or something?
>
> Cheers,
>
> Dan
>
>
> On Mon, Nov 9, 2020 at 9:20 PM Gabe Black <gabe.bl...@gmail.com> wrote:
>
>> 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 <daniel.gerz...@gmail.com>
>> 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 <gabe.bl...@gmail.com>
>>>>> 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 <
>>>>>>> daniel.gerz...@gmail.com> 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<X86PseudoInstABI>(
>>>>>>>> xc->tcBase(), IMMEDIATE, ret);
>>>>>>>> if (!recognized)
>>>>>>>> fault = std::make_shared<InvalidOpcode>();
>>>>>>>> Rax = ret;
>>>>>>>>
>>>>>>>> //<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<Added This
>>>>>>>> }}, 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 <
>>>>>>>> daniel.gerz...@gmail.com> 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 <
>>>>>>>>> daniel.gerz...@gmail.com> 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=0xFFFF0000')
>>>>>>>>>> -env.Append(CCFLAGS='-DM5OP_ADDR=0xFFFF0000')
>>>>>>>>>> +#env.Append(CXXFLAGS='-DM5OP_ADDR=0xFFFF0000')
>>>>>>>>>> +#env.Append(CCFLAGS='-DM5OP_ADDR=0xFFFF0000')
>>>>>>>>>>
>>>>>>>>>> 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=[ '-O2' ])
>>>>>>>>>> +main.Append(CXXFLAGS=[ '-std=c++11' ])
>>>>>>>>>> main.Append(CCFLAGS=[ '-O2' ])
>>>>>>>>>> main.Append(CPPPATH=[ common_include ])
>>>>>>>>>>
>>>>>>>>>> The compilation process compiles m5op.S with gcc though, so c++11
>>>>>>>>>> doesn't have any effect on it. Not sure if that matters.
>>>>>>>>>>
>>>>>>>>>> 3. Finally I linked both m5_mmap.o and m5op.o as per the
>>>>>>>>>> instructions but I am a little wary of m5_mmap
>>>>>>>>>>
>>>>>>>>>> What does m5_mmap actually do if I don't have M5OP_ADDR defined.
>>>>>>>>>> It looks like nothing? Do I need to link it?
>>>>>>>>>>
>>>>>>>>>> *Is there something inside the program I need to do before
>>>>>>>>>> calling magic instructions that has to do with m5_mmap?*
>>>>>>>>>>
>>>>>>>>>> Thanks for your help,
>>>>>>>>>>
>>>>>>>>>> Dan
>>>>>>>>>>
>>>>>>>>>> On Mon, Nov 9, 2020 at 12:12 PM Matt Sinclair <
>>>>>>>>>> mattdsincl...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Dan,
>>>>>>>>>>>
>>>>>>>>>>> In recent weeks, Gabe (if I recall correctly) updated how the
>>>>>>>>>>> m5ops are created. I had created a homework assignment for my
>>>>>>>>>>> course about
>>>>>>>>>>> it:
>>>>>>>>>>> https://pages.cs.wisc.edu/~sinclair/courses/cs752/fall2020/handouts/hw3.html
>>>>>>>>>>> (see #2), but this is now already out of date as the location of
>>>>>>>>>>> some files
>>>>>>>>>>> changed. The updated instructions are:
>>>>>>>>>>>
>>>>>>>>>>> 1. Update $GEM5_ROOT/util/m5/SConstruct, add a new line between
>>>>>>>>>>> the current lines 46 and 47:
>>>>>>>>>>>
>>>>>>>>>>> main.Append(CXXFLAGS=[ '-O2' ])
>>>>>>>>>>> *+main.Append(CXXFLAGS=[ '-std=c++11' ])*
>>>>>>>>>>>
>>>>>>>>>>> main.Append(CCFLAGS=[ '-O2' ])
>>>>>>>>>>>
>>>>>>>>>>> 2. Now run the same command you ran in step 2 of the above link:
>>>>>>>>>>>
>>>>>>>>>>> scons build/x86/out/m5
>>>>>>>>>>>
>>>>>>>>>>> 3. This will create the same two .o files in step 2 of the
>>>>>>>>>>> above link, in the same places (although the location of m5op.o
>>>>>>>>>>> may have changed to include/gem5 util/m5/build/x86/abi/x86/
>>>>>>>>>>> according to some of the students in my course).
>>>>>>>>>>> Matt
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Nov 9, 2020 at 9:25 AM Daniel Gerzhoy via gem5-users <
>>>>>>>>>>> gem5-users@gem5.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hey all,
>>>>>>>>>>>>
>>>>>>>>>>>> I've recently updated to using the dev branch for my GCN3
>>>>>>>>>>>> simulations. I've noticed that I am now getting return values of 0
>>>>>>>>>>>> for
>>>>>>>>>>>> every magic instruction (m5_rpns for instance).
>>>>>>>>>>>>
>>>>>>>>>>>> Is there a special way I need to be compiling/linking m5ops.S
>>>>>>>>>>>> to get the return values to show up correctly? Or might this be a
>>>>>>>>>>>> bug?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Dan
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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 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
