Hi Amin,
The issue is that you're compiling m5op_arm.S as thumb code. It would need some work for that to end up creating the right thing since we encode the instructions with .longs. Ali On 30.04.2012 14:28, Amin Farmahini wrote: > Hi Ali, > > I am using the development copy. > > And here is the gcc I am using: > ../Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin/arm-none-linux-gnueabi-gcc --version > arm-none-linux-gnueabi-gcc (Sourcery CodeBench Lite 2011.09-70) 4.6.1 > > And here is input command to generate the binary using thumb instructions: > arm-none-linux-gnueabi-gcc -march=armv7-a -mthumb -mfpu=vfpv3 -mfloat-abi=softfp -static util/m5/m5op_arm.S -Iutil/m5 hello.c -o hello -Wall > > and here is input command to generate the binary without thumb instruction: > arm-none-linux-gnueabi-gcc -march=armv7-a -mno-thumb -mfpu=vfpv3 -mfloat-abi=softfp -static util/m5/m5op_arm.S -Iutil/m5 hello.c -o hello -Wall > > Let me know if you need more information. I am new to Gem5, so it is possible that I am doing something wrong. > > Thanks, > Amin > > On Mon, Apr 30, 2012 at 1:13 PM, Ali Saidi <[email protected] [12]> wrote: > >> Hi Amin, >> >> Are you using gem5 stable or development? There was a bug that might explain this that was fixed about 5 weeks ago in the development repository. >> >> Thanks, >> >> Ali >> >> On 30.04.2012 07:55, Ali Saidi wrote: >> >>> Hi Amin, >>> I'd really like to know what is going on. It all should work. What version of gcc are you using? >>> Thanks, >>> Ali >>> >>> On Apr 29, 2012, at 11:00 PM, Amin Farmahini wrote: >>> >>>> Ali and Gabe, >>>> >>>> Thanks for your responses. I found out that disabling thumb instructions in gcc (-mno-thumb) fixes this problem. I'll try to dig into this more tomorrow. >>>> >>>> Ali, >>>> >>>> As you mentioned, adding that flag did not help much. I got the panic message of "Page table fault when accessing virtual address." >>>> >>>> Thanks, >>>> Amin >>>> >>>> On Sat, Apr 28, 2012 at 5:14 PM, Gabe Black <[email protected] [7]> wrote: >>>> >>>>> I'd guess it isn't the printf itself that changes things, it's probably that that changes the size of the function, stack frame, etc., and makes the compiler generate different code or use different syscalls or underlying functions. It could also be it changes how/when stdio is buffered. >>>>> >>>>> Gabe >>>>> >>>>> On 04/28/12 08:03, Ali Saidi wrote: >>>>> >>>>>> The error message is printed with hex and the flags are listed with octal, so they're not the same. It's complaining about NOATIME which as it turns out is not in flag translation table in: src/arch/arm/linux/linux.cc >>>>>> You can certainly try to add it, however I'm skeptical that it's going to fix your problem, but maybe it will. >>>>>> You're going to need to use the debug flags (particularly Exec) to figure out what the CPU is doing differently with the addition of the single printf. It shouldn't change anything, but clearly it is. >>>>>> Ali >>>>>> >>>>>> On Apr 27, 2012, at 10:38 PM, Amin Farmahini wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have written a very simple hello world program to run on ARM SE. However, the simulator prints a warning, and the simulation never finishes (Gem5 keeps ticking, but no progress. So I have to manually stop it). Here is the program: >>>>>>> >>>>>>> #include >>>>>>> >>>>>>> #include "m5op.h" >>>>>>> int main() { >>>>>>> printf("Hello Worldn"); >>>>>>> m5_reset_stats(0,0); >>>>>>> printf("Hello Worldn"); >>>>>>> printf("Hello Worldn"); >>>>>>> printf("Hello Worldn"); //IF I COMMENT THIS OUT, THEN IT WORKS FINE >>>>>>> } >>>>>>> >>>>>>> And here is the output: >>>>>>> command line: build/ARM/gem5.opt configs/example/se.py -c hello >>>>>>> Global frequency set at 1000000000000 ticks per second >>>>>>> 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 >>>>>>> **** REAL SIMULATION **** >>>>>>> info: Entering event queue @ 0. Starting simulation... >>>>>>> Hello World >>>>>>> warn: instruction 'cdp' unimplemented >>>>>>> warn: Syscall: OPEN: CANNOT DECODE FLAGS 0X40000 >>>>>>> ^Chack: be nice to actually delete the event here >>>>>>> Exiting @ tick 85824528000 because user interrupt received >>>>>>> >>>>>>> I took a look at arm/linux.linux.hh and it seems like flag 0X40000 corresponds to TGT_O_DIRECT. FYI, hostflags are set to 0x23000 (defined in syscall_emul.hh). >>>>>>> >>>>>>> The weird thing is that if I comment out the last printf("Hello Worldn"); then the whole simulation works just fine. >>>>>>> >>>>>>> Any thoughts what the problem might be? >>>>>>> >>>>>>> Thanks, >>>>>>> Amin >>>>>>> >>>>>>> _______________________________________________ >>>>>>> gem5-users mailing list >>>>>>> [email protected] [1] >>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [2] >>>>>> >>>>>> _______________________________________________ gem5-users mailing list [email protected] [3] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [4] >>>>> >>>>> _______________________________________________ >>>>> gem5-users mailing list >>>>> [email protected] [5] >>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [6] >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> [email protected] [8] >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [9] >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] [10] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [11] Links: ------ [1] mailto:[email protected] [2] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [3] mailto:[email protected] [4] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [5] mailto:[email protected] [6] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [7] mailto:[email protected] [8] mailto:[email protected] [9] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [10] mailto:[email protected] [11] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [12] mailto:[email protected]
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
