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
