> set architecture arm That shouldn't be necessary. When you do "target remote", gem5 sends an XML "features descriptor" to GDB; this contains detailed information about the architecture (because just saying "arm" is not enough). One thing I would try, is do
target remote localhost:7000 show arch to see whether what GDB thinks, matches the correct architecture you have. > Invalid breakpoint length Usually when I see this warning, I sniff the Z packet by passing --debug-flags=GDBSend,GDBRecv to gem5 (using Wireshark is fun, too), to see exactly what "kind" it is (2 or 4). Btw, maybe your GDB is confused between Thumb and Arm? > when I modify something (some byte) in the code That should work; and yes, the addresses you see in GDB are the same as what the debugee sees. Something more suspicious is happening here: > accessing virtual address 0 So your modified arm_test is dereferencing a null pointer. If you pass --debug-flags=Exec to gem5 you will see exactly what instructions are being executed and which instruction is blowing up. -----"husin alhaj ahmade via gem5-users" <[email protected]> wrote: ----- To: "gem5 users mailing list" <[email protected]> From: "husin alhaj ahmade via gem5-users" <[email protected]> Date: 01/30/2021 03:11AM Cc: "husin alhaj ahmade" <[email protected]> Subject: [gem5-users] Remote GDB/cross GDB I need to debug a program that is being run on Gem5 (NOT TO DEBUG GEM5 ITSELF). For this goal, I was forced to use gdb remote. The code I want to debug was compiled using arm-linux cross compiler. In my host machine I installed all cross-tools required (gcc, g++ and gdb) to work with the ARM simulated machine in Gem5. From the host machine I started the gdb and typed the following commands: gdb-multiarch file arm_test // a sample code compiled using arm-gcc cross compiler set architecture arm set b main target remote localhost:7000 c when I hit enter after typing c (cont) the program at Gem5 does not stop at main (as I set a breakpoint there) and it finishes its work, prints hello world and exits. At the Gem5 I saw a warn message says: warn: Invalid breakpoint length Strictly speaking, I think there is no harmony between the gdb running on my host and the program being executed on Gem5. Another thing... Is the memory address offset for the code being debugged at host machine differ from the one being executed at gem5? assume I want to modify the content of the code (binary instrumentation using gdb trap)... when I modify something (some byte) in the code and then type (cont) I get an error at gem5 (even I rewrite the same byte) panic: panic condition !handled occurred: Page table fault when accessing virtual address 0 Memory Usage: 703788 KBytes Program aborted at tick 4262000 --- BEGIN LIBC BACKTRACE --- ./build/ARM/gem5.opt(_Z15print_backtracev+0x2c)[0x55d827ea2d4c] ./build/ARM/gem5.opt(_Z12abortHandleri+0x4a)[0x55d827eb54ba] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fc89f802980] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7fc89e010fb7] /lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7fc89e012921] ./build/ARM/gem5.opt(+0xb5514f)[0x55d82672114f] ./build/ARM/gem5.opt(_ZN21GenericPageTableFault6invokeEP13ThreadContextRK14RefCountingPtrI10StaticInstE+0xc1)[0x55d827ef9831] ./build/ARM/gem5.opt(_ZN13BaseSimpleCPU9advancePCERKSt10shared_ptrI9FaultBaseE+0x173)[0x55d827fd5143] ./build/ARM/gem5.opt(_ZN15AtomicSimpleCPU4tickEv+0x465)[0x55d827fc78b5] ./build/ARM/gem5.opt(_ZN10EventQueue10serviceOneEv+0xa5)[0x55d827eab225] ./build/ARM/gem5.opt(_Z9doSimLoopP10EventQueue+0x87)[0x55d827ecff47] ./build/ARM/gem5.opt(_Z8simulatem+0xcba)[0x55d827ed0f9a] ./build/ARM/gem5.opt(+0x11982d1)[0x55d826d642d1] ./build/ARM/gem5.opt(+0xcfe011)[0x55d8268ca011] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x64d7)[0x7fc89faafc47] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7fc89fbee908] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5bf6)[0x7fc89faaf366] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7fc89fbee908] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5bf6)[0x7fc89faaf366] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7fc89fbee908] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5bf6)[0x7fc89faaf366] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7fc89fbee908] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7fc89faa95d9] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6ac0)[0x7fc89fab0230] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7fc89fbee908] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5bf6)[0x7fc89faaf366] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7fc89fbee908] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7fc89faa95d9] /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyRun_StringFlags+0x76)[0x7fc89fb596f6] ./build/ARM/gem5.opt(_Z6m5MainiPPc+0x83)[0x55d827eb3fb3] ./build/ARM/gem5.opt(main+0x38)[0x55d82669a0b8] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7fc89dff3bf7] --- END LIBC BACKTRACE --- Aborted (core dumped) Any help or suggestions Thanks _______________________________________________ gem5-users mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s _______________________________________________ gem5-users mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
