blob: c44b298b57168156b72ec79bfd56c44f81e2688f (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
|
This is a quick'n'dirty HowTo for cross-debugging on your iPAQ/Zaurus:
Requirements:
-------------
1) You need the same binary of the program being debugged on the handheld
and on the desktop machine.
2) The binary for the handheld can be stripped (!!)
3) The binary for the desktop must have been compiled with -g
3) The same applies to shared libraries (but this is only needed if you want
to step into libraries or if you want the backtrace to show the right
function names for libraries)
Setup:
------
1) install the gdbserver.ipk on the handheld.
2) put the arm-linux-gdb binary somewhere in your $PATH (I would suggest
/opt/Embedix/tools/arm-linux/bin)
3) copy the sample.arm-gdbinit to your $HOME directory and rename it to
.arm-gdbinit
4) edit ~/.arm-gdbinit:
"solib-search-path" is the path, where gdb searches for shared libraries
"rtX" are some aliases to speed up debugging -- you can rename them, or
remove them (see below for the "target ... " syntax)
Sample session: debugging the launcher
--------------------------------------
1) Login on the handheld, kill Opie and execute:
# gdbserver foo:2345 /opt/QtPalmtop/bin/qpe
This starts the program qpe in debug mode, and the gdbserver stub now
listens on port 2345 for an incoming connection from the real gdb.
(foo should be name of the desktop machine, but it is ignored)
2) On the desktop, change to the $OPIEDIR containing the arm binaries
# cd $OPIEDIR
# cd core/launcher
# arm-linux-gdb ../../bin/qpe
or
# ddd --debugger arm-linux-gdb ../../bin/qpe
3) You should get an "(arm-gdb)" prompt. Now do
(arm-gdb) target remote zaurus:2345
You have to change zaurus to the hostname or ip-address of your handheld.
This should produce:
Remote debugging using zaurus:2345
0x40002a80 in ?? ()
(arm-gdb) break main
(arm-gdb) cont
And gdb should stop in 'main'. If gdb complains about unknown symbol
'main', you forgot to compile the application in debug mode.
This is where the rtFOO macros come in handy: just type rtX and you are
connected to machine BAR.
4) You can debug/step your application, as you would with a native gdb from
here on.
Please note that single stepping in a cross-debugger can be VERY SLOW
sometimes !!
Robert 'sandman' Griebl, 17.11.2002
|
