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

Reply via email to