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
