Ticket #1890 (in_testing defect)
gdb problems (single stepping and debug symbol table)
| Reported by: | h.koenig | Owned by: | openmoko-devel |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | unknown | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Estimated Completion (week): | ||
| HasPatchForReview: | PatchReviewResult: | ||
| Reproducible: |
Description
trying to debug Xglamo I have (at least) two problems with gdb (Om 2008.8 + zecke-dev) :
1)
using instruction stepping (si) doesn't seem to work for
instruction "bxcc lr" -- the program just "continues" in free run.
for "bx lr" gdb stops at address lr as expected.
btw: where can I find some (gnu) arm assembler docs/tutorial
which mention and explain bxcc (and the other opcodes;) ?
working example with "bx lr":
0x000fdfa4 in ?? ()
1: x/i $pc 0xfdfa4: bx lr
(gdb) print/x $lr
$2 = 0xf5be4
(gdb) si
0x000f5be4 in GetTimeInMillis? ()
1: x/i $pc 0xf5be4 <GetTimeInMillis?+44>: add r0, r4, r0
voila..
non-working example with "bxcc lr":
0x401f88b0 in gettimeofday () from /lib/libc.so.6
1: x/i $pc 0x401f88b0 <gettimeofday+16>: cmn r0, #4096 ; 0x1000
(gdb) si
0x401f88b4 in gettimeofday () from /lib/libc.so.6
1: x/i $pc 0x401f88b4 <gettimeofday+20>: bxcc lr
(gdb) p/x $lr
$3 = 0xf5bcc
(gdb) si
Breakpoint 2, 0x000f5bcc in GetTimeInMillis? ()
1: x/i $pc 0xf5bcc <GetTimeInMillis?+20>: mov r3, #1000 ; 0x3e8
(gdb)
without that breakpoint #2 at address 0xf5bcc gdb wouldn't have stopped :-(
btw: address 0x000fdfa4 in the 1st example is in divsi3, one
of the many "invisible" symbols (only ~350 out of 3314 symbols
show up in gdb for Xglamo)
nm .debug/Xglamo | sort | grep 000f
...
000fdef0 T aeabi_idiv
000fdef0 T divsi3
000fe01c T aeabi_idivmod
this is my other big gdb problem:
2)
gdb doesn't show/use all symbols in the debug symbol image. e.g. for symbols starting with "w" only 6 out of 12 symbols can be used:
(gdb) b W<TAB>
WantFontInfo? WellKnownConnections? WindowTable? WriteToClient? Write_CVT Write_CVT_Stretched
(gdb)
but:
harald om > nm .debug/Xglamo | grep -i " t w" | sort +2 | wc
12 36 359
harald om > nm .debug/Xglamo | grep -i " t w" | sort +2
000ed7f8 T WaitForSomething?
0001ef3c T WakeupHandler?
000245e8 T WalkTree?
00024a18 t WindowExtents?
0003d5f8 T WindowHasNewCursor?
0003fe68 T WindowsRestructured?
0003bb64 T WriteEventsToClient?
000462d8 T WriteSConnSetupPrefix
000478d8 T WriteSConnectionInfo
000ae73c t WriteSwappedPortNotifyEvent?
000ae698 t WriteSwappedVideoNotifyEvent?
000f297c T WriteToClient?
more examples on devel-list "Subject: Xglamo loops and hangs..."
any help or insights ?
thanks!
Change History
comment:2 in reply to: ↑ 1 ; follow-up: ↓ 3 Changed 5 years ago by h.koenig
Replying to zecke:
Please file such bugs upstream. Even if we are able to hack on gdb I do not see anyone having this pleasure during the next year. Once the bug is filed upstream please add the URL to this bug.
before reporting upstraeam (how many gdb developers might have an OM/FR?) I'd like to be sure
- that it's not just my error, me just starting up with OM and ARM...
- that my Xglamo binary and .debug/Xglamo really fit together (see my question about different time stamp)
- maybe even if someone can reproduce my findings (I can't beleave that noone so far used gdb with instruction stepping -- how to you test/debug ???).
- if this might be an artefact because of running a neo1973 kernel on a gta02v5 (btw. why is there no gta02 kernel in Om 2008.8(-update) ?).
IMHO _then_ it makes sense to bother the gdb guys...
BTW: I "only" have gdb-6.6 installed while gdb-6.8 source is available,
maybe gdb-6.8 would work just fine. gdb-6.6 is quite old and reporting
"bugs" for 1+ year old software without testing current release ins't
too kind either ;-)
from ftp.gnu.org:/pub/gnu/gdb/ :
-rw-r--r-- 1 1003 65534 19298180 Dec 18 2006 gdb-6.6.tar.gz
-rw-r--r-- 1 1003 65534 20076241 Oct 29 2007 gdb-6.7.1.tar.gz
-rw-r--r-- 1 1003 65534 20070649 Oct 10 2007 gdb-6.7.tar.gz
-rw-r--r-- 1 1003 65534 20709230 Mar 27 18:43 gdb-6.8.tar.gz
is there a change to get a decent gdb for testing ?
thanks!
comment:3 in reply to: ↑ 2 Changed 5 years ago by h.koenig
update:
BTW: I "only" have gdb-6.6 installed while gdb-6.8 source is available,
maybe gdb-6.8 would work just fine. gdb-6.6 is quite old and reporting
"bugs" for 1+ year old software without testing current release ins't
too kind either ;-)
I build gdb-6.8 myself with MokoMakefile? (surprisingly easy once I realized
that gdb-6.8 is alreay supported with a .bb file).
with gdb-6.8 instruction single stepping seems to work correct (at least for that "bxcc lr" as some few tests showed)
why does Om 2008.8 still include gdb-6.6 ?
- that my Xglamo binary and .debug/Xglamo really fit together (see my question about different time stamp)
so next I rebuild Xglamo using MokoMakefile? -- and now I get all symbols in gdb.
as I suggested: the -dbg package did't seem to match the installed binary:-(
for reference here are the md5sums of the files I tried before:
f3e4aa396f53cfe0e70b167bb130f1fb /usr/bin/Xglamo.
34457ec11ce9a0398ac2c3923fff81c2 /usr/bin/.debug/Xglamo.
so an upstream report to gdb is not neccessary.
now, where can I advocade to update gdb to version 6.8 in Om 2008.9 ???

Please file such bugs upstream. Even if we are able to hack on gdb I do not see anyone having this pleasure during the next year. Once the bug is filed upstream please add the URL to this bug.