The reason is that I am working on some standard test cases, and our whole project is current target on 32-bit x86 platform...
I am trying to dig into the full-system mode, thank you for your information ! ________________________________ 发件人: gem5-users <[email protected]> 代表 Arthur Perais <[email protected]> 发送时间: 2016年12月21日 8:05:51 收件人: gem5 users mailing list 主题: Re: [gem5-users] 答复: syscall set_tid_address (#258) unimplemented It is possible m5threads only supports x86_64, so in that case, your only solution is to go take a look at Full Sytem mode (http://gem5.org/Running_gem5#Full_System_.28FS.29_Mode) I am not sure if a 32-bit x86 linux ISO can be retrieved from the website though (look here : http://gem5.org/Download). Is there something forbidding you from targeting x86_64, by the way? Arthur. Le 21/12/2016 à 16:19, ps4 lover a écrit : Hey Arthur, Thank you so much for your reply! I do find the usage of multi-threading utilities in the test code I am working on. I have actually tried to use the m5threads library. However, it seems that I cannot compile it on 32-bit x86 platforms? I can only compile this library on the 64-bit x86 platforms, while on 32-bit platforms, I got a bunch of errors due to the lack of some symbols, I copied them here: gcc -O3 -static -c -o pthread.o pthread.c pthread.c:46:4: error: #error "spinlock routines not available for your arch!\n" #error "spinlock routines not available for your arch!\n" ^ In file included from pthread.c:50:0: tls_defs.h:220:4: error: #error "No TLS defs for your architecture" #error "No TLS defs for your architecture" ^ pthread.c: In function ‘populate_thread_block_info’: pthread.c:69:37: error: ‘tcbhead_t’ undeclared (first use in this function) #define NPTL_TCBHEAD_T_SIZE (sizeof(tcbhead_t)) ^ pthread.c:140:69: note: in expansion of macro ‘NPTL_TCBHEAD_T_SIZE’ size_t sz = sizeof(pthread_tcb_t) + thread_block_info.tls_memsz + NPTL_TCBHEAD_T_SIZE + thread_block_info.stack_guard_size + CHILD_STACK_SIZE; ^ pthread.c:69:37: note: each undeclared identifier is reported only once for each function it appears in #define NPTL_TCBHEAD_T_SIZE (sizeof(tcbhead_t)) ^ pthread.c:140:69: note: in expansion of macro ‘NPTL_TCBHEAD_T_SIZE’ size_t sz = sizeof(pthread_tcb_t) + thread_block_info.tls_memsz + NPTL_TCBHEAD_T_SIZE + thread_block_info.stack_guard_size + CHILD_STACK_SIZE; ^ make: *** [pthread.o] Error 1 At this moment, I do not see anything else I can do for m5threads.. ________________________________ 发件人: gem5-users <[email protected]><mailto:[email protected]> 代表 Arthur Perais <[email protected]><mailto:[email protected]> 发送时间: 2016年12月21日 2:43:14 收件人: gem5 users mailing list 主题: Re: [gem5-users] syscall set_tid_address (#258) unimplemented Hi, You are running in system emulation mode (se.py), meaning that all calls to OS are emulated by gem5, and in particular, set_tid_address does not seem to be implemented. By any chance, is your code multithreaded? As is, system emulation does not support multithreaded code, so this might be one reason. Another thinkg is that I'm not sure dynamic linking works with system emulation (I remember a patch allowing it but I don't know if it is in the mainline yet). If not, make sure your executable is statically linked. So, to fix your problem, either: 1) Implement set_tid_address (I would not know where to look myself). 2) If the error comes from your code being multithreaded and 2.1) You need multithreading, look for m5threads or run in full system mode (gem5 will boot Linux and run your executable under a full OS). There should be some examples in the wiki. 2.2) You don't need it, then remove it. Good luck, Arthur. Le 20/12/2016 à 23:07, ps4 lover a écrit : Dear List, I have been using gem5 to study the cache access on several C programs, and it works well! Now I am switching to one C++ test case, and when I employ one sample config to test this binary code: ./build/X86/gem5.opt configs/example/se.py -c /data/sample_cpp_bin I got the following error: gem5 Simulator System. http://gem5.org gem5 is copyrighted software; use the --copyright option for details. gem5 compiled Dec 19 2016 14:07:53 gem5 started Dec 20 2016 16:58:17 gem5 executing on lrs-dwu01, pid 25039 command line: ./build/X86/gem5.opt configs/example/se.py -c /data/sample_cpp_bin Global frequency set at 1000000000000 ticks per second warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (512 Mbytes) 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 warn: ClockedObject: More than one power state change request encountered within the same simulation tick **** REAL SIMULATION **** info: Entering event queue @ 0. Starting simulation... fatal: syscall set_tid_address (#258) unimplemented. @ tick 1286000 [unimplementedFunc:build/X86/sim/syscall_emul.cc, line 95] Memory Usage: 639384 KBytes Program aborted at tick 1286000 --- BEGIN LIBC BACKTRACE --- ./build/X86/gem5.opt(_Z15print_backtracev+0x15)[0x8ccc05] ./build/X86/gem5.opt(_Z12abortHandleri+0x36)[0x8de586] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7fd804d69cb0] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7fd803334035] /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7fd80333779b] ./build/X86/gem5.opt(_Z15__exit_epilogueiPKcS0_iS0_+0x1ec)[0x92cdec] ./build/X86/gem5.opt(_Z17unimplementedFuncP11SyscallDesciP11LiveProcessP13ThreadContext+0x86)[0x915cb6] ./build/X86/gem5.opt(_ZN11SyscallDesc9doSyscallEiP11LiveProcessP13ThreadContext+0x8a)[0x91629a] ./build/X86/gem5.opt(_ZN11LiveProcess7syscallElP13ThreadContext+0x4c)[0x90c10c] ./build/X86/gem5.opt(_ZN6X86ISA15I386LiveProcess7syscallElP13ThreadContext+0x4e)[0x8b7dae] ./build/X86/gem5.opt(_ZNK10X86ISAInst8Sysenter7executeEP11ExecContextPN5Trace10InstRecordE+0x35)[0x14c0e05] ./build/X86/gem5.opt(_ZN15AtomicSimpleCPU4tickEv+0x22d)[0xa2f83d] ./build/X86/gem5.opt(_ZN10EventQueue10serviceOneEv+0xb1)[0x8d6831] ./build/X86/gem5.opt(_Z9doSimLoopP10EventQueue+0x38)[0x8f75c8] ./build/X86/gem5.opt(_Z8simulatem+0x1fb)[0x8f7b4b] ./build/X86/gem5.opt[0x98cb4c] /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4f18)[0x7fd8048f9188] /usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855)[0x7fd8048b96b5] /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5420)[0x7fd8048f9690] /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x614b)[0x7fd8048fa3bb] /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x614b)[0x7fd8048fa3bb] /usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855)[0x7fd8048b96b5] /usr/lib/libpython2.7.so.1.0(PyEval_EvalCode+0x32)[0x7fd8048b99e2] /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x515f)[0x7fd8048f93cf] /usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855)[0x7fd8048b96b5] /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5420)[0x7fd8048f9690] /usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855)[0x7fd8048b96b5] /usr/lib/libpython2.7.so.1.0(PyEval_EvalCode+0x32)[0x7fd8048b99e2] /usr/lib/libpython2.7.so.1.0(PyRun_StringFlags+0x8c)[0x7fd8048b9a7c] ./build/X86/gem5.opt(_Z6m5MainiPPc+0x7f)[0x8dddff] ./build/X86/gem5.opt(main+0x33)[0x70e2b3] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fd80331f7ed] --- END LIBC BACKTRACE --- [1] 25039 abort (core dumped) ./build/X86/gem5.opt configs/example/se.py -c It seems to me that system call set_tid_address is not supported. Actually for the C++ test case I am working on, the set_tid_address will be invoked before main function, seems to support some standard initialization procedures: strace /data/sample_cpp_bin execve("/data/sample_cpp_bin", ["/data/bot"...], [/* 29 vars */]) = 0 [ Process PID=26743 runs in 32 bit mode. ] uname({sys="Linux", node="test01", ...}) = 0 brk(0) = 0x9ce9000 brk(0x9ce9d40) = 0x9ce9d40 set_thread_area(0xfff47360) = 0 set_tid_address(0x9ce98a8) = 26743 set_robust_list(0x9ce98b0, 0xc) = 0 futex(0xfff47450, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 9ce9840) = -1 EAGAIN (Resource temporarily unavailable) rt_sigaction(SIGRTMIN, {0x81cc640, [], SA_SIGINFO}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x81cc6c0, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=-4286578688, rlim_max=-9223372036718672192}) = 0 uname({sys="Linux", node="lrs-dwu01", ...}) = 0 readlink("/proc/self/exe", ""/data/sample_cpp_bin", 4096) = 47 brk(0x9d0ad40) = 0x9d0ad40 brk(0x9d0b000) = 0x9d0b000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) futex(0x8387c14, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x8387c1c, FUTEX_WAKE_PRIVATE, 2147483647) = 0 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 44), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff77bf000 write(1, "Usage: XXXXXXX"..., 86Usage: "/data/test_cpp_bin messagefile) = 86 exit_group(1) = ? So my question is, given my current situation, how should I config gem5 to make my C++ sample testable? Any suggestion would be appreciated, thank you! _______________________________________________ gem5-users mailing list [email protected]<mailto:[email protected]> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users _______________________________________________ gem5-users mailing list [email protected]<mailto:[email protected]> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
