BRN:Software:Build and Distribution:Userland Debugging: Difference between revisions
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
The remove debugging setup consists of a debugger stub (named gdbserver), which runs on the target machine (mipsel in our case) and is attached to the debuggee process. The debugger resists on a (remove) host machine and is connectet to the stub via a TCP/IP or serial connection. At first we have to build both a debugger stub and a cross-debugger (note that the host debugger which is shipped with the linux distribution could not be used for cross debugging). |
The remove debugging setup consists of a debugger stub (named gdbserver), which runs on the target machine (mipsel in our case) and is attached to the debuggee process. The debugger resists on a (remove) host machine and is connectet to the stub via a TCP/IP or serial connection. At first we have to build both a debugger stub and a cross-debugger (note that the host debugger which is shipped with the linux distribution could not be used for cross debugging). |
||
* Build the gdbserver. It must be configured for host and target mipsel. |
|||
* Build the |
|||
* Build the cross-gdb. Configure it for target mipsel and host i386. |
|||
= Debugging Userland Applications = |
= Debugging Userland Applications = |
||
* At first, start the gdbserver on the mips. You can either specify an executable which is load or attach it to a running process. To debug a process with PID 333 for example, simply type |
|||
wgt30$ gdbserver :2000 --attach 333 |
|||
The debugger stub is now attached to the process with given PID and reachable on TCP port 2000. |
|||
* Start the cross-debugger on the host system and connect it to the stub, e.g. |
|||
(gdb) target remote wgt30:2000 |
|||
It may be the case that the gdb does not find the images of the linked-in shared libraries, since host and target system may differ. As a result, the debugger is not able to exermine the stack correctly and no (of no usefull) backtrace could be generated. You can solve this problem by specifying a shared object lookup prefix using the following command: |
|||
(gdb) set solib-absolute-prefix /wgtroot |
|||
Now you should be able to use the remote debugger in the same was as a local debugger. |
|||
Revision as of 10:11, 27 September 2006
Debug Setup
The remove debugging setup consists of a debugger stub (named gdbserver), which runs on the target machine (mipsel in our case) and is attached to the debuggee process. The debugger resists on a (remove) host machine and is connectet to the stub via a TCP/IP or serial connection. At first we have to build both a debugger stub and a cross-debugger (note that the host debugger which is shipped with the linux distribution could not be used for cross debugging).
- Build the gdbserver. It must be configured for host and target mipsel.
- Build the cross-gdb. Configure it for target mipsel and host i386.
Debugging Userland Applications
- At first, start the gdbserver on the mips. You can either specify an executable which is load or attach it to a running process. To debug a process with PID 333 for example, simply type
wgt30$ gdbserver :2000 --attach 333
The debugger stub is now attached to the process with given PID and reachable on TCP port 2000.
- Start the cross-debugger on the host system and connect it to the stub, e.g.
(gdb) target remote wgt30:2000
It may be the case that the gdb does not find the images of the linked-in shared libraries, since host and target system may differ. As a result, the debugger is not able to exermine the stack correctly and no (of no usefull) backtrace could be generated. You can solve this problem by specifying a shared object lookup prefix using the following command:
(gdb) set solib-absolute-prefix /wgtroot
Now you should be able to use the remote debugger in the same was as a local debugger.