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
