Re: gdb: "No line number information available for address...." :(
Re: gdb: "No line number information available for address...." :(
- Subject: Re: gdb: "No line number information available for address...." :(
- From: Jason Molenda <email@hidden>
- Date: Tue, 28 Jul 2009 20:41:45 -0700
On Jul 28, 2009, at 8:02 PM, Jerry Krinock wrote:
And when I run dwarfdump --arch=i386 -r 0, I get 218 "Compile Unit"
sections similar to the one above. It looks like maybe there is one
"Compile Unit" for most every file in the code.
Right, the "-r 0" is telling dwarfdump to prune its output to just the
highest-level debug info entries (the source files). If you didn't
add that, you'd see a lot more information - but it would be harder to
tell if the expected information is actually present. We can assume
that if any debug information is present for a file, it is full and
complete.
I still don't see any symbols,
"symbols" is a loaded term. Some function names are present even in a
stripped, shippable binary and those may be the symbols you're
seeing. Local symbols are usually stripped from the binary. Debug
information gives you function names -- but it also gives you source
line information. Your original email showed you do "info line
*<addr>" which is a correct way to see if debug info is present. The
crash report popup can show you function names without the DWARF debug
information if those functions haven't been stripped from the binary.
Here are my conclusions so far:
1. Xcode *sometimes* does not generate a .dSYM file at all.
Xcode typically has a Debug and a Release configuration. Your Debug
configuration may not build a dSYM -- it isn't necessary if you're
debugging only on the machine where you built your app and you can
keep the .o files around. gdb can find the debug information in
the .o files. Your Debug configuration likely does not strip the
binary either. Your Release configuration will typically create a
dSYM and then strip the binary during its copy phase. You can see
these by bringing up your target's build settings (command-option-E I
believe) and specifying a Configuration to view.
I know of no bugs where Xcode behaves nondeterministically in its dSYM
creation. If it's not creating a dSYM, you likely have a
Configuration which does not create one.
2. Xcode *sometimes* generates a .dSYM file which in fact has no
symbols in it. You would not suspect this from the .dSYM file
size because it appears to be normal.
I've never seen anything like that.
But Xcode does warn me
that there are "no debug symbols in executable".
This is a warning from dsymutil and it only issues this warning when
it is run on a binary with no debug information. As I said earlier,
either the debug information was not generated in the first place or
it was stripped from the binary before dsymutil was run.
If dsymutil emits this warning, you will not get a dSYM. Well, at
least with the version of tools I'm using here. I don't know what
version of tools you are using or if this was a problem in the past.
3. Xcode *sometimes* generates a .dSYM file with symbols in
it, i.e. WORKS AS EXPECTED.
The problems you're experiencing are very likely a configuration
settings issue, not a bug with Xcode. Bugs in Xcode, or the tools
underneath it, are not unheard of but this is pretty basic stuff that
has been working for a while now.
Jason, do you or anyone know why Xcode would sometimes give me an
undesired outcome of either not generating a .dSYM file, or
generating an empty one? I do not always do a Clean before my final
Build. Is there a reason why that would be a good practice?
There is likely an unexpected setting in one of your target's
Configurations - but it is hard to speak as to what it is in general
terms.
You could work this problem by looking over your target settings for
your different Configurations or you could work this problem by
looking over a clean build and debug it step by step. At what point
does the debug information get removed? Is it in the .o files? In
the final binary? You can tell if a binary has been stripped by doing
nm -pa Bookdog.app/Contents/MacOS/Bookdog | grep ' OSO'
You should see a list of your .o files in your non-shipping binary.
dsymutil needs these. You should NOT see a list of your .o files in
your shipping (stripped) binary.
I can't offer any more concrete advice - the problem is likely
specific to your project setup in some way.
[...]
Weird because the size of the Bookdog file in the .dSYM package is
just a tad more, 3,254,939 bytes vs. 3,251,947 for the one that is
"empty", and there have been other changes since then too.
It's unlikely that the "empty" one is actually empty but but I don't
know what's going on here - Jonas' suggestion that it was built ppc
only was a good one. I would recommend running otool -hlv and seeing
what DWARF segments, if any, are present and what their sizes look like.
It may be constructive to create a do-nothing Cocoa Application new
project and observe how it builds its Debug/Release Configurations and
what its settings look like.
J
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden