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