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
