views:

162

answers:

3

Hi all,

I wrote an iPhone app which uses a third party library. I crosscompiled this library successfully and everything works smoothly. But when I want to debug the application, it would make sense to also be able to debug the library. So I compiled also the external library with debuging information (usign the gcc option -ggdb). But when I want to debug it, I get the correct symbol names, but the positions are always wrong/extremly wierd (locale_facets.tcc:2505 or iostream:76). For example a stack trace could look like this:

#0  0x000045e8 in zorba::serialization::SerializeBaseClass::SerializeBaseClass () at iostream:76
#1  0x0001d990 in zorba::RCObject::RCObject () at iostream:76
#2  0x00025187 in zorba::xqpStringStore::xqpStringStore () at iostream:76
#3  0x000719e4 in zorba::String::String () at locale_facets.tcc:2505
#4  0x00030513 in iphone::iLabelModule::getURI (this=0x533f710) at /Users/sausalito/eth/izorba/sandbox/ilabel.cpp:19
#5  0x00356766 in zorba::static_context::bind_external_module () at locale_facets.tcc:2505
#6  0x0006139d in zorba::StaticContextImpl::registerModule () at locale_facets.tcc:2505
#7  0x000333e5 in -[ZorbaCaller init] (self=0x53405c0, _cmd=0x95583398) at /Users/sausalito/eth/izorba/sandbox/ZorbaCaller.mm:61
#8  0x00033180 in +[ZorbaCaller instance] (self=0x11dc2bc, _cmd=0x93679591) at /Users/sausalito/eth/izorba/sandbox/ZorbaCaller.mm:37
#9  0x0003d998 in -[testOne execute:] (self=0x530d560, _cmd=0x9366b126, sender=0x5121da0) at /Users/sausalito/eth/izorba/sandbox/generator/testOne.mm:13
#10 0x01a21405 in -[UIApplication sendAction:to:from:forEvent:] ()
#11 0x01a84b4e in -[UIControl sendAction:to:forEvent:] ()
#12 0x01a86d6f in -[UIControl(Internal) _sendActionsForEvents:withEvent:] ()
#13 0x01a85abb in -[UIControl touchesEnded:withEvent:] ()
#14 0x01a3addf in -[UIWindow _sendTouchesForEvent:] ()
#15 0x01a247c8 in -[UIApplication sendEvent:] ()
#16 0x01a2b061 in _UIApplicationHandleEvent ()
#17 0x03b6fd59 in PurpleEventCallback ()
#18 0x034a8b80 in CFRunLoopRunSpecific ()
#19 0x034a7c48 in CFRunLoopRunInMode ()
#20 0x03b6e615 in GSEventRunModal ()
#21 0x03b6e6da in GSEventRun ()
#22 0x01a2bfaf in UIApplicationMain ()
#23 0x0002dd7e in main (argc=1, argv=0xbffff044) at /Users/sausalito/eth/izorba/sandbox/main.m:16

Does anybody have an idea, where these wrong locations come from?

+1  A: 

I don't have a complete answer for you, but when I end up with something I am having trouble getting a backtrace for, I will find whatever is closest or just go through different functions until something crashes.

For example, /Users/sausalito/eth/izorba/sandbox/ZorbaCaller.mm:61 looks like a good place to start. Just a little deeper, that looks like its still in your source code:

iphone::iLabelModule::getURI (this=0x533f710) at /Users/sausalito/eth/izorba/sandbox/ilabel.cpp:19
iaefai
Sure I could do that. But since the library I am linking against is one of our projects, I also want to be able to debug this. It is very hard if you cannot see 90% of your stack trace (or let's say only the method names but no line number and no variable information).
Markus Pilman
+1  A: 

I've seen e.g. inlining to be a problem when debugging. Turning off (or at least reducing) gcc optimization (-O0 or -O1) helped. Maybe also worth a try in your case. Also note that there are different types of debug information formats. You also might want to pass -gdwarf-2 to the gcc compiling your library. (Of course depends what debugging format you use in Xcode as well).

tcurdt
+1  A: 

It looks like your third party library is C++. Is it using templates? If so, the code is being generated at compile time based on the template arguments. In this case, the source doesn't exist on disk and it's impossible for the compiler to show you the actual code it compiled or give you an accurate line number.

Steve Madsen