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: Jerry Krinock <email@hidden>
- Date: Tue, 28 Jul 2009 20:02:43 -0700
On 2009 Jul 28, at 15:03, Jason Molenda wrote:
As Jonas suggested in his email, it's worthwhile to look at the ppc
side of your dSYM as well to see what's in there - I'm specifying -
arch i386 in all of these examples so you don't get confused by the
presence of ppc debug info when you need i386 debug info.
Same "< EMPTY >" stuff if I specify ppc.
Either the app was built without debug information or the app was
stripped before the GenerateDSYMFile. By the time dsymutil ran on
Bookdog, the debug symbols were not present.
Makes sense -- I like it!
You can run dwarfdump on one of your .o files like we did with the
dSYM earlier -- does it have any DWARF debug info in it?
Here we go:
dwarfdump --arch=i386 -r 0 "/Users/jk/Library/Application Support/
Xcode/IntermediateBuildFiles/Bookdog.build/Release/Bookdog.build/
Objects-normal/i386/BookdogController.o"
----------------------------------------------------------------------
File: /Users/jk/Library/Application Support/Xcode/
IntermediateBuildFiles/Bookdog.build/Release/Bookdog.build/Objects-
normal/i386/BookdogController.o (architecture i386)
----------------------------------------------------------------------
.debug_info contents:
0x00000000: Compile Unit: length = 0x000121c4 version = 0x0002
abbr_offset = 0x00000000 addr_size = 0x04 (next CU at 0x000121c8)
...<snip> (There are a total of 2376 dots) </snip>...
I'm not sure if those 2376 dots are dwarfdump's way of displaying non-
ASCII bytes?
Look for the Strip phase in your build log - is it happening before
the GenerateDSYMFile?
I built again, but couldn't find an explicit "Strip" phase in my build
transcript. Actually, even after modifying a .m file, I couldn't find
a GenerateDSYMFile phase either. Should it be skipping these phases
if there is a modified source file?
So, I did a "Clean". Then I built again. This time, my Build
transcript shows GenerateDSYMFile happening near the middle, and
"Stripping" is dead last.
Now, when I run dwarfdump --arch=i386 --debug-line, I get 144,007
lines. I see lots of file names, but no symbol names. A typical
section is shown below [1].
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.
I still don't see any symbols, but apparently they are there, because
the next thing I did was to purposely write a crasher into the code.
Then I built again. Again, Build Transcript says that
GenerateDSYMFile executed, as did Stripping (last, again). Then I ran
the app, generated a crash report, asked gdb to symbolize an address
from the report (even though it was already symbolized thanks to Crash
Reporter's "magic"), and, voila, it gave me the symbol. 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.
Here are my conclusions so far:
1. Xcode *sometimes* does not generate a .dSYM file at all.
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. But Xcode does warn me
that there are "no debug symbols in executable".
3. Xcode *sometimes* generates a .dSYM file with symbols in
it, i.e. WORKS AS EXPECTED.
However, I have yet to discover the conditions which evoke outcome 1,
2 or 3. This is a mature product, and I'm doing bug fixes only -- I
never touch the Build Settings, nor do I ever change the Active
Configuration from Release. As far as the order of GenerateDSYMFile
vs. Stripping, since I'm using Xcode I don't believe I have any
control over that. I'm just a monkey, checking boxes in Build
Settings :)
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?
Sincerely,
Jerry Krinock
The best way to introspect this is to use otool, e.g. "otool -arch
i386 -hlv Bookdog.app.dSYM/Contents/Resources/DWARF/Bookdog" you can
skip down to the LC_SEGMENT load command for the __DWARF segment and
see how much space all of the DWARF debug info is using.
I'll do that someday as a homework assignment.
[1]
----------------------------------------------------------------------
debug_line[0x00001278]
----------------------------------------------------------------------
Line table prologue:
total_length: 0x0000038d
version: 0x0002
prologue_length: 0x000001e3
min_inst_length: 0x01
default_is_stmt: 0x01
line_base: -10
line_range: 245
opcode_base: 0x0a
standard_opcode_lengths[ DW_LNS_copy ] = 0
standard_opcode_lengths[ DW_LNS_advance_pc ] = 1
standard_opcode_lengths[ DW_LNS_advance_line ] = 1
standard_opcode_lengths[ DW_LNS_set_file ] = 1
standard_opcode_lengths[ DW_LNS_set_column ] = 1
standard_opcode_lengths[ DW_LNS_negate_stmt ] = 0
standard_opcode_lengths[ DW_LNS_set_basic_block ] = 0
standard_opcode_lengths[ DW_LNS_const_add_pc ] = 0
standard_opcode_lengths[ DW_LNS_fixed_advance_pc ] = 1
include_directories[ 1] = '/Developer/SDKs/MacOSX10.4u.sdk/System/
Library/Frameworks/Foundation.framework/Headers'
include_directories[ 2] = '/Developer/SDKs/MacOSX10.4u.sdk/usr/include'
include_directories[ 3] = '/Developer/SDKs/MacOSX10.4u.sdk/usr/
include/i386'
include_directories[ 4] = '/Developer/SDKs/MacOSX10.4u.sdk/usr/
include/objc'
include_directories[ 5] = '/Users/jk/Documents/Programming/Projects/
Bookdog'
Dir Mod Time File Len File Name
---- ---------- ---------- ---------------------------
file_names[ 1] 5 0x00000000 0x00000000 BookdogArrayCategories.m
file_names[ 2] 2 0x00000000 0x00000000 i386/_types.h
file_names[ 3] 2 0x00000000 0x00000000 runetype.h
file_names[ 4] 2 0x00000000 0x00000000 objc/objc.h
file_names[ 5] 0 0x00000000 0x00000000 <built-in>
file_names[ 6] 1 0x00000000 0x00000000 NSObject.h
file_names[ 7] 1 0x00000000 0x00000000 NSArray.h
file_names[ 8] 1 0x00000000 0x00000000 NSArchiver.h
file_names[ 9] 1 0x00000000 0x00000000 NSObjCRuntime.h
file_names[ 10] 1 0x00000000 0x00000000 NSString.h
file_names[ 11] 1 0x00000000 0x00000000 NSValue.h
file_names[ 12] 5 0x00000000 0x00000000 BmItem.h
0x00001465: DW_LNE_set_address( 0x00005648 )
0x0000146c: DW_LNS_advance_line( 15 )
0x0000146e: address += 0, line += 0
0x0000000000005648 1 16 0
0x0000146f: DW_LNS_advance_line( 0 )
0x00001471: DW_LNS_advance_pc( 7 )
0x00001473: DW_LNS_copy
0x000000000000564f 1 16 0
0x00001474: DW_LNS_advance_line( 3 )
0x00001476: DW_LNS_advance_pc( 3 )
0x00001478: DW_LNS_copy
0x0000000000005652 1 19 0
<snip> And then there are dozens DW_LNS sections such as the above
three sections
_______________________________________________
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